The assistant can only see this trip
What does this piece decide?
TripGlide's assistant runs in an edge function with two tools. The trip id is fixed for the request. A tool cannot name a different one.
A member asks the assistant about the day. The message is free text. If a tool trusts a trip id from that text, one member can read a trip they were never on.
The function binds the id
The travel-ai function rejects an id that is not a UUID and binds the valid one for the request. get_trip_data cannot supply a different id. The read uses the caller's token. Email and contact are dropped unless the role is owner or admin. The OpenAI key and the model name stay in the function, off the phone. The default model is gpt-4o-mini. Chat, recommendations, and the daily plan are three actions on that same function. Chat history travels with the request.
Weather is a tool. A price is not a guess.
get_weather asks Open-Meteo for that place and date, and returns activity hints from the forecast. The chat instruction requires bookings, prices, and hours to come from a tool. Asked for a plan, a model will write a forecast, a price, and opening hours when the prompt leaves the blank. The tool is what stops that. A generated day sends a slice of the saved itinerary and a slice of the forecast. The daily-plan action asks for one object: date, location, activities with time, duration, category, and cost, then weather advice and packing tips. Neither call books anything.
The loop has a last turn
Each turn can load members, expenses, messages, and the itinerary again. Nothing in the call itself stops the next one. After the tool turns, the function calls the model once more with the tools removed. A snapshot read is capped per field. The answer has to finish.
Who can see the trip, the upload, and the expense that waits for an owner are in the TripGlide case study.