> ## Content Index
> Fetch the complete content index at: https://cms.syntrigen.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Multi-agent systems are usually one agent and a queue
- URL: https://cms.syntrigen.com/multi-agent-systems-are-usually-one-agent-and-a-queue/
- Published: 2026-03-11T09:00:00.000Z
- Updated: 2026-08-20T12:48:35.000Z
- Description: Most problems described as needing a team of collaborating agents need one competent agent, a work queue, and a way to hand off to a person. The orchestration is the easy part to add and the hard part to debug.
- Author: Syntrigen
- Tags: Agent architecture, Architecture

There is a diagram that appears in almost every AI proposal now. Boxes labelled Researcher, Planner, Critic and Executor, arrows between them, sometimes a Supervisor above. It is an appealing picture because it maps onto how a team works, and organisations understand teams.

It is also, most of the time, considerably more machinery than the problem requires.

## What the extra agents are usually doing

Look closely at a working multi-agent system and the sub-agents frequently turn out to be one of three things.

**A prompt boundary.** The Critic exists because putting "now check your work" in the same prompt produced worse results than a separate call. That is a real finding, and it is a two-call pipeline, not a multi-agent system. Naming it an agent adds a mental model without adding capability.

**A retry with different instructions.** The Planner failed, so the Supervisor sends it back. This is a retry loop with a variable prompt. Implemented as agent negotiation, it becomes very hard to answer "how many attempts did this take and why did it stop".

**A queue.** The Executor picks up tasks the Planner produced. That is a work queue. Queues are a solved problem with forty years of operational tooling, and re-implementing one as inter-agent messaging discards all of it.

## Why the framing costs you

**Failure attribution gets much harder.** When a five-agent run produces a wrong answer, the question "which step was wrong" has five candidate answers and no clear boundary between them. Each agent's input is the previous one's output, so an early misinterpretation arrives at the end looking like a late reasoning failure.

**Cost becomes unpredictable.** Each hop is a model call. A supervisor that can loop has no natural bound. The first bill that includes a run which went round nineteen times is a memorable one.

**Latency compounds.** Five sequential calls at two seconds each is ten seconds before any tool executes. Users notice.

**Evaluation loses its grip.** You can evaluate a step. Evaluating an emergent conversation between five components, where the same input can take different paths, requires either enormous sample sizes or accepting that you are not really measuring.

## The version that usually wins

One agent with a good tool set, a durable queue for work it produces, deterministic code for anything that can be deterministic, and an explicit escalation path to a person.

Concretely: the agent reads the input, calls tools, and produces either a result or a typed refusal. Work it cannot finish goes on the queue with the reason attached. A person sees the queue. Every tool call is logged with resolved arguments.

This is duller and it has properties the diagram does not: a bounded number of calls per item, a cost you can multiply out in advance, one place where failures land, and a step boundary you can evaluate.

## When more than one agent is genuinely right

Not never. Two cases hold up.

**Genuinely different tool scopes.** If one part of the work needs read access to finance systems and another needs write access to a CRM, separate agents with separate credentials is a security boundary, not a diagram. That is a good reason.

**Genuinely parallel work.** Ten documents, ten independent extractions, fan out and collect. That is parallelism, it is worth doing, and it needs no supervisor — a map over a queue does it.

The distinguishing feature of both: they are justified by a constraint, not by resembling an organisational chart.

## The question to ask a proposal

For each agent on the diagram: what can it do that the others cannot, and what would break if its work were a function call instead?

If the answer is "nothing, and nothing", you have found a pipeline wearing a costume — and pipelines are much easier to keep running.