From Single-Agent to Multi-Agent Architecture

The multi-agent hype cycle is in full swing. The pitch is seductive: instead of one AI agent doing everything, you have specialized agents that each handle a specific domain. A search agent. A booking agent. A support agent. They coordinate like a team of experts, each contributing their specialty.

It sounds great on paper. In practice, the tradeoffs are more complex than the hype suggests.

We have built both single-agent and multi-agent architectures at Nowah. I want to share what we learned about when each approach wins, when it loses, and how we think about the architectural decision.

The allure of multi-agent

The case for multiple agents is compelling.

Specialization. A search agent can have a model instructions optimized for understanding travel queries and selecting search parameters. A booking agent can have a prompt optimized for collecting passenger data, handling payment flows, and managing confirmations. Each agent is tuned for its specific role.

Independent scaling. Search is called far more often than booking. With separate agents, you can scale them independently. More search capacity during peak hours without over-provisioning booking infrastructure.

Isolation. A bug in the booking agent does not affect search. A model update to the search agent can be tested independently. Failures are contained within agent boundaries.

Parallel processing. A search agent can query flights while a hotel agent queries hotels simultaneously. The results are merged by a coordinator. This reduces latency for complex queries.

These are real advantages. They explain why multi-agent architectures are popular in the research literature and in conference talks. But they come with costs that are less frequently discussed.

Coordination overhead

The biggest cost of multi-agent architecture is coordination.

When one agent does everything, context is naturally shared. The agent that searched for flights knows the results. The agent that selected option B knows the price. The agent that is about to book knows all of the above because it is the same agent.

When separate agents handle search, selection, and booking, every piece of context must be explicitly passed between them. The search agent's results have to be serialized and transmitted to the ranking agent. The ranking agent's selections have to be packaged for the booking agent. The booking agent needs the full context of what was discussed, what was selected, and why.

This state-passing introduces latency. In our testing, coordination overhead added 30-50% to total response time compared to a single agent handling the same task. That is significant when users are waiting for a real-time conversational response.

It also introduces failure modes. What if the state transfer is incomplete? What if the search agent's output format does not match what the ranking agent expects? What if the coordinator routes to the wrong agent? Each handoff point is a potential failure point, and in an agentic system, failures compound.

When single-agent wins

We found that single-agent architecture wins in several scenarios that happen to be common in travel booking.

Shared context is high. In a typical travel planning conversation, the booking agent needs to know everything the search agent discussed. There is very little information that is relevant to one agent but not another. When context overlap is high, the benefit of specialization is low and the cost of context transfer is high.

Conversation flow is non-linear. Users do not follow a clean search-then-rank-then-book pipeline. They search, then ask a question about visa requirements, then modify their search, then ask about hotels, then go back to flights, then book. With multiple agents, every change of topic requires a handoff. With a single agent, the conversation flows naturally.

Debugging is paramount. When something goes wrong in a single-agent system, you have one conversation thread to examine. When something goes wrong in a multi-agent system, you have to trace the issue across multiple agents, their handoff messages, and the coordination layer. In our experience, debugging time roughly doubled with multi-agent.

Cost per interaction matters. Each agent call consumes tokens. A coordinator agent that routes messages adds overhead. State serialization adds tokens. In a multi-agent system, the same user query might consume 2-3x the tokens of a single agent processing the same query.

Our single-agent processes 3 to 7 tool calls per complex query. It does this within a single reasoning chain. The context is always available. The reasoning is coherent. Debugging is straightforward.

When multi-agent wins

Multi-agent architecture is not wrong. It is situationally better.

Extreme specialization requirements. If one domain requires fine-tuned models and another requires frontier reasoning models, multi-agent lets you match models to tasks. A fast, cheap model for simple intent classification. A powerful, expensive model for complex planning.

Independent development velocity. If you have separate teams working on search, booking, and support, multi-agent lets each team iterate independently. Changes to the search agent's prompt do not require regression testing the entire booking flow.

Regulatory boundaries. If payment processing has different compliance requirements than search, separating them into different agents with different security contexts can simplify compliance.

Truly parallel tasks. When tasks have no dependencies (search flights AND search hotels simultaneously), separate agents can process them in parallel. A single agent processes them sequentially unless the model supports parallel tool calling.

Domain decomposition for travel

If you do go multi-agent for travel, the natural decomposition is:

Intent router. A lightweight agent (or even a classifier) that determines what the user wants: search, book, modify, cancel, general question. This routes to the appropriate specialist.

Search agent. Handles flight and hotel searches. Optimized for query understanding, tool parameter extraction, and result presentation.

Booking agent. Handles the transaction flow: collecting passenger data, confirming details, processing payment, issuing confirmations. Optimized for accuracy, idempotency, and error recovery.

Support agent. Handles post-booking questions: itinerary changes, cancellation policies, document retrieval, disruption management.

The challenge is the boundaries between these agents are blurry. A user might start asking a question (support territory), then decide to modify their trip (booking territory), which requires a new search (search territory). The conversation crosses boundaries multiple times, and each crossing requires a handoff.

Shared memory across agents

The most underestimated problem in multi-agent architecture is shared memory.

In a single-agent system, memory is naturally shared. The agent that learned your preference for aisle seats is the same agent that books your flight. Simple.

In a multi-agent system, preference information must be stored in a shared memory service that all agents can access. The search agent needs to know your preferences to rank results. The booking agent needs to know your passenger details. The support agent needs to know your booking history.

This shared memory service becomes a critical dependency. If it is slow, all agents are slow. If it has stale data, agents make decisions on outdated information. If its schema does not accommodate a new piece of information that one agent needs, you have a cross-team coordination problem.

We found that the engineering complexity of a robust shared memory service roughly equals the complexity of the agents themselves. It is not a minor infrastructure detail. It is a core system component that determines the quality of the entire multi-agent system.

Our architectural evolution

We started with a single agent. It was simple, fast, and easy to debug. As we added more tools (now 70+), we wondered if a single agent could handle the complexity. A model instructions with 70 tool definitions is large. Would the model get confused about which tools to use?

We tested a multi-agent approach where a router directed queries to specialized agents for search, booking, and support. Each specialist had a smaller tool set (15-25 tools) and a focused model instructions.

The results were mixed. Specialist agents made marginally better tool selections within their domain. But the coordination overhead, the context-passing failures, and the debugging complexity more than offset the gains. Task completion rate was slightly lower in the multi-agent setup, primarily due to handoff failures.

We went back to a single agent with improved prompt organization. We structured the 70+ tools into categories with clear descriptions. We added tool selection guidelines in the model instructions. We tuned the tool schemas for maximum clarity.

The single-agent approach with well-organized tools outperformed the multi-agent approach on our evaluation metrics. Your mileage may vary depending on your domain, your scale, and your team structure. But for our use case, where most conversations naturally cross domain boundaries and shared context is essential, single-agent was the right call.

The cost analysis

Architecture decisions have direct economic consequences that are often underestimated in the design phase.

In a single-agent system, a complex booking query might consume 8,000-15,000 tokens: the model instructions with tool schemas, the conversation history, tool call parameters and results, and the generated response. One model call, one round of tool execution.

In a multi-agent system, the same query might consume 25,000-40,000 tokens distributed across multiple agents. The router agent needs a model instructions and the user message. The search agent needs its own model instructions, the user message, and the routing context. The booking agent needs its model instructions, the search results, and the conversation history. Each agent call includes overhead for model instructions, tool schemas, and context serialization.

At current inference pricing, the per-query cost difference between single-agent and multi-agent is roughly 2-3x. For a product that processes thousands of conversations daily, this adds up. Over a month, the difference could fund an engineer.

The cost argument alone does not settle the architecture question. If multi-agent produced meaningfully better outcomes, the extra cost might be justified. In our testing, it did not. Task completion rates were comparable or slightly lower (due to handoff failures), while costs were substantially higher. The economic case reinforced the engineering case for single-agent.

The testing dimension

Testability is a practical consideration that affects development velocity more than most teams anticipate.

Testing a single-agent system is relatively straightforward. You send a message and verify the response. You check that the right tools were called with the right parameters. You confirm that the response correctly represents the tool results. One agent, one conversation thread, one set of assertions.

Testing a multi-agent system requires verifying the behavior of each individual agent, the routing logic that directs queries to agents, the state serialization between agents, and the end-to-end behavior of the complete system. A bug could be in any agent or in the coordination layer. Reproducing a failure requires capturing the state at each handoff point.

Our test suite runs in minutes for the single-agent architecture. When we prototyped multi-agent, the equivalent test suite took 3-4x longer because each test scenario involved multiple agent calls and state verifications. The feedback loop between making a change and knowing whether it worked was slower, which meant slower iteration.

For a product that is evolving rapidly, as any AI product should be in 2026, iteration speed is a competitive advantage. Anything that slows the feedback loop has real costs.

The hybrid path

Pure single-agent and pure multi-agent are not the only options. There is a hybrid approach that we are exploring.

The primary interaction uses a single agent with the full tool suite. This agent handles the conversational flow, maintains context, and manages the booking lifecycle. No handoffs. No coordination overhead.

But certain background tasks run as separate, specialized processes. Price monitoring runs independently, checking saved routes for price changes. Flight status monitoring runs independently, watching for delays and cancellations. Document processing runs independently, parsing passport scans and organizing trip documents.

These background processes are not agents in the conversational sense. They do not interact with the user directly. They feed information into the primary agent's context when relevant. "I noticed that the SFO-NRT route you are watching dropped to $420" comes from the price monitor but is presented by the primary agent.

This hybrid approach gives us the simplicity of single-agent conversation with the specialization benefits of independent processing for well-defined background tasks. The coordination overhead is minimal because the background processes are event-driven, not conversational.

Lessons for other domains

Our experience generalizing from travel to other agentic domains suggests a few principles.

Start with single-agent. The simplicity benefits are enormous for development speed, debugging, and user experience. You can always decompose later if you need to.

Decompose only when forced. The compelling reasons to decompose are: genuinely different model requirements (one task needs a cheap fast model, another needs an expensive powerful model), regulatory boundaries that require isolation, or scale requirements that demand independent scaling.

Never decompose for organizational reasons. "We have two teams" is not a good reason for two agents. Organizational structure should follow product architecture, not the other way around.

Measure the coordination cost honestly. Multi-agent papers often report the accuracy of individual agents. They less often report the end-to-end accuracy including coordination failures. Always measure the full system, not the parts.

The 3-7 tool calls per complex query that our single agent handles would, in a multi-agent system, require at least 3-7 inter-agent messages plus the tool calls themselves. The overhead is not trivial. For real-time conversational products, that overhead directly affects user experience.

When to reconsider

Several triggers would make us reconsider the single-agent approach.

Tool count beyond 100. At some point, the number of tools in a single agent's schema becomes unwieldy. The model spends more tokens reasoning about which tool to use. Selection accuracy drops. If we cross this threshold, domain-specific sub-agents might become necessary.

Latency requirements tighten. If user expectations for response speed increase (they will), parallel processing across specialized agents might be needed to meet latency targets that a single sequential agent cannot.

Regulatory segmentation. If payment processing regulations require stricter isolation between booking and search components, separate agents with separate security contexts might become a compliance requirement.

Model specialization diverges. If a specialized model trained specifically for travel search dramatically outperforms the general model we use, it might be worth running that specialist alongside a general coordinator. Today, frontier models are good enough at all our tasks that specialization does not justify the coordination cost.

We track these triggers quarterly. None have fired yet. When one does, we have the evaluation framework to measure whether a multi-agent approach actually improves outcomes, not just whether it sounds architecturally cleaner.

The industry perspective

Many AI companies talk about multi-agent as their architecture. I think some of them would benefit from simplifying.

The appeal of multi-agent is partly technical (real specialization benefits) and partly narrative (it sounds impressive to say you have a team of coordinating agents). The narrative appeal is strong in investor presentations and conference talks.

But users do not care about architecture. They care about whether the product works. A single-agent system that completes bookings reliably is better than a multi-agent system that occasionally drops context during handoffs, even if the multi-agent system is architecturally more interesting.

This is not a permanent decision. As models improve at inter-agent coordination and as our tool count grows, the calculus might shift. We evaluate the architecture decision quarterly. But for now, simplicity wins.

The real question

The multi-agent vs single-agent debate often gets framed as a technical architecture decision. I think the real question is simpler: does the user have a better experience?

Users do not care whether their request was handled by one agent or five. They care whether they got a good flight at a good price without hassle. They care whether the agent remembered their preferences. They care whether the booking was confirmed correctly.

If a multi-agent system delivers measurably better user outcomes, the coordination complexity is worth it. If it delivers equivalent outcomes with more engineering complexity and higher costs, it is not.

Our evaluation framework gives us a definitive answer for our product today: single-agent delivers equivalent or slightly better outcomes at lower cost and lower complexity. The margin is not dramatic, but the direction is clear.

The debate will continue in conference talks and architecture blogs. We will continue measuring. And we will switch to multi-agent the day our metrics tell us it is the right call. Until then, we ship the simpler system that works.

A note on team structure

One argument for multi-agent that deserves acknowledgment is team organization. In large companies with separate teams for search, booking, and support, multi-agent architecture maps naturally to team boundaries. Each team owns an agent. Dependencies are managed through well-defined interfaces.

This is a legitimate consideration at scale. But for most startups and growth-stage companies, the team is small enough that everyone works on everything. Introducing architectural boundaries to match a team structure that does not exist yet is premature optimization of the organizational kind.

We have seen companies split into multi-agent architectures primarily because different engineers wanted ownership of different pieces. The architecture served the organization chart, not the product. In every case we observed, this introduced coordination overhead that slowed the product down.

Build the simplest architecture that serves the product. Reorganize the architecture when the product or the team demands it. Not before. The 3 to 7 tool calls per complex query that our single agent handles work because one agent has full context. Splitting that context across agents should be a last resort, not a first instinct.

The architecture should serve the user experience, not the org chart, not the conference talk, and not the blog post about how you built a team of coordinating agents. Ship what works. Measure what matters. Evolve when the data says to. And resist the temptation to add architectural complexity for the sake of appearing sophisticated. The most sophisticated system is the simplest one that solves the problem reliably. Complexity is not a feature. Simplicity that works is.

Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. Plan your next trip.