Agentic AI · Systems Architecture

One agent, or a
team of them?

Multi-agent systems delegate tasks to specialized agents that collaborate, exchange tasks, and verify each other's results. When implemented effectively, they outperform a single generalist agent. However, if implemented haphazardly, they often incur unnecessary costs and coordination efforts without any significant benefits.

SLIDE 01 : MULTI-AGENT SYSTEMS
Cover slide: Multi-Agent Systems
Quick answer

A multi-agent system Coordinating multiple LLM-driven agents, each with a unique role, prompt, model tier, or tool set, is necessary to successfully complete tasks that a single generalist agent would struggle with due to inefficiency, slowness, or inability. This complexity is justified by three key conditions: specialization (a focused agent genuinely outperforms a generalist), parallelism (independent tasks can be executed concurrently, reducing overall time) critique Six orchestration patterns effectively enhance the quality of production systems beyond the capabilities of self-review within a single agent. supervisor/worker, hierarchical, swarm, pipeline, debate, and fan-out : it's important to note that multi-agent setups usually have 58% to 285% more token overhead compared to a single well-designed agent, so it's wise to ensure one of those three conditions is met before opting for a team.

SLIDE 02 : WHEN MULTI-AGENT ACTUALLY PAYS OFF
Three conditions that justify a multi-agent architecture
Not a default, a decision

Earn the added complexity

This shape is often overly utilized in applied AI: opting for multiple agents for the sake of complexity rather than necessity. A single well-defined agent, equipped with the appropriate tools and sufficient context, can effectively handle the majority of tasks.

  • Specialization : a specialized agent with a specific prompt and limited tools consistently surpasses a generalist in this particular task
  • Parallelism - Multiple sub-tasks can be executed simultaneously, reducing the overall time taken for a task that would otherwise be completed sequentially by a single agent.
  • Critique : a new critic agent, offering a fresh perspective, identifies mistakes that an individual agent consistently overlooks during self-review
The orchestration patterns

Six shapes cover almost every production system

Every pattern is a unique response to a common inquiry: who determines the outcome and how are outcomes reconciled.

SLIDE 03 : SUPERVISOR / ORCHESTRATOR-WORKER
Supervisor pattern: central coordinator dispatching to worker agents
The 2026 production default

One coordinator, several specialists

In most production scenarios, a central supervisor assigns tasks to specialist worker agents after breaking down the main goal into subtasks, eventually combining the results. This orchestrator-worker topology is utilized in approximately seventy percent of multi-agent systems.

Clear control and easy debugging are provided, as all decisions pass through a single point. However, the downside is the potential bottleneck of centralization, with the supervisor's expanding context window typically taking up most of the token spend, rather than the worker calls.

SLIDE 04 : HIERARCHICAL (SUPERVISORS OF SUPERVISORS)
Hierarchical pattern: nested supervisors managing specialist worker teams
When one layer of delegation isn't enough

A tree of supervisors, not just workers

In hierarchical systems, supervisors are organized into levels, with a top-level coordinator assigning tasks to mid-level supervisors such as a research team lead and a code team lead. Each mid-level supervisor oversees a team of specialized workers. The higher levels prioritize coordination and planning, while the lower levels focus on carrying out tasks.

The added coordination overhead is justified only when the task complexity involves multiple distinct domains of expertise. Introducing an additional hierarchy to a task that can already be managed by a single supervisor only results in increased delays and expenses, without any corresponding advantage.

SLIDE 05 : SWARM / DECENTRALIZED PEER-TO-PEER
Swarm pattern: peer agents coordinating without central control
No single point of failure : or control

Peers, not a chain of command

Autonomous agents in a swarm operate independently, communicating with nearby agents or through a message bus, rather than relying on central coordination. This decentralized approach eliminates bottlenecks and points of failure.

The cost of not having a coordinator is evident in the complexity of achieving system convergence and debugging. Swarm technology is most beneficial in research and summarization tasks, where independent parallel exploration proves to be highly effective.

SLIDE 06 : PIPELINE / SEQUENTIAL
Pipeline pattern: agents processing work in sequence
The simplest topology that still counts as multi-agent

Each agent refines what the last one made

Agents in the pipeline work through tasks in a set order, with each one building upon the work of the previous agent - starting with drafting, then editing, and finally fact-checking. This linear process ensures that each step relies on the completion of the one before it, making the workflow straightforward to understand and troubleshoot, but also completely sequential with no overlap between tasks.

It is best suited for workflows that follow a truly organic order of drafting, editing, and verifying, as opposed to tasks that can be done simultaneously.

SLIDE 07 : DEBATE / CONSENSUS
Debate pattern: multiple agents argue perspectives, a judge arbitrates
Paying for a second opinion

Two perspectives, a judge decides

During the debate pattern, multiple agents present varying viewpoints on a common issue, with a distinct judge, possibly a different model, mediating between them. This method effectively implements the 'critique' condition for engaging in multi-agent systems, as an impartial second opinion can identify mistakes overlooked by a single agent's self-assessment.

The cost of running a debate pattern is significant, typically around two and a half times the cost of a single-model call. It should be reserved for high-stakes decisions where the potential cost of being wrong justifies the expense.

Quick reference

All six patterns, at a glance

Central control
Supervisor / Worker

One coordinator dispatches and synthesizes. The 2026 production default.

Nested control
Hierarchical

Supervisors of supervisors, for genuinely multi-domain complexity.

No central control
Swarm

Autonomous peers, parallel exploration, harder to coordinate.

Fixed order
Pipeline

Sequential hand-offs, each agent refining the last one's output.

Adversarial
Debate

Competing perspectives plus a judge; costly but high-assurance.

Scatter-gather
Fan-out

Parallel dispatch to independent workers, results gathered back.

SLIDE 08 : COORDINATION & SHARED STATE
Diagram of shared state and coordination challenges in multi-agent systems
Where multi-agent POCs actually fail

Context loss, not pattern choice, sinks most systems

All orchestration patterns require persistent, shared state that outlasts any individual agent's actions. Without this crucial component, systems will encounter the same common failures regardless of the chosen pattern.

  • Context loss : intermediate results disappear between agent hand-offs
  • Payload bloat : instead of sharing state references, the full context is passed through every hand-off.
  • Race conditions : two agents overwrite each other's work with no coordination
  • Recovery failures : no checkpoint exists to resume from after a crash

Cross-vendor communication has its own emerging standard: the A2A protocolUnder the Linux Foundation, it dictates how agents can communicate with one another across various frameworks or vendors, irrespective of the orchestration pattern in use.

The honest cost picture

Multi-agent is not free parallelism

Each additional agent increases the number of tokens, causing the coordination overhead to grow more rapidly than anticipated by many teams.

SLIDE 09 : TOKEN ECONOMICS BY TOPOLOGY
Token overhead by multi-agent topology, and model tiering by role
Where the spend actually goes

The supervisor's context, not the workers, drives cost

Independent and decentralized configurations usually incur approximately 58% higher token overhead than a similar single agent setup, while centralized supervisor configurations can see an increase of up to 285%, as each worker's output ultimately passes through and expands the supervisor's context window.

One commonly used cost-saving strategy is model tiering, where a larger, more advanced model is designated for the planner or supervisor role, while smaller, less expensive models are used for routing classifiers and specific worker tasks. This is because the supervisor's decision-making quality has a greater impact on the overall outcome than any individual worker's performance.

TopologyTypical token overheadCost driver
Single agent (baseline)0%:
Independent / decentralized~58% extraRedundant context across peers
Centralized / supervisor~285% extraSupervisor's growing context window
Debate / consensus~2.5x a single callMultiple full reasoning passes plus a judge
SLIDE 10 : MATCHING PATTERN TO TASK
Summary: matching an orchestration pattern to task characteristics
The decision that matters most

Pattern follows task, not the other way around

In real systems, various patterns are frequently intertwined - for example, a hierarchical arrangement can involve a pipeline within individual teams, or a supervisor may initiate a swarm to facilitate parallel exploration before consolidating the outcomes. It is not incorrect to use these hybrid approaches; the error lies in selecting a structure without first comprehending the requirements of the task at hand.

Begin with one agent. Introduce a second only if specialization, parallelism, or critique proves its value - and budget for the additional overhead costs upfront, before they are reflected in the invoice.

Frequently asked

Multi-agent systems FAQ

If one of three conditions is met: a specialized agent outperforms a generalist on a sub-task, independent sub-tasks can be run in parallel to save time, or a separate critic agent catches errors missed by self-review, then it may be more cost-effective and easier to debug to use a single well-scoped agent.

The supervisor/ orchestrator-worker pattern is employed in around seventy percent of multi-agent deployments, where a central coordinator divides tasks into subtasks, assigns them to specialized workers, and combines the outcomes, providing precise control but risking the supervisor becoming a bottleneck.

Decentralized, autonomous configurations usually have approximately 58% higher token overhead compared to a single agent, while centralized supervisor configurations can have up to 285% more, mainly due to the supervisor constantly absorbing each worker's output. Discussing patterns with a judge model can cost around 2.5 times more than making a call to a single model.

In hierarchical structures, supervisors are organized into levels, with higher levels focusing on planning and coordination, while lower levels handle execution. This system remains centralized, but operates across multiple tiers. In contrast, Swarm operates without a central coordinator: autonomous peer agents work independently and communicate directly with each other, eliminating bottlenecks but making coordination more complex to understand.

More often than not, the issue lies not in the chosen orchestration pattern, but in the absence of persistent shared state. This results in context loss during hand-offs, bloated payloads being passed at each step, clashes between agents overwriting each other's work, and no safety net to recover from crashes. Prioritizing coordination and state management is key, overshadowing the importance of selecting the 'perfect' topology.

Agent-to-Agent (A2A) is an open standard, currently managed by the Linux Foundation, designed for enabling communication between agents from various vendors or frameworks, allowing coordination across different orchestration patterns.

Get started

Ready to design your agent team?

Begin with only one agent, ensure one of the three conditions is met before introducing a second agent, and select the orchestration pattern that best fits the actual requirements of your task, rather than choosing the most grandiose option available.