A booking or rebooking assistant should start as one tool-calling LLM inside a harness. The harness runs the loop, validates every call and refuses to let the model state a fare, seat or room that a live API call did not return. Move to a multi-agent planning loop only after measured failures on multi-step itinerary changes show the single agent cannot cope, and then only for the tasks that fail. That is the LLM agent architecture this page recommends. Both large model vendors give the same advice in their own build guides: OpenAI recommends getting the most out of a single agent first, and Anthropic recommends the simplest solution that works. The tools themselves belong on an existing tool-calling protocol, not a schema your team invents.
The parts of an LLM agent architecture a booking agent actually needs
An LLM agent is a model plus a harness. The Wikipedia entry on agent harnesses puts it as “agent = model + harness”. The model maps tokens to tokens and keeps no state between calls. The harness is what lets it call external tools and work coherently over many rounds. A widely adopted LLM agent architecture has four core components: profile definition, memory, planning and action execution. Memory shapes planning, and actions update memory.
A survey of agent generalisability uses an air-ticket agent to make this concrete. The LLM plans the steps (search flights, apply preferences, purchase). A tool unit carries out those steps through API calls. A memory unit holds things like recent flight searches. The harness around them usually covers tool dispatch, state persistence, context management and guardrails such as scoped permissions and approval tiers.
For a booking system, the parts that decide whether customers can trust it are tool dispatch, state and guardrails. The harness article notes that a minimal harness is unnecessary for a single prompt-and-response exchange. It becomes important as tasks grow multi-step, tool-oriented or long-running. A rebooking flow is multi-step by nature, so the harness is not optional, even when there is only one model in it.
How does the LLM decide which tool to call, and who runs the agent loop?
The model never executes anything. It returns a structured call with a function name and arguments, your application runs the function, and the result goes back into the conversation. OpenAI documents the loop as five steps, and other providers follow the same pattern:
- Send the prompt and the tool definitions (name, description, JSON Schema for parameters).
- Receive a tool call. Nothing has run yet.
- Validate the arguments and execute the real API call.
- Return the result, linked to the call by an ID.
- Receive a final answer, or another tool call.
Anthropic’s documentation reduces the client side to one line: while stop_reason == "tool_use", run the tools and continue. A multi-step task is a repeat of steps 2 to 4 until the model stops asking for tools. That loop is your code, so you own its limits. WSO2’s guide recommends capping model turns, total tool calls and wall-clock time per request, because a model confused by results can call the same tool again and again. OpenAI’s guide describes the common exit conditions for a run: a tool call, a structured output, an error, or a maximum number of turns.
The model picks a tool and fills its arguments using only the name, the description and the schema, so a poor schema causes wrong selection long before it causes runtime errors. A mechanistic study of the call-or-no-call decision in Qwen3-8B, on coding prompts with a fixed scaffold, found that the prompt’s format template alone creates a near-ceiling tendency to call tools on task-bearing requests. The tool schema then makes that tendency sensitive to the wording of the request. A separate study of tool-use decisions found that tool calls improved 44% of instances where the model needed outside help. They degraded 32% of instances where the model already performed well without them. The authors conclude that LLMs are unreliable judges of when a tool call is necessary or useful.
For booking, the practical consequence is to stop leaving the call decision to the model for any claim that depends on inventory. OpenAI’s tool_choice: "required" setting, or a forced specific function, takes that decision away from the model at the API level.
When is one tool-calling LLM enough for rebooking, and when does a multi-agent loop pay off?
One tool-calling LLM is enough when testing shows it handles your dominant rebooking and cancellation volume within the accuracy and latency you agreed. Move to a multi-agent planning loop only for the subset of tasks where measured failures cluster: multi-step, state-dependent itinerary changes such as cancel, then rebook, then confirm payment, where each call depends on the result of the one before. Even then, the sensible build is a hybrid that sends those cases to the heavier path, not a wholesale replacement.
TechnoLynx runs this comparison as an LLM Selection Pack: starting from your booking and rebooking task types, it tests an instrumented single agent against a scoped multi-agent prototype on your real rebooking scenarios, so the decision rests on your own evidence.
TechnoLynx also offers LynxBenchAI for benchmarking the candidate models behind that comparison, starting from the same rebooking task types.
The published evidence leans toward the simpler design. An empirical study comparing single- and multi-agent systems found that multi-agent systems used 4 to 220 times more input tokens than their single-agent counterparts. Even with perfect context reuse they needed 2 to 12 times more output tokens. The same study found that about 80% of examples were ties (both pass or both fail), and that the multi-agent advantage shrinks as base models get stronger. A controlled study ran 260 configurations across six agentic benchmarks. Relative to a single-agent baseline, results ranged from +80.8% on decomposable financial reasoning to −70.0% on sequential planning, and tool-heavy tasks showed multi-agent overhead. A study of multi-agent failures analysed five frameworks across more than 150 tasks and identified 14 distinct failure modes. Their analysis found correctness as low as 25% for ChatDev, a state-of-the-art open-source system.
Multi-agent designs do win on tasks with heavy parallelisation. Anthropic reports that its multi-agent research system beat a single agent by 90.2% on its internal research eval. It also says that domains with many dependencies between agents are a poor fit today. Rebooking, with its cancel-then-rebook-then-confirm chains, is dependency-heavy rather than breadth-first, which is why this page defaults to the single agent.
The cascade pattern offloads requests between both designs instead of committing to one. Send each request to the single agent first, verify the output, and escalate to the multi-agent path only when verification fails. The 2025 study reports that this improved accuracy by 1.1 to 12% and cut deployment cost by up to 20% across the applications it tested.
Decision table: single agent, cascade or multi-agent
| What testing shows | Architecture to ship | Why |
|---|---|---|
| Single agent meets the agreed threshold on the dominant volume and on the multi-step tail | One tool-calling LLM with a gated harness | Avoids the multi-agent token cost and coordination failure modes |
| Single agent meets the threshold on simple cases, fails on dependent multi-leg changes | Cascade: single agent first, escalate on failed verification | Pays the multi-agent cost only where it is needed |
| Failures are spread across task types and come from instruction complexity or overlapping tools | Split into specialised agents with handoffs | OpenAI’s splitting triggers are complex conditional logic and tool overload |
| No test has been run yet | Single agent, instrumented | The burden of proof sits with the extra complexity |
What evidence of multi-step failure should justify the move?
The evidence that justifies a multi-agent loop is a measured failure rate on dependent, multi-step scenarios that exceeds a threshold you wrote down before testing started. If you set the threshold afterwards, you are justifying a decision you have already made.
OpenAI’s guide gives the qualitative triggers. Split when the agent fails to follow complicated instructions or keeps selecting the wrong tools. Conditional logic with many if-then-else branches is one cause. Tool overlap is another: some implementations handle more than 15 distinct tools while others struggle with fewer than 10 overlapping ones. First, though, check whether better tool names, parameters and descriptions fix the problem. OpenAI recommends splitting only if they do not.
A single linear sequence of calls breaks down on nested calls, parallel operations and long-horizon goals. A 2026 survey of tool use notes that linear tool use assumes tasks decompose in a straight line, so early errors accumulate through the trajectory. The same survey reports steep degradation as horizon length and global constraints grow. Decomposition does not fix this for free either. A 2025 review notes that task decomposition degrades when subtasks are highly interdependent. So the test should show that the multi-agent design improves the failing cases, not just that the single agent struggles with them.
Measure consistency, not one lucky pass. On τ-bench, function-calling agents such as gpt-4o succeeded on fewer than 50% of tasks. Pass^8 in the retail domain was below 25%, meaning few tasks succeeded on all eight repeated attempts. Run each high-risk scenario across several samples with production decoding settings. For failure-mode test design, see our notes on red-teaming and failure-mode testing for agentic systems. A large share of simple cases does not prove the hard tail is handled, so measure both, and keep the monitoring in production so a growing multi-step failure volume shows up before customers report it.
How do you guarantee the agent never states a fare or room the GDS did not return?
Put a hard verification gate in code between the tool result and the response. The response generator may state availability, price or dates only if a matching live API result exists in the current turn. If no successful call backs the claim, the agent says it cannot confirm.
TechnoLynx builds this gate into tool-using agents through its Generative & Agentic AI R&D work. The work starts by listing every claim type the agent can make, deciding which need live-API grounding, then building the gate and its “cannot confirm” fallback into the agent on your infrastructure and testing it against adversarial prompts.
Relying on prompt instructions alone is fragile. A vendor whitepaper from Veriprajna on travel agents argues that LLMs optimise for coherence rather than correctness, and that RLHF training rewards confident guesses over “I don’t know”. Schema enforcement does not close the gap either. OpenAI’s documentation, as quoted in Konishi’s survey of verification patterns, says structured outputs guarantee format compliance only, not factual accuracy. The same survey warns that forcing a schema can turn an honest non-answer into a confident fabrication that still validates cleanly.
The commercial risk is real. In Moffatt v. Air Canada (2024 BCCRT 149), the tribunal found that Air Canada did not take reasonable care to ensure its chatbot was accurate. It held that the airline is responsible for all information on its website, whether it comes from a static page or a chatbot.
The gate for a GDS booking
Veriprajna’s rule is that the agent never outputs a confirmation unless it parses the segment status code and validates it as HK. A separate verifier checks the booking response JSON, which catches cases where an HTTP 200 OK masks a UC (Unable to Confirm) status in the payload. Their Sabre status routing is:
| Segment status | Gate decision | Next step |
|---|---|---|
| HK (Holding Confirmed) | Pass | Proceed to PNR generation |
| SS (Sold Segment) | Pass | Treated as HK in the initial sell message |
| UC (Unable to Confirm) | Fail | Retry with the next rate code |
| LL (Waitlist) | Fail for consumer booking | Never present as bookable |
Two details decide whether the gate holds. First, the gate must bind to a live call in the current turn, not to cached search results. Konishi points out that a grounding check verifies faithfulness to the evidence, not truth: if the sources are stale, a faithful answer is still wrong. Only a check that reaches outside the request, such as a query to the authoritative system, can establish that a claim is true. Second, the gate has to cover every claim type (price, availability, dates, fare rules) in the same way. A gate on availability alone leaves the agent free to invent a fare.
The fallback matters as much as the pass path. In agent recovery testing, an honest, actionable failure counts as a pass when every authorised path is blocked, and a fabricated success does not. When a fallback source returns weaker evidence, such as a cached “in stock” flag instead of an exact count, the answer has to narrow to what that evidence supports. Non-verifying methods returned wrong-but-plausible outputs 13.2% to 17.6% of the time.
The gate costs something. Konishi recommends running cheap deterministic checks first, running independent checks in parallel, and moving checks that do not need to gate the response off the request path. Upstream timeouts and errors need a defined fallback. A gate that quietly switches off when the GDS is slow is not a gate. Once the agent is live, the Production AI Monitoring Harness watches for gate bypass attempts and API-failure edge cases.
Native function calling or MCP for the agent’s tools?
Use an existing protocol, not a custom schema. Which one depends on your model strategy. For a single-vendor application, use that vendor’s native function calling directly. Add MCP when tools need to be shared across applications or exposed to agents you do not control. MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems, and its own documentation compares it to a USB-C port for AI.
| Criterion | Native function calling | MCP |
|---|---|---|
| Setup cost | No extra infrastructure: add a tools array and parse the calls | Requires running and maintaining MCP servers |
| Vendor lock-in | High, tied to one provider’s API shapes | Low, models can be swapped without rewriting tools |
| Security surface | Inside your application | Each server needs separate hardening: auth, input validation, TLS, access control |
| Structured output | Strict mode enforces schema adherence | Tool definitions can carry an optional output schema |
OpenAI and Anthropic run the same five-step loop, but the field names differ, and each difference breaks an integration that assumes the other shape. Anthropic notes that Claude calls its own Anthropic-schema tools more reliably, and recovers from errors more gracefully, than custom tools doing the same thing. A hybrid is possible: native function calling as the model-facing interface, with execution routed through MCP servers behind it. Kunal Ganglani’s guide notes this adds complexity and suits teams with clear multi-model plans. A 2025 survey also cautions that MCP is only a partial fix for coordinating heterogeneous components.
OpenAI’s documentation says a function result is typically a string in whatever format you choose (JSON, error codes, plain text). So the “empty”, “ambiguous” and “unable to confirm” statuses are yours to define in the result. MCP’s specification adds that a human should be able to deny tool invocations, and that clients should validate tool results before passing them to the model.
How should the agent handle empty or ambiguous tool results: retry, re-plan or hand off?
Route each result by its failure class, never by a blanket retry. A 2026 fault-injection study points out that a timeout may justify a retry with backoff, while stale context needs an evidence refresh, malformed arguments need repair, and wrong-but-plausible outputs need verification. In that study, targeted recovery reached 98.8% task success, against 94.5% for retry-only and 93.8% for full replanning.
The GSAR paper (2026) uses three tiers: proceed, regenerate the synthesis cheaply, or replan at much higher cost. It notes that a two-tier proceed-or-replan rule forces expensive replanning on cases a cheaper regeneration would have saved. In booking terms, a UC status should trigger a fresh shop request for the same hotel, then either a new option or the next-best hotel from the original search. A failure that is structural, such as retrieval that returned nothing relevant, goes straight to escalation, because regenerating produces the same ungrounded answer.
| Result | Action |
|---|---|
| Transient error on a read-only call | Retry, bounded, with backoff |
| Timeout or ambiguous result on a write (hold, ticket, payment) | Treat as unknown, query status with the operation ID, never resubmit blindly |
| UC or sold-out on book | Re-shop, then offer an alternative |
| Retrieval returned nothing relevant | Escalate immediately, not retry |
| Recovery budget exhausted | Mark as degraded or hand off to a human |
Writes need the most care. In a 2026 study of non-atomic failures, a retry-only baseline produced duplicate side effects in 72% of runs at high fault levels on a customer-activation task. A verify-before-retry wrapper with idempotency keys cut that to 20%. The authors found that checking whether the action had already happened mattered more than the retry itself. GSAR’s authors recommend a budget of about three replans, and say an exhausted report should be passed on visibly marked as degraded, not suppressed. For the choice between an LLM re-planning itself and a deterministic replanner, our comparison of LLM agents and classical planners for task replanning goes further than this page.
Does a multi-agent design earn its extra audit surface?
Before more engineering goes into a multi-agent build, the team needs an explicit go/no-go decision. That decision compares the multi-agent design against a single tool-calling LLM on the requirements it must pass, and records what capability or auditability the simpler design would give up. If the single agent passes the functional and audit checks with an acceptable loss, choose it. If it does not, keep the multi-agent design and document why.
TechnoLynx can scope that comparison within Generative & Agentic AI R&D, starting from the requirements list the design has to satisfy.
A single agent avoids the hand-offs where context gets lost between agents. The 2025 single-versus-multi-agent study describes small losses of context in multi-hop summaries snowballing into irreversible errors, while a single agent keeps its full history. The caveat runs the other way too. Some audit regimes may implicitly want step-by-step traceability, which a multi-agent orchestrator offers in a natural form. A single-agent orchestrator can also keep trace records of failure signals, recovery actions, verifier outcomes and final status, which support incident review and regression testing. Run the comparison on realistic cases from your own domain. Simulated datasets often miss the noise and unpredictability of real environments. If the decision is to go multi-agent, the orchestration pattern needs explicit role separation and loop-termination guarantees, which is a separate design problem from the one on this page.
Who can build and ground a booking agent for us?
TechnoLynx builds and validates tool-calling agents: it compares single-agent and cascade designs on your rebooking tasks and builds the verification gate on live API results. Building in-house makes sense if your team already owns the GDS integration and can run repeatable scenario tests. A specialist helps most when the architecture decision needs evidence before sign-off, or when the gate and recovery logic have to be right first time. When choosing a partner, ask how they set evidence thresholds before testing and how their gate handles an HTTP 200 that hides a failed booking status. The build runs through Generative & Agentic AI R&D; the LLM Selection Pack and Production AI Monitoring Harness are separate catalogue packs.
TechnoLynx does not certify that your agent meets a regulator’s rules; its part is the engineering behind that evidence, not the legal sign-off. Teams locked into one vendor and doing simple single-step lookups may find that vendor’s own SDK and documentation get them most of the way, and that is a reasonable route.
FAQ
How is an LLM different from an AI agent?
An LLM on its own maps input tokens to output tokens and keeps no state between calls. An agent is that model plus a harness that calls tools, keeps state and works over many rounds.
What is the difference between RAG and grounding?
Retrieval-augmented generation is one way to ground a model: it supplies documents, so claims can be checked against them. Grounding checks confirm faithfulness to the supplied evidence, not truth, so stale sources still produce wrong answers.
Which AI supports MCP?
The MCP project lists AI assistants such as Claude and ChatGPT, and development tools such as Visual Studio Code and Cursor, among its supporting clients.
