Multi-agent constraint solving across 50+ tourism vendors, in real time

A national tourism board coordinating a country-wide vendor ecosystem — hotels, ski lifts, restaurants, transport, activities.

Each with its own availability, its own booking system, and its own dependencies on the others. Which is the part that makes this hard.

The board needed a system that could coordinate 50+ tourism vendors in real time, reason with local and cultural knowledge, optimise complex itineraries on the fly, and maximise revenue through intelligent cross-selling.

The gap, in one line: traditional travel apps give static recommendations. What was needed was dynamic, intelligent coordination — a system that knows a change to one booking is a change to several.

Those three figures are market research, not results from this engagement — they are here because they explain why a tourism board was commissioning this in the first place. Sources: Statista on AI use in travel and tourism, and aggregated travel-chatbot adoption statistics. The measured numbers for this project are the four at the top of the page.

• CascadeA single substitution — a different hotel — propagates through transport, timing and every booking downstream. Handling that as “start over” is a bad experience; handling it as constraint re-satisfaction is the product.
• Heterogeneity50+ vendors means 50+ integration surfaces with no common standard between them.
• LatencyA traveller changing plans is standing somewhere, waiting for an answer. Re-planning had to happen at conversation speed.
• TimelineFour weeks with a lean team, against an architecture that had to survive city-wide operation afterwards.
• Local knowledgeCultural and contextual judgment is not in a booking API. It had to be modelled explicitly.

One model asked to handle accommodation, transport, dining and revenue does all four at the level of its weakest. Worse, it has no principled way to arbitrate when they conflict — and in itinerary planning they conflict constantly.

So we built an AI conductor that orchestrates specialised agents the way a conductor coordinates a section. Each agent is competent in its own domain; the conductor is responsible for them making sense together.

The core mechanism is a background scratchpad acting as working memory. Rather than re-deriving the itinerary on every change, the system holds the current plan and its constraints, then reasons about what a proposed change breaks.

1. 01AI conductor — Built on the Agno framework. Responsible not for answering, but for making the specialists agree with each other.
2. 02Specialist agents — Accommodation, transport and lift scheduling, dining and activities, and cross-sell — each competent in one domain rather than all of them approximately.
3. 03Background scratchpad — The system’s working memory, holding the current plan and its constraints. This is what makes re-planning possible instead of restarting.
4. 04Vector database — Fast lookup across the vendor and destination corpus.
5. 05Vendor integration — 50+ live APIs across the ecosystem, on AWS, with real-time processing.

Ask for a cheaper hotel further out and the system checks the evening dinner reservation and the added ski-lift commute before answering — then returns the optimised plan rather than a list of things that now conflict.

The failure mode of a naive itinerary assistant is not a wrong answer. It is a quiet one. A change gets applied, three downstream bookings become invalid, and nobody finds out until a traveller arrives somewhere at the wrong time.

Holding the plan as an explicit constraint set is what prevents that. A proposed change is tested against the commitments it touches, and the conflicts it creates are surfaced and resolved rather than absorbed — so the response names what moved: the transport, the ski schedule, the table.

The same structure is what lets the cross-sell agent operate safely. It can only suggest what the constraint set will still satisfy, so revenue optimisation cannot quietly break the plan it is attached to.

• Itinerary planning went from hours to minutes — 70% faster, because re-planning replaced rebuilding. This is the constraint scratchpad paying for itself.
• Vendor coordination fully automated across 50+ vendors, through 50+ live API integrations — replacing what the board described as manual chaos.
• A 60% efficiency gain on revenue, from cross-selling that the previous static-recommendation approach simply never surfaced.
• Delivered as a 4-week MVP with a lean team, on an architecture built for city-wide operation from the start.

The behaviour that demonstrates the difference is the ordinary one: asked to change a hotel while keeping a dinner reservation, the system updates the transport, adjusts the ski schedule and confirms the table — and mentions that the new hotel is five minutes closer to the slopes.

The multi-agent constraint optimisation built for tourism now underpins other work — supply chain logistics in real time, healthcare scheduling for dynamic patient care, and enterprise resource planning.

Multi-vendor coordination at scale turns out to be one problem wearing different clothes: a set of independent parties, a shared set of constraints, and a change that has to propagate correctly through both.