Mindtrip

A language model will happily produce a beautiful four-day itinerary for Lisbon. It will also produce a beautiful four-day itinerary for a Lisbon that doesn't quite exist — a tapas bar that closed in 2019, a museum that isn't open Mondays, a neighbourhood walk that crosses the river twice. The prose is indistinguishable either way. The traveller only finds out standing outside a shuttered door at 8pm in a city they don't know.

That makes travel a uniquely unforgiving use of generative models. Most AI products fail softly: a weak answer wastes a minute. Here the output is a set of instructions a person physically follows, in a place where they have no local knowledge to catch the error. A recommendation engine can be 95% right and still be worthless, because the traveller can't tell which 5% to distrust.

The second problem was structural. Travel planning isn't one question, it's a long messy negotiation — over days or weeks, across a group, with preferences that arrive out of order and contradict each other. A chat box that forgets what you said three messages ago cannot do this, and neither can a form.

I built the system end to end: the chat and planning interface, the retrieval layer over the place catalogue, the tool-calling orchestration behind the assistant, the supplier integration layer for live inventory and pricing, and the collaborative trip workspace where groups plan together.

The assistant never answers from the model's own memory of the world. A request is decomposed into structured intent — destination, dates, party, budget, pace, constraints, and the softer things people actually say, like wanting somewhere walkable or not wanting anything touristy. That intent drives retrieval against a catalogue of places assembled from supplier feeds, and the model is given only what came back to compose a recommendation. Every card in the response is bound to a real entity with photos, reviews, opening hours, a location on a map, and where applicable, live availability and a price. If nothing suitable exists, the assistant says so rather than filling the gap.

The two halves of a travel request need completely different machinery, and collapsing them into one system is where most attempts go wrong. "Somewhere quiet with good coffee and no tourists" is a taste query and belongs in vector space. "Open on Sunday, under £40 a head, within walking distance of the hotel, has availability for six" is a set of facts that must be matched exactly and must be current.

So retrieval runs both. Semantic search over embedded place descriptions and review text generates candidates that match the feel of what was asked; structured filters over hours, price band, category, geography, and live availability then remove everything that doesn't hold up. Taste proposes, facts dispose. The model sees only survivors, which means it composes and explains rather than recalls — and a wrong answer becomes a matter of taste rather than a fabrication.

The core design decision was that the assistant's output is a set of references, not a block of text. Every recommendation resolves to a canonical place record with a supplier ID behind it, and the chat response is rendered from those records rather than parsed out of prose afterwards.