Skip to content
TiMiNa
All articles
Guide · Multi-agent systems

Multi-agent systems explained: when multiple AI agents are better than one

By Misagh Akhondzad/18 min read
Multi-agent systemsOrchestrationAI agentsEnterprise AI

Imagine an AI system evaluating next quarter’s promotional plan. A single agent could attempt the whole task — but a commercial analyst thinks differently from a demand planner, several analyses can happen simultaneously, and some agents may need access to systems that others should never see. Why not build a lead agent with six specialists underneath it, the way human organizations divide complicated work?

Because adding agents does not automatically create intelligence — it creates a coordination problem. The system must now determine who does what, who knows what, how work is divided, how duplicated work is prevented, how disagreements are resolved, who owns the final answer, and how the system stops. A weak multi-agent system produces five agents repeating the same search, contradictory analyses, long conversations with little progress, cascading hallucinations, much higher cost — and an answer worse than one strong agent would have produced. A multi-agent system is not a single agent repeated; it is a designed organization of agents, and the architecture determines whether they behave like a coordinated expert team or a chaotic group chat.

Multiple agents are valuable only when the benefits of specialization, parallelism, context separation, or independent verification exceed the costs of coordination.

Foundations

What counts as a multi-agent system

A multi-agent AI system is an architecture in which two or more model-driven agents — each with its own instructions, context, role, tools, or authority — communicate or coordinate to complete a task. Not every extra model call qualifies. Three model calls in a fixed chain (extract → summarize → rewrite) is a workflow. Three named prompts called “researcher, writer, editor” with no independent decision-making is still close to a prompt chain. Three autonomous specialists — a research agent choosing sources, a writer selecting evidence, an evaluator requesting corrections and approving completion — is clearly multi-agent. The boundary is a spectrum, and an agent earns the name through some combination of a defined objective, bounded context, available tools, decision responsibility, state, and an exit condition.

Keep the neighbours distinct. Agents versus models: several agents can share one model with different roles and permissions, and one agent can use several models — different architectural axes. Agents versus tools: a tool is a bounded capability; do not create an “AI finance agent” to perform arithmetic an approved calculator handles. Agents versus workflows: the workflow defines how work moves; multi-agent coordination should usually sit inside a broader controlled workflow. Agents versus personas: “think like a marketer, an analyst, and a skeptical customer” is multi-perspective prompting — separate agents have independent context windows, trajectories, tools, and state, which is exactly why they cost real money.

Why and when

Five reasons — and the coordination tax

  • Specialization. A contract agent focused on obligations and fees, a finance agent on contribution and exposure — narrower, clearer instructions with less distraction than one agent carrying every business rule.
  • Parallelism. Independent workstreams run simultaneously. Anthropic reported large gains from parallel research subagents on breadth-first information-gathering — and that this works only when work is genuinely independent.
  • Context separation. Several focused contexts beat one crowded window; subagents compress large bodies of work into concise findings for a lead agent.
  • Permission separation. The research agent gets the public web; the contract agent gets approved contracts; only the execution agent touches reservations. Agent boundaries reinforce least privilege.
  • Independent verification. A second agent challenges the first — but only when it has real independence. Two identical agents with identical context make correlated errors.

Every agent also creates overhead: more model calls, tokens, communication, state, failure paths, and evaluation work — Anthropic reported its multi-agent research system using roughly fifteen times the tokens of ordinary chat, economically justified only for sufficiently valuable tasks. The coordination tax is the work of making distributed agents function as one system: decomposition, briefing, updates, conflict resolution, synthesis, recovery. Splitting 100 units of work across four agents does not produce 25 each:

TOTAL COMPUTEone agent100= 100four agents4 × 25302015= 165coordinationduplicationsynthesisELAPSED TIMEone agent100sequentialfour agents≈ 60parallel wins heresplit only when the gain outweighs the tax
The coordination tax: more total work, less wall-clock

One agent is often better when the task is sequential, steps share context, the toolset is manageable, latency matters, and the output needs one consistent voice — OpenAI’s agent guidance explicitly recommends maximizing a single agent’s capabilities first, and splitting mainly when instructions become unmanageable or tool overlap causes persistent selection failures. Multi-agent architecture earns its keep when several conditions hold at once: independent workstreams, materially different specialist contexts, evidence exceeding one useful context window, different permissions, genuine value from independent perspectives, and task value that justifies the cost. The design spectrum runs from fixed pipelines through managers, dynamic orchestrators, peer handoffs, blackboards, debate, and markets to open agent networks — flexibility rises rightward, and so do unpredictability and governance burden. Enterprise systems should begin on the controlled side.

Three architectural dimensions

Centralized versus decentralized: a coordinator owns decomposition, monitoring, and synthesis (clear ownership, but a bottleneck and single point of failure), versus agents handing off directly (flexible, but unclear accountability, loops, and hard stopping conditions — adopt it for a real coordination requirement, not because it resembles a social network). Static versus dynamic teams: predefined specialists are predictable and testable; dynamically created workers match effort to complexity — and invite agent sprawl. Anthropic reported early orchestrators spawning dozens of unnecessary subagents for simple queries, which is why explicit effort budgets and delegation heuristics exist. Cooperative versus competitive: shared goals versus competing proposals, bids, and debates — competition creates diversity and can waste resources or invite strategic behavior; mixed systems have teams cooperate internally while competing across alternatives.

Pattern catalog

Control and structure patterns

  1. 01Manager with agents as tools. The manager keeps user context, control, and synthesis, calling reusable specialists as tool invocations. Clear accountability; risks are poor delegation, ignored findings, and nuance lost in compression.
  2. 02Orchestrator–worker. The orchestrator dynamically decomposes the task and creates temporary workers — Anthropic’s research system in a sentence. The difference from a manager: workers are task-specific, not predefined. The load-bearing detail is the worker contract: objective, scope, context, tools, expected output, budget, stopping condition. “Research Retailer A” is weak; “identify the current fee, notice period, and funding obligations in the signed 2026 agreement, from the approved repository only, as a structured table with clause references — do not analyse profitability” is delegation.
  3. 03Decentralized handoffs. Control transfers — triage → billing → refund → human — with a handoff packet: goal, current owner, reason, verified facts, evidence, completed actions, open questions, constraints. The receiver must not reconstruct history.
  4. 04Sequential specialist pipeline. Research → analysis → writing → editing, the MetaGPT/ChatDev assembly line. Predictable with clean interfaces; rigid, error-propagating, and prone to the game of telephone. If the “agents” have no autonomy, use a prompt chain and drop the theater.
  5. 05Parallel specialists. Finance, supply, contract, market running independently, then merged. A shared assumptions object tames the classic failure: incompatible assumptions discovered at synthesis.
  6. 06Hierarchical teams. Managers of managers for genuinely multi-level work — with information distortion, slow communication, and accountability diffusion as the price. Do not reproduce an eight-level corporation in software without measured benefit.
  7. 07Blackboard architecture. Agents read and write a shared workspace of tasks, evidence, hypotheses, and conflicts — asynchronous and inspectable, but it needs schemas, permissions, versioning, and conflict resolution, or it becomes a poisoned whiteboard.
  8. 08Artifact-centric collaboration. Agents exchange evidence tables, code files, and memos instead of long conversations — preserving fidelity, reducing token copying, enabling audit. For enterprise systems, artifacts usually beat free-form agent chat.

Deliberation patterns

  1. 01Debate. Agents propose, challenge, and respond before a judge rules. Research suggests gains on selected tasks — but persuasive language can beat evidence, agents can share the same error, and cost grows by round. Debate works best when claims are verifiable.
  2. 02Critic and red-team agents. A focused reviewer — factuality, security, legal, assumptions — with explicit criteria and a stopping limit, or critique becomes an endless loop that degrades good work.
  3. 03Voting and weighted voting. Independent attempts, majority rules. Helps when errors are independent — and same-model, same-context agents agree confidently on the same mistake. A unanimous answer can still be wrong; weights should come from evidence, not role names.
  4. 04Consensus. Discussion until agreement — coherent, and capable of suppressing valuable dissent. In high-stakes decisions, preserving unresolved disagreement is often safer than forcing agreement.
  5. 05Judge or jury. Several proposals, one selector applying rubric, tests, and policy — not rhetorical quality.
  6. 06Mixture-of-Agents. Layers of agents synthesize prior layers’ outputs — benchmark gains on language generation that may not transfer to tool-using enterprise workflows with real state.
  7. 07Role-playing, markets, and swarms. CAMEL-style role play structures interaction, but “you are a senior legal expert” confers no qualification, sources, or accountability — roles need context, tools, and governance behind them. Auction systems allocate tasks by bids (calibration and gaming are open problems), and true swarms — many simple agents, emergent coordination — remain experimental for enterprise knowledge work.
  8. 08Human–multi-agent teams. Humans as leads or as specialists inside the team. Microsoft’s research highlights the real challenges: common ground, visibility, steerability, uncertainty communication, authority clarity, and trust calibration — more than task accuracy.
Communication

How agents should talk

Communication is the connective tissue — and unstructured natural-language chat is flexible, ambiguous, and expensive. The architecture should define who may communicate with whom, in which format, and with what authority. The channels: direct messages (for clarification — with loop and audit risks), broadcast (for constraint changes and stop signals — with noise and groupthink risks), shared-state objects (goal, completed tasks, evidence, open questions, decisions — far easier to inspect than chat), events (contract_verified, capacity_unavailable — the asynchronous backbone), and artifact references— send “artifact FINANCE-2084, type scenario_analysis, complete” and let the receiver pull the content. Protocols make messages typed (task_request, progress_update, result, challenge, escalation, stop) and conversations bounded: manager assigns, worker accepts, reports at milestones, returns structured output, one revision, exit. Communication budgets — one clarification, one final result, one failure report — keep coordination from becoming simulated workplace chatter. Push critical state changes; pull detailed evidence on demand.

Security

Trust, permissions, and shared memory

Every agent needs a real identity — role, owner, model, version, tools, permissions, budget — because “From: Finance Agent” in a text field is not authentication. The governing rule: an agent must not inherit another agent’s permissions through communication. When the research agent asks the finance agent for the full margin table, the finance agent checks requester identity, task purpose, and allowed scope — it does not comply because a peer asked. Delegation transfers a task, not all authority; the confused deputy appears when a low-privilege agent (say, a web researcher carrying a poisoned instruction) manipulates a high-privilege peer into acting; and cross-agent prompt injection propagates one poisoned document through research agent → manager → execution agent. Treat inter-agent messages as untrusted input. Shared tools enforce actor identity and per-call authorization themselves; private tools (margin simulator for finance, reservation tool for execution only) reduce selection confusion and excessive agency.

Memory splits the same way: private role memory (“Retailer A agreements are indexed under Holding B”), shared task memory (plan, evidence, decisions, open questions), and curated organizational memory that individual agents cannot publish into unilaterally. Write conflicts — agent A says capacity available, agent B says unavailable — need versioning, timestamps, source authority, and an explicit conflict state rather than silent overwrites. And one compromised agent can poison the shared workspace: write permissions, provenance, append-only history, and quarantine are the containment. Watch also for information leakage through shared state and artifacts, and — at scale — collusion: agents coordinating to hide errors or game evaluation, a risk Microsoft flags for autonomous agent populations. More communication is not always beneficial.

Reality checks

How agent teams fail

  1. 01Correlated errors. Shared model, training data, and sources mean confident agreement on the same mistake. Consensus is not proof; verify externally.
  2. 02Groupthink and anchoring. Later agents converge on earlier outputs. Run independent first passes before revealing peers’ work; randomize order.
  3. 03Authority bias. The agent labeled “senior expert” is trusted excessively. Labels are not evidence.
  4. 04Social loafing. Superficial work because another agent is expected to handle it. Clear ownership and output criteria.
  5. 05Coordination loops. A hands to B, B hands back to A. Handoff counters, ownership rules, loop detection.
  6. 06Delegation explosion. 1 → 5 → 25 → 125 subagents. Maximum depth, maximum agents, creation permissions, global budgets.
  7. 07Communication explosion and synthesis bottleneck. Fully connected topologies drown the synthesizer. Structured outputs, hierarchical summaries, limited worker scope.
  8. 08Lost minority insight. The dissenting result vanishes in synthesis. Require the synthesizer to report consensus, disagreement, and minority evidence.
  9. 09Cascading hallucination. Agent A invents a fact; B summarizes it; C builds the recommendation on it. Provenance, source-linked claims, independent retrieval — the failure MetaGPT’s structured procedures were designed against.
  10. 10Goal drift and local optimization. Specialists optimize incompatible local goals. Preserve the objective in shared state; global trade-offs are not a specialist’s call.
  11. 11Incorrect specialization. The web research agent asked for live inventory returns plausible, invalid numbers. Tool and source boundaries must be explicit.
  12. 12Premature synthesis and endless collaboration. Finalizing before critical work completes — or critiquing forever without improvement. Evidence matrices, completion criteria, budgets, maximum rounds.
  13. 13Inconsistent terminology. Two definitions of “uplift” meet at synthesis. Use a shared semantic contract.
  14. 14Duplicate and conflicting actions. Two agents reserve the same capacity; one cancels what another created. Task ownership, idempotency keys, execution locks, one execution owner.
Evidence

Observing and evaluating the team

Every task gets one parent trace with each worker’s trajectory, messages, artifacts, and costs nested beneath — plus an interaction graph(who talked to whom, how often) revealing bottlenecks, loops, and isolated agents. Coordination metrics track duplicated-work rate, handoff success, idle time, synthesis delay, and unresolved conflicts; contribution metrics track each agent’s accepted findings, corrections, and cost — never inferred from message count. Evaluation answers two separate questions: does the system complete the task, and does using multiple agents improve the result? The second requires a matched single-agent baseline — same model family, tools, data, and critically the same budget, because Anthropic found token usage explained much of the performance variation on hard research benchmarks. Separating architecture benefit from extra compute is the whole game.

Beyond outcomes, evaluate coordination (decomposition quality, coverage, overlap, stopping), collaboration quality, and both layers — an agent can excel while the team fails at synthesis, or a weak specialist can be saved by the evaluator. Run ablations (remove the evaluator, remove a worker, replace the team with one agent) to prove each agent adds value, compare topologies, stress test (one worker fails, returns malicious content, or conflicts), and run repeated trials — team behavior is non-deterministic too. The economics close the loop: quality gain + speed gain + control gain − coordination cost − inference cost − latency cost − operational risk. Cost per successful task, not cost per task.

Worked example

The Promotion-to-Profit team

The promotion task combines historical analytics, forecasting, finance, contract interpretation, and supply feasibility — spread across systems with different permissions, and largely parallelizable. A justified architecture: a commercial orchestrator over five specialists and an independent evaluator, feeding an approval workflow.

  • Commercial orchestrator: resolves entities, plans tasks, maintains shared state, synthesizes, prepares the approval packet. May not access raw finance tables, reserve capacity, send proposals, or approve.
  • Historical-performance agent: comparable promotions, uplift, cannibalization — returned as structured JSON with evidence IDs.
  • Demand-planning agent: baselines and scenario volumes with uncertainty. May not choose discounts or approve supply.
  • Contract agent: the current signed agreement — €68,000 fee, eight weeks’ notice, clause references — with access to Retailer A contracts only.
  • Finance agent: scenario simulations and sensitivity through approved models. No exposure approval, no external communication.
  • Supply-feasibility agent: inventory, capacity, deadlines. May not reserve or change plans.
  • Independent evaluator: checks evidence completeness, currency, assumption consistency, explicit conditions, and that no agent exceeded authority — with one revision request allowed.

All agents share one task contract (maximize incremental contribution, current contract, cannibalization included, no external action without approval). Historical, demand, and contract agents run in parallel; finance waits on their outputs; supply starts with inventory while waiting for volumes. When the historical agent reports 22% expected uplift and the demand agent 31%, the orchestrator does not average — it opens a reconciliation task, each agent explains its assumptions, and the final scenario carries a range instead of false precision. The finance result kills the 15% proposal (−€30,000 to +€3,000) in favor of 10% (€62,000–€94,000); supply adds the 20 August capacity condition; the evaluator verifies; and the system stops — creating structured approval requests for the commercial director, finance director, and planning manager. Analysis, recommendation, approval, and execution stay separated. This team may beat one agent through parallelism, focused context, permission separation, and independent review — or lose to it through inconsistent assumptions, coordination failures, and cost. Only the matched baseline comparison settles it.

Framework

Maturity, COORDINATE, and design process

The design process in twelve steps: define the business outcome (not “create a team of AI agents”); map the work; build the single-agent baseline; identify real separation points; choose the topology; define role contracts; design communication; define shared state; establish authority (who assigns, approves, executes, stops); add budgets and limits; instrument everything; and evaluate against the baseline before deploying.

LevelWhat it addsCharacteristics
0 · Agent-themed prompt chainNamed roles, fixed sequenceLittle reason for the word “agent”
1 · Predefined specialistsFixed agents, structured handoffsCentral coordinator, limited autonomy
2 · Parallel specialist teamIndependent workstreamsShared task state, artifact exchange, permission separation
3 · Dynamic orchestrationTask-specific workersAdaptive decomposition, budgets, evaluation agent
4 · Governed enterprise systemIdentities, least privilegePolicy-aware communication, tracing, approvals, failure isolation, ablation evaluation
5 · Coordination platformReusable agent registryCapability discovery, secure delegation, standardized protocols, org-wide observability
Six levels of multi-agent maturity

TiMiNa’s COORDINATE framework compresses the discipline into ten principles:

  1. 01Clarify the shared outcome. One objective, success criteria, and trade-offs that every agent works toward.
  2. 02Only split where separation creates value. Specialization, parallelism, context isolation, permission isolation, or verification — never decorative roles.
  3. 03Own every task and decision. Task, output, approval, execution, and incident owners. Distributed work must not create distributed accountability.
  4. 04Restrict tools, context, and authority. Least privilege, private tools, scoped delegation — communication must not transfer authority implicitly.
  5. 05Define communication contracts. Message types, schemas, evidence requirements, deadlines. No uncontrolled group chat.
  6. 06Isolate failure and untrusted input. Workers fail, peers err, documents lie, shared memory rots. Validate at every boundary.
  7. 07Normalize evidence and outputs. Structured findings, common definitions, source references, confidence labels — so the synthesizer compares like with like.
  8. 08Allocate effort according to complexity. Agent count, depth, and budgets scale with the task. Simple tasks do not get large teams.
  9. 09Trace interactions and test the team. Delegation, messages, artifacts, conflicts, costs — against a single-agent baseline.
  10. 10End collaboration deliberately. Completion criteria, maximum rounds, a stopping owner, and a policy for unresolved disagreement.

Ten principles for multi-agent AI systems

  1. 01Start with one agent. Add more only after observing a real limitation.
  2. 02Give every agent a reason to exist. Specialization, parallelism, isolation, or verification — not a job title.
  3. 03Treat coordination as a cost. Communication and synthesis consume resources and introduce failure.
  4. 04Preserve one shared objective. Specialists must not optimize incompatible local goals without global arbitration.
  5. 05Minimize free-form agent conversation. Use structured state, messages, and artifacts.
  6. 06Do not transfer trust through communication. Every agent and message is validated independently.
  7. 07Preserve evidence across handoffs. Avoid the game of telephone.
  8. 08Keep consequential execution centralized and controlled. Distributed analysis does not require distributed authority.
  9. 09Compare against a strong single-agent baseline. A more complicated system must earn its complexity.
  10. 10Optimize the team, not the individual agents. The measure is system outcome, not how intelligent each role appears.

Frequently asked questions

Is every workflow with several model calls multi-agent?

No. A fixed sequence of model calls is a prompt chain. Separate agents have distinct roles, context, tools, state, or decision responsibility.

Are multiple agents better than one?

Not automatically. They add cost, latency, communication overhead, state complexity, and new failure modes — the benefits must outweigh the coordination tax.

Should agents communicate in natural language?

Natural language is flexible but expensive and ambiguous. Structured messages, shared state, events, and artifacts are usually preferable in production.

Should all agents share the same context?

No. Share the core goal and necessary state; keep role-specific and sensitive information scoped.

How do you prevent agents repeating the same work?

Clear task boundaries, single ownership, shared progress state, structured delegation, and overlap checks before launch.

How do you resolve disagreement among agents?

Compare source authority, assumptions, and temporal validity — and preserve unresolved disagreement rather than forcing artificial consensus.

Can multiple agents reduce hallucinations?

Independent review and source verification catch some. Multiple agents can also propagate and amplify the same hallucination — independence is the deciding factor.

Are multi-agent systems more secure?

They can improve permission separation — while adding identities, communication channels, and attack paths. Security depends on the architecture, not the agent count.

What is the biggest multi-agent design mistake?

Creating many agents because the architecture sounds advanced, without demonstrating that distributed work improves the result enough to justify its coordination cost.

Conclusion

Multi-agent systems promise digital teams that divide work, specialize, run in parallel, and challenge one another — and the promise is real. But the analogy with human teams misleads: naming agents “researcher, strategist, analyst, manager, critic” does not create a high-performing organization. A functional system requires a shared objective, clear decomposition, distinct roles, scoped context and permissions, structured communication, conflict resolution, evidence-preserving synthesis, and verified outcomes. The benefits are specific — specialization, parallelism, context isolation, permission isolation, independent verification — and so are the costs: communication, duplication, latency, tokens, state complexity, failure propagation, and evaluation difficulty.

For predictable sequential work, use a workflow. For broad tool use, begin with one well-designed agent. For reusable expertise, a manager with specialists. For dynamic parallel exploration, orchestrator–worker. For large outputs, artifacts. For quality, focused critics. For high-impact actions, narrow authority and controlled execution. The strongest multi-agent system may contain three agents rather than thirty, use fewer conversations and more structured state, distribute analysis while centralizing authority — or decide that one strong agent is enough.

The defining question is not “how many agents can we create?” but: which parts of this work become meaningfully better when separated — and how will those parts coordinate without losing coherence, control, or accountability?

From guide to production

Want help choosing the right architecture for your process?

We map where agents create leverage in FMCG operations, then build and ship the ones that pay back. One call to pressure-test your highest-leverage use case.

All articles