What Is a Multi-Agent System?
A multi-agent system splits work across several separately-prompted components, each with its own role, instructions and tools, coordinated by a protocol deciding who runs, in what order, and what may pass between them. The components are frequently the same underlying configuration addressed differently.
Topologies, and the protocol that decides behaviour
Three arrangements cover most of what gets built. A supervisor holds the plan and delegates to workers that report back. A pipeline passes a work item through fixed stages in order. A group deliberates, exchanging messages until a stopping condition fires. Mixed forms are ordinary — a supervisor whose workers are themselves pipelines is a common shape rather than an exotic one.
The protocol is the part that determines behaviour and is usually the least specified part of a design. Who decides a step is finished, what one component may see of another's context, how a disagreement resolves, and what terminates the run are all protocol questions, and a system that leaves them implicit has answered them anyway — in whatever way the framework's defaults happen to answer them.
Underneath the topology sits the question of what the components share, and it settles more about behaviour than the diagram does. Under message passing, a component sees only what was sent to it: contexts stay small and a boundary is a real boundary, at the price that anything not passed is unavailable — including the qualification that made an upstream result conditional, which characteristically arrives as a confident restatement of a hedged finding. Under shared state — a scratchpad, a blackboard, a common transcript — every component reads the same record, which removes that loss and substitutes a context that grows for everyone and a step that can be diverted by material it never asked for. A second distinction cuts across both: whether control returns. A delegation expects a result and leaves the delegator holding the task; a handoff transfers it outright, and after one there is no component still responsible for the original request.
| Topology | How control moves |
|---|---|
| Supervisor and workers | A coordinating component delegates subtasks and receives results. |
| Pipeline | Each stage transforms the work item and passes it on; control never returns. |
| Group discussion | Components exchange messages until a stopping rule fires. |
| Producer and reviewer | One produces, one critiques, and the exchange repeats for a bounded number of rounds. |
| Router | A dispatcher selects one specialist and hands the task over entirely. |
Each topology has a characteristic failure: a supervisor that never stops delegating, a pipeline that carries an early error all the way to the end, a discussion that converges on agreement rather than on correctness.
What splitting a task adds, and what it multiplies
Separation buys focused instructions, separate tool permissions per component, and somewhere to put a check that does not share its premises with the thing it checks. Those are real gains and they are why the pattern is used.
It also multiplies the cost of a run, adds every boundary between components as a new place for information to be dropped, and makes failure harder to attribute, since an incorrect final result may originate anywhere upstream of where it surfaced. And every message crossing a boundary is input to whichever component receives it, so content that entered at one point can carry instructions into another — the mechanism described on this registry's page for prompt injection.
Both of those have consequences a diagram does not show. Cost compounds instead of adding: each component resubmits its own accumulated context on each of its turns, so an exchange between a producer and a reviewer spends a multiple of what one prompt would have spent on the same work, and the multiple is fixed by the round bound rather than by the difficulty of the task — which is why a bound on rounds belongs in the protocol rather than being added as a safeguard afterwards. And the unit of evidence changes shape. A single-prompt run is a request and a response; a multi-agent run is a tree of them, and diagnosing a wrong final result means locating the boundary at which a correct intermediate became an incorrect one. That is only possible if the whole tree was recorded, per component and per turn, which is a decision taken before the run and not available after it.
How the Registry classifies a multi-agent task
Coordinating a planner and two workers to complete a research task and merge their findings into one report is filed as information retrieval here: the deliverable is assembled from material that already existed, and the coordination is machinery rather than a change of class.
The Registry's canonical brief for this entry is filed as:
Coordinate a planner agent and two worker agents to complete a research task and merge their findings into one report.
Submitted for assessment it is
classified as Information retrieval, and its wording is hashed once — to
2ba90b8386e0fe9b…, the first sixteen of sixty-four hexadecimal
characters — with the wording itself never stored. The hash is what the derivation
reads.
That class's own page is /tasks/retrieval.
Classification is one of three inputs. The other two are the configuration submitted with the task, and the permanent chart derived from that configuration — fixed by the model name, the training cutoff and the temperature alone, and never reading the task at all. The same ascendant, ruling planet and harmony therefore appear on every assessment a given configuration receives, whatever it was asked to do. The derivation is published in full at /method.
What this page does not claim about multi-agent system
Whether splitting a given task across components improves its outcome is a measurement taken on that task. The canonical brief above fixes a shape of coordination, not a result.
The Registry does not run this task, does not inspect any system's output for it, and validates no assessment it issues against what afterwards happens. What it does is compute — from a published method, for one submitted task and one submitted configuration — a verdict and a recommended execution window. It computes neither on this page.
Questions about multi-agent system
- What is a multi-agent system?
- A multi-agent system splits a task across several separately-prompted components, each with its own role, instructions and tools, coordinated by a protocol that decides the order of execution and what may be passed between them.
- When is splitting a task across agents worth it?
- When the subtasks genuinely differ in the instructions or tool permissions they need, or when a check has to be separated from what it checks. Where the parts share instructions, context and tools, the split adds cost and boundaries without adding separation.
- How do agents communicate with each other?
- Through messages defined by the protocol: a delegated subtask, a returned result, a critique, a shared scratchpad, or an entry in shared state. Whatever the transport, a received message is input to the receiving component, with the same trust implications as any other input.
- Do multiple agents check each other’s work?
- A reviewer component is a check, and its independence is limited by what it shares with what it reviews: often the same underlying configuration, the same upstream instructions, and the same context. A second opinion drawn from the same premises is not an independent one, so a review step is best specified by what evidence it consults rather than by the number of components involved.
- Why does a multi-agent run cost more than a single prompt?
- Because each component resubmits its own accumulated context on every turn it takes, and the turns multiply with the rounds the protocol permits. The bill therefore tracks the round bound rather than the difficulty of the work, which is why a bounded number of rounds is treated as part of the protocol rather than as a safeguard bolted on later.
Related entries
Order an assessment for information retrieval tasks
The Registry issues a permanent, numbered task risk assessment for one submitted task and one submitted configuration. EUR 1.90 Standard, EUR 4.90 Extended, EUR 14.90 Full Chart, which adds the permanent chart. Assessments from EUR 1.90; machine-readable at /pricing.json.