Technology

Multi-agent systems.
One outcome.

Multi-agent architectures are the default answer to a hard agent problem, and they are usually the wrong one. Here is when they genuinely help, and the cheaper thing to try first.

All Technology & Model Stack →

The unpopular opening

Most problems people reach for multi-agent to solve are single-agent problems with bad context engineering.

The reasoning usually goes: the agent is failing at a complex task, so decompose the task and give each part its own agent. It is intuitive, it maps onto how we organise humans, and it frequently makes things worse — because the original failure was not insufficient specialisation. It was that the agent lacked the right information at the right step, or had twelve tools where three would do, or was being asked to hold too much in one context window.

Splitting into agents does not fix any of that. It adds coordination overhead, multiplies token cost, introduces handoff points where context is silently dropped, and makes debugging dramatically harder — a failure is now somewhere in a graph rather than in a trace you can read top to bottom.

Try first: better retrieval so the agent has what it needs; fewer, better-described tools; explicit intermediate steps in one context; a stronger model for the hard step only. In our experience that resolves the majority of "we need multi-agent" situations, at a fraction of the complexity.

When it genuinely helps

Genuinely parallel work

Researching forty accounts, or analysing thirty documents independently. There is no coordination problem because the units do not interact — this is parallelism, and it is the clearest win available.

Hard trust boundaries

One agent may read customer PII, another may write to a public channel, and they must never be the same context. Separation here is a security control, not an optimisation, and it is the strongest architectural justification there is.

Adversarial review

A generator and a critic with genuinely different instructions catch errors a single pass does not. This works when the critic has a real basis for disagreement — a rubric, a test, a policy — and degrades into theatre when it is the same model asked to "check your work".

Context that will not fit

When the work genuinely exceeds a usable context window even after retrieval and compaction. Note that this bar has moved a long way: much of the multi-agent literature predates the context lengths now routinely available.

The two patterns

Supervisor.

One agent owns the goal and delegates sub-tasks to workers, each returning a result. Control is centralised, so the trace is readable and the stopping condition is unambiguous. The supervisor's context is the bottleneck — everything flows through it.
Handoff.

Agents transfer control to one another, each fully owning the interaction while it holds it. This suits routing — triage hands to billing hands to a specialist — and mirrors how support organisations work. The risk is context loss at each hop and, without a supervisor, loops that no one terminates.

In practice supervisor is the safer default. Handoff earns its place where a conversation genuinely changes owner and the previous agent has nothing further to contribute.

SUPERVISOR PATTERN

01

Request

goal + constraints
02

Supervisor

plans, delegates
03

Workers

parallel, isolated
04

Collect

results + failures
05 · Branch / escalation

Retry

bounded attempts
06

Synthesise

supervisor decides

Lower box = bounded retry pathMarker = one request

Retries are bounded and counted at the supervisor. An unbounded retry loop is the most common way a multi-agent system turns a transient error into a large invoice.

Where they break

Cost multiplication

Five agents on a task is not five times the tokens — coordination messages, repeated context and retries can push it well beyond five times. Model this before building, not after the first invoice.

Context loss at handoff

Each transfer summarises, and each summary loses the detail that mattered. Failures appear far downstream of the hop that caused them, which makes them expensive to diagnose.

Unbounded loops

Two agents can pass work back and forth indefinitely, each convinced the other should handle it. Hard iteration caps and a terminal fallback are not optional.

Questions

Questions about Multi-Agent Systems.

How do we know if we need multi-agent?

Build the single-agent version first and instrument where it fails. If failures cluster on a specific sub-task that would benefit from different tools or a different model, that is a signal. If they are spread across context problems — the agent not knowing something it should have known — multi-agent will not help, and the fix is retrieval.

Which framework should we use?

For simple supervisor patterns, plain code with a loop and a tool router is often clearer than a framework and much easier to debug. LangGraph is reasonable when the graph is genuinely complex and you want the state machine made explicit. Where reliability and retries across long-running steps matter, a durable execution engine like Temporal contributes more than an agent framework does.

How do we debug a multi-agent system?

Trace everything, with a correlation ID across the whole graph, and store every prompt and response. Without full traces, debugging is guesswork — this is the single largest practical cost of multi-agent architectures and the reason we push back on them by default.

Do agents need shared memory?

Usually less than people expect. Shared mutable state between agents reintroduces every concurrency problem you know from distributed systems, now with a non-deterministic actor. Passing explicit results, and keeping durable state in a normal database with normal transactions, is simpler and more reliable than a shared memory abstraction.

When agents cross platform boundaries.

For work owned by another system, our A2A interoperability guide explains task contracts, identity and failure handling. For the execution loop within one application, explore managed agent runtimes and the September 2026 Agents API release.