How it works
A multi-agent system decomposes a task into roles and hands each role to an agent with its own instructions, tool surface, and context window. Coordination is the actual design work; the agents are almost secondary.
Most production systems settle on one of two coordination shapes:
- Orchestrator-worker. A lead agent plans, splits the task, dispatches subtasks to workers, and merges their results. Control stays centralized, which makes the flow legible and easy to gate.
- Peer / handoff. Agents pass control laterally through a shared protocol or message bus, each deciding when to act or defer. This is more flexible and much harder to reason about.
Inside either shape, a single step runs the familiar loop: read context, choose a tool, act, observe, decide whether to continue. What changes is that outputs become inputs for a different agent. So the real substrate of a multi-agent system is the interface between agents — what context is passed, what is summarized away, what a worker is allowed to touch, and how its result is validated before it propagates. Get those interfaces wrong and you have not built a team; you have built a rumor mill where one agent's guess becomes another agent's premise.
Why it matters in an agent harness
More agents is not more capability by default — it is more surface to control. A harness should treat every added agent as an added blast radius and an added failure mode, then justify it.
The cases where splitting genuinely pays:
- Isolation of authority. A worker that only reads and a worker that can write should not share a context window or a permission boundary. Separate agents let you scope tools per role, so the researcher literally cannot deploy.
- Context hygiene. A long task pollutes a single window with dead ends. Handing a clean subtask to a fresh agent keeps each context focused and reduces drift.
- Parallelism on separable work. Independent subtasks (survey three sources, draft three sections) fan out cleanly when there is no shared mutable state.
- Containment. A failing worker fails locally. The orchestrator can retry, reroute, or drop the branch without corrupting the whole run.
All of that only holds if the harness stays in charge of the seams: typed handoffs, per-agent tool scopes, a checkpoint before any worker with write access acts, and an evaluator on the merged result. Without those, multi-agent architecture mostly multiplies the ways a run can go wrong while hiding where it went wrong.
Multi-agent system vs a single-agent loop
Reach for multiple agents to isolate authority or context — not to feel more capable. A single agent with good tools and a tight loop beats a committee for most tasks.
| Dimension | Single-agent loop | Multi-agent system |
|---|---|---|
| Coordination cost | None | Real; grows with agent count |
| Permission scoping | One tool surface | Per-role, tightly scoped |
| Failure containment | Whole task fails together | Fails per branch |
| Debuggability | One trajectory to read | Many trajectories plus their seams |
| Best fit | Cohesive, sequential work | Separable subtasks, split authority |
The honest default is the single loop. Add agents when you can name the specific isolation or parallelism you are buying, and when you can afford to instrument the handoffs.
The Rifty take
We optimize for containment and legibility, not for the appearance of a team. An agent earns its place by isolating a permission boundary, a context, or a separable subtask — never because org-chart-shaped systems feel more capable. We accept the coordination cost only when the seams are typed, gated, and observable, and we default to the smallest agent count that does the job. The interesting engineering lives in the handoff, not in the headcount.
Common failure modes
- Hallucination propagation. A worker's unverified guess enters another agent's context as fact. Validate results at the seam before they propagate.
- Coordination overhead swamps the benefit. Two agents spend more tokens negotiating than one would spend just doing the work.
- Permission leakage. A worker inherits broader tool scope than its role needs, erasing the isolation that justified the split.
- Lost observability. No single trajectory to read; a failure hides in the messages between agents, which most traces don't capture.
- Shared mutable state. Parallel agents write the same resource and race, producing nondeterministic, unreproducible runs.
- Missing checkpoint before write. A worker with side effects acts with no rollback point, so a bad branch can't be cleanly undone.
- Unbounded fan-out. No cap on spawned agents or iterations, and cost and latency drift without a ceiling.
Frequently asked questions
When should I use a multi-agent system instead of a single agent?
Use multiple agents when you can name a concrete reason: isolating a permission boundary, keeping contexts clean, or running separable subtasks in parallel. If a single agent with good tools handles the task cohesively, keep it single — added agents add coordination cost and failure surface, not capability by default.
What is the difference between orchestrator-worker and peer coordination?
Orchestrator-worker centralizes control: a lead agent plans, dispatches subtasks, and merges results, which keeps the flow legible and easy to gate. Peer coordination passes control laterally between agents through a shared protocol. Peer designs are more flexible but much harder to reason about, debug, and contain when something fails.
How do I keep a multi-agent system observable?
Instrument the seams, not just the agents. Log every handoff — what context was passed, what was summarized away, and what result crossed the boundary — so failures between agents are visible. Without seam-level tracing, a bad output hides in the messages between agents, and no single trajectory explains the run.
What is the biggest risk unique to multi-agent architectures?
Hallucination propagation: one agent's unverified guess enters another agent's context as an accepted premise, then compounds downstream. Contain it by validating results at each seam before they propagate, scoping tools per role, and checkpointing before any worker with write access acts, so a bad branch fails locally and can be rolled back.
Do more agents make an agentic system more reliable?
Not inherently. More agents mean more surface to control and more ways a run can fail, unless the harness governs the seams with typed handoffs, per-role permissions, checkpoints, and result evaluation. Reliability comes from containment and legible interfaces, not headcount; the smallest agent count that works is usually the most reliable one.