Multi-Agent Systems › Limitations and Practical Considerations

Multi-agent systems are powerful, but they introduce failure modes that single-agent systems do not have. Understanding these limitations clearly is as important as understanding the capabilities, since deployment decisions often hinge on whether the system will hold up in production.

In a pipeline, each agent's errors can compound downstream. If the researcher agent produces inaccurate findings, the analyst and writer agents build on those inaccuracies. Unlike a single agent that encounters a problem and can backtrack, a pipeline agent often has no visibility into earlier stages' quality. Adding verification stages helps but increases both latency and cost.

The compounding nature of pipeline errors is a fundamental challenge. A 10% error rate at each of five pipeline stages produces roughly 40% of outputs with at least one error, even if each individual stage is reasonably reliable. This is a strong argument for keeping pipelines shallow (three to four stages at most) and investing heavily in the quality of each stage rather than adding more stages to compensate for earlier deficiencies.

Every agent invocation costs tokens and time. An orchestrator planning five subtasks, dispatching them, reviewing results, and synthesizing outputs might use an order of magnitude more tokens than a single agent tackling the same problem directly. For routine tasks, this overhead is not justified. Multi-agent approaches earn their cost on difficult tasks that benefit from specialization and parallel search.

A useful rule: use multi-agent when the task can be decomposed into independent subproblems, when different subproblems require different specialized knowledge or tools, or when the cost of errors in critical subtasks justifies independent verification. For straightforward single-step tasks, a well-prompted single agent is both cheaper and faster.

Agent invocations account for only part of a multi-agent system's token cost. The orchestrator itself must process all incoming completion messages, maintain an updated view of the workspace, and reason about what to do next after each round. For large task decompositions with many agents, the orchestrator's context window can become expensive. Practical orchestrator design therefore involves keeping completion messages compact (structured status plus a brief summary, with full results in the workspace) rather than including full agent outputs in every message.

When agents communicate through shared workspaces or message passing, malicious or compromised inputs can propagate. A research agent that processes a webpage containing a prompt injection attack (a webpage that instructs the agent to ignore its task and perform a different action) might write manipulated data into the shared workspace, corrupting downstream agents. Multi-agent systems require careful input sanitization, output validation, and trust boundaries between agent roles. We will address these risks in detail in the Agent Safety chapter.

The trust problem is particularly acute because agents in a multi-agent system are often designed to trust each other's outputs. An analyst that trusts the researcher's findings without independent verification is efficient, but it is also vulnerable to any compromise of the researcher. Defense-in-depth, where each agent validates inputs before acting on them, adds cost but significantly improves security.

Single-agent failures are relatively easy to trace: examine the conversation history, identify the point of error, and fix it. Multi-agent failures involve reconstructing a distributed execution trace across multiple agents, conversation threads, and message exchanges. Good tooling is essential: structured logging, conversation thread tracking, and replay capabilities that let you inspect what each agent received and produced at each step.

Observability frameworks adapted from distributed systems (distributed tracing, correlation IDs, structured logging with context propagation) apply directly to multi-agent systems. Treating each agent invocation as a span in a distributed trace and linking all spans for a single user request through a common trace ID makes failures debuggable even in complex multi-agent topologies.

Because subagents receive structured outputs from other agents as inputs, the output format of one agent becomes a de facto interface contract with the next agent. When you change how the researcher formats its findings, the analyst's prompt may break because it expects specific field names or structures. This prompt coupling is a maintenance burden. Formal output schemas (using JSON Schema or Pydantic models) help enforce consistency.

Treating inter-agent data formats as versioned APIs, with explicit schemas and change management processes, turns prompt coupling from a hidden fragility into an explicit, manageable dependency. This discipline takes effort upfront but pays dividends when the system needs to evolve.

As the number of agents grows, coordination overhead scales in ways that can offset the parallelism gains. Consider what happens when an orchestrator manages 50 agents simultaneously. The orchestrator must process status messages from all 50, maintain an accurate model of the workspace, and route new tasks as dependencies resolve. For an LLM-based orchestrator, this means each orchestration cycle includes a growing volume of context that the orchestrator must process in full before making the next set of dispatch decisions. At some agent count, the orchestrator becomes the bottleneck, spending more time reading and processing messages than any individual agent spends on its assigned work.

Several architectural responses exist. Hierarchical orchestration, where a top-level orchestrator manages a small number of sub-orchestrators who each manage a group of agents, reduces the fan-out at each level. A two-level hierarchy with a top orchestrator managing 5 sub-orchestrators, each managing 10 agents, gives the same 50-agent capacity but reduces the maximum coordination fan-out at any single point from 50 to 10. The tradeoff is additional latency through an extra coordination layer and more complex failure modes when a sub-orchestrator fails.

Another response is to reduce orchestrator involvement in routine progress. Rather than having every agent send a completion message directly to the orchestrator, agents can push results into a structured workspace and the orchestrator periodically polls for readiness conditions. This batch polling pattern reduces the number of LLM calls required for orchestration but introduces latency between task completion and dispatch of the next dependent task.

A single well-designed agent will outperform a multi-agent system in several situations. Tasks that are inherently sequential, where each step depends heavily on the result of the previous step and the next step cannot be specified in advance, do not benefit from parallelism and pay a coordination tax for no gain. Tasks with very low latency requirements may find that the orchestration overhead makes multi-agent slower than a single agent despite the parallelism potential. Tasks requiring strong narrative coherence, where the final output needs to feel like it was written by one voice with one consistent line of reasoning, often suffer from the stitching artifacts that arise when outputs from multiple agents are combined. Recognizing these situations and defaulting to single-agent design preserves resources for cases where multi-agent helps.