Building a Trip Planner Agent

Most agent demos use a simple tool call: look up the weather, search a database, summarise a document. These are fine for illustrating a single concept, but they don't show you what happens when the pieces interact.

A trip planner forces every concept from the enterprise agents page to work together at once. Intent is ambiguous, data comes from multiple services, some tasks can run in parallel, and the user expects a coherent result even when parts of the system fail.

Everything on this page — the event topics, the agent roles, the context window design, the fallback chain — is a direct consequence of those requirements. The system shape comes from the problem.

Before designing the system, it helps to walk through what the agent actually needs to do at each step. This is the lifecycle from first user message to final itinerary.

The system has five layers. A UI layer where the user interacts. An intent layer where free text becomes structured data. An event bus that decouples intent from execution. A pool of specialist agents that each own one concern. And an assembly layer that turns raw results into a final answer.

The event bus is the critical design choice. Without it, the orchestrator would call each agent in sequence — or in parallel but with a tangled web of direct calls. With it, agents are fully decoupled. You can add a new specialist (say, a visa requirements agent) without touching any existing code.

The event bus is where choreography happens. Rather than an orchestrator calling each agent and waiting, the IntentAgent publishes one event and walks away. Each search agent reacts to it independently. The ResultAssembler listens for all four result events and assembles the plan when they arrive.

This is the fan-out pattern. One event, many consumers. No coupling between the producers and consumers. The IntentAgent has no idea who is listening.

Six agents, each with a single responsibility. The search agents — FlightAgent, HotelAgent, WeatherAgent, ActivitiesAgent — don't call external APIs directly. Each one submits an intent to the Lattice capability runtime and receives a structured projection back.

The search agents in this system don't call external APIs directly. Each one submits a typed intent to Lattice — a capability runtime that executes the underlying steps, manages retries and failure policy, keeps intermediate state out of the model's context, and returns a projection shaped for reasoning rather than integration.

The model sees two meta-tools regardless of how many capabilities exist. It never needs to know about the underlying APIs.

The IntentAgent builds a context window before each LLM call. The contents are assembled dynamically based on what's known: trip constraints extracted from the current message, user preferences pulled from memory, conversation history from the session, and any context retrieved from earlier agent results.

Not all of this fits in one call. Context windows have limits, and even within the limit, attention is not uniform. Items in the middle of a long context receive less weight. So the IntentAgent prioritises: hard constraints first, then preferences, then history.

Once the intent event is published, all four search agents start simultaneously. None of them wait for each other. The ResultAssembler holds until the hard dependencies — flights and hotels — are done. Soft dependencies contribute if they finish within the timeout window.

The three traces below show how this plays out across different types of requests. Select a query to see how intent was parsed, which agents ran in parallel, and what came back.

The trip planner needs three kinds of memory working at the same time. Working memory holds the current request — the constraints extracted in this session, the results received so far, any corrections the user has made. It lives in the session state attached to the request and disappears when the request is done.

Long-term memory holds user preferences: airports they prefer, hotel amenities they care about, destinations they've visited and want to avoid repeating. This is retrieved from a vector store at the start of each session and injected into the IntentAgent's context. It persists across requests.

The conversation buffer holds the dialogue from the current planning session. If the user rejects the first hotel option and says "something in Shinjuku instead," the buffer gives the IntentAgent the context to understand that correction without asking again.

The FlightAgent is a hard dependency. If it fails completely, the itinerary can't include flights. The error handling chain tries to avoid that outcome through three layers: retry, fallback provider, and finally graceful degradation.

Each agent emits an OpenTelemetry trace span when it starts and when it finishes. Tool calls are child spans. LLM calls are child spans with token counts attached as span attributes. The result is a complete trace tree that shows exactly where time was spent.

The trace below represents a real request. The root span covers the full request duration. You can see the sequential IntentAgent phase, the parallel search phase where flights and hotels run concurrently, and the assembly phase at the end.

Every component in one diagram. The user enters through the UI. The IntentAgent translates the request into a structured event. The event bus fans the event out to four search agents. Each agent calls its tool, handles its own failures, and publishes its result. The ResultAssembler waits for hard dependencies, calls the LLM, and sends the itinerary back.

The observability stack watches every hop. The memory store is read at the start and written when new preferences are detected. Dead-letter events from failed agents go to a monitoring service that can trigger retries or alert on-call.