Multi-Agent Systems in Production: A2A, Orchestration and Real Costs

Multi-agent systems split a job across several AI agents, each with its own instructions, tools and context, coordinated by code or by another agent. In 2026 the idea has two concrete supports: a maturing standard for agents to talk to each other (the Agent2Agent or A2A protocol) and published evidence of where multi-agent designs beat single agents and where they waste money.

The short version: multi-agent setups work well for broad, parallel work such as research across many sources, and for crossing organisational boundaries where each side runs its own agent. They work poorly when every step depends on the last, and they cost several times more in tokens than a single agent.

This guide covers the A2A protocol, the orchestration patterns that hold up in production, what real systems have measured, and a decision framework for whether you need more than one agent at all.

What "multi-agent" actually means

The term is used loosely, so it helps to separate three things.

• One agent with many tools. A single model loop that calls tools until a job is done. This is what most production "agents" are, and it is often enough.
• Several agents inside one system. An orchestrator delegates sub-tasks to worker agents, each with a narrower prompt and toolset, then combines results. You own all of them.
• Agents across boundaries. Your agent asks a supplier's, insurer's or partner's agent to do something. Neither side sees the other's internals. This is the problem A2A was built for.

If you are still deciding whether a single bounded agent fits your business, start with our post on AI agents for small business. This post assumes you are past that point.

The A2A protocol: what it is and where it stands

Google announced Agent2Agent in April 2025 with more than 50 partners and moved it to the Linux Foundation in June 2025 under an Apache 2.0 licence. On 9 April 2026, the Linux Foundation reported that more than 150 organisations support A2A and that version 1.0, the first stable specification, had shipped with multi-tenancy, updated security flows and a migration path for early adopters.

Cloud support matters for adoption. Microsoft has built A2A into Azure AI Foundry and Copilot Studio, and AWS supports it through Amazon Bedrock AgentCore Runtime. A related protocol, AP2 (Agent Payments Protocol), extends the model to agent-initiated payments and has more than 60 supporters in payments and financial services.

The core ideas are simple:

• Agent Cards describe what an agent can do, how to reach it and what authentication it needs. In v1.0, cards can be signed so a caller can verify the agent's identity cryptographically.
• Tasks are the unit of work. A client agent sends a task, the remote agent works on it, and status and results flow back, including for long-running jobs.
• Opacity is deliberate. The remote agent does not expose its prompts, tools or memory, only its declared capabilities and outputs.

A2A vs MCP: complementary, not competing

A practical rule: use MCP to give your agent hands, and A2A to let it ask someone else's agent for help. Our guide to the Model Context Protocol for business covers the MCP side in depth.

Orchestration patterns that hold up in production

Most working systems use one of a handful of patterns. Choose the simplest one that fits.

Notice that only one pattern, orchestrator-worker, is "multi-agent" in the full sense. Routers and pipelines are deterministic code with LLM steps, and they are often more reliable because of it.

What a real multi-agent system measured

The most detailed public account comes from Anthropic's write-up of its multi-agent research system, which uses a lead agent that spawns parallel subagents to search and summarise.

The findings are worth knowing before you design anything:

• On Anthropic's internal research evaluation, the multi-agent setup outperformed a single agent using the stronger model by 90.2%.
• In their analysis, token usage alone explained about 80% of performance variance. Multi-agent designs work partly because they spend more tokens across separate context windows.
• That spending is real: agents used about 4 times the tokens of a chat interaction, and multi-agent systems about 15 times.
• The authors say most coding tasks, and domains where agents must share the same context or have many dependencies, are poor fits today.
• Rewriting unclear tool descriptions cut task completion time by 40%, and running 3-5 subagents in parallel cut research time by up to 90% on complex queries.

When not to use multiple agents

Gartner predicted in June 2025 that over 40% of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. Over-engineering is a common route to all three.

Skip multi-agent designs when:

• The job is a sequence where each step needs the full result of the previous one.
• A deterministic workflow with one or two LLM steps would do the job. Tools like n8n handle this well; see our post on n8n workflow automation.
• The value per task is low, such as answering routine FAQs.
• You cannot yet evaluate a single agent reliably. Adding agents multiplies the ways things fail.
• Latency matters. Coordinating agents adds round trips, which hurts voice and chat experiences.

Engineering for production

Multi-agent systems fail in ways single prompts do not. Plan for these from day one.

• Budgets. Cap tokens, tool calls and wall-clock time per task and per subagent. Kill runaway loops automatically.
• Explicit delegation. Give each worker a clear objective, output format, tool list and boundaries. Vague delegation produces duplicated work.
• Checkpoints. Persist the plan and intermediate results so a failure resumes from the last good step instead of restarting.
• Idempotent tools. A retried worker must not book the same appointment twice. Use idempotency keys on every write.
• Tracing. Record every agent span, tool call and handoff with timing and cost. OpenTelemetry's generative AI conventions now define agent and tool spans for this.
• Evaluation of outcomes. Judge the final result, not whether the agent followed a particular path. Different valid paths are normal. Our guide to LLM evaluation and observability explains how.

Securing traffic between agents

When your agent talks to someone else's agent, you inherit a new trust problem. The remote agent's answer is untrusted input, exactly like a web page or an email, and it can carry instructions meant to redirect your agent.

Treat cross-boundary agent traffic the way you would treat a partner API, with a few additions:

• Verify identity. Use signed Agent Cards and mutual authentication, and keep an allow-list of agents you are willing to call.
• Constrain what you send. Share only the fields the task needs. A referral request to a diagnostic partner's agent needs the test and slot, not the full patient history.
• Validate what comes back. Check responses against an expected schema and business rules before acting on them. A booking confirmation without a valid reference number is a failure, not a success.
• Never let a remote agent trigger irreversible actions directly. Its output should feed your own decision logic, with human approval for payments or anything external.
• Record the exchange. Store the task, the response and who approved the follow-up action, so disputes can be resolved later.

A worked example makes this concrete. Imagine a hospital group whose intake agent books outsourced imaging through a partner centre's agent. The intake agent sends an A2A task with the scan type, preferred dates and a referral ID. The partner agent replies with available slots. The intake agent checks the slots against the patient's OPD schedule, a staff member confirms, and only then does the booking task go out. Each side keeps its own systems private, and each side keeps control of its own commitments.

How to start

1. Build the single-agent version first and measure it on a fixed test set.
2. Find where it fails. If failures come from too little breadth (missed sources, shallow coverage), parallel workers may help. If they come from wrong reasoning or bad data, more agents will not.
3. Add the smallest change: often a router or a pipeline step, not a full orchestrator.
4. If you do add an orchestrator, start with 2-4 workers and strict budgets, and compare cost per successful task against the single agent.
5. Use A2A only where you genuinely cross a boundary, such as a partner's agent or another business unit's platform.
6. Ship behind a feature flag and shift traffic gradually.

Cost is mostly driven by token volume and engineering time for orchestration, observability and evaluation. A focused multi-agent pilot on an existing data foundation is typically a matter of weeks; most of the effort is in evaluation and guardrails rather than the agents themselves. Algon's AI agent development work usually starts with that single-agent baseline so the case for more agents is measured, not assumed.

Conclusion

Multi-agent AI has moved from demos to standards and production systems. A2A v1.0 gives agents a common way to work across organisational lines, and real systems show that parallel agents can deliver much better results on broad tasks.

The same evidence shows the cost: many times the tokens of a chat, more failure modes, and harder debugging. Use multiple agents when the task is valuable and parallel, keep one agent when it is not, and measure both before you decide. If you want help designing that comparison, talk to our AI development services team.