More agents should earn their place
Parallelism is useful when the work separates cleanly and the coordination cost is justified.
A diagram with six agents can make a proposal look sophisticated. It can also represent six opportunities to repeat context, disagree, retry and lose ownership. Before adding another agent, I want to know what distinct responsibility it improves and how we will measure the improvement.
Let the work determine the architecture
The first question concerns the structure of the work. If the next step is known, a fixed workflow may be easier to test. If the next step depends on what the system discovers, an agent may be useful. Anthropic’s design guidance makes this distinction and recommends starting with simple, composable patterns. Anthropic — Building effective agents
Take an illustrative research brief assembled from approved internal sources. Parallel workers could independently inspect separate source collections and return evidence. A coordinator could combine those findings into a draft. That can be a sensible division because source reviews are separable and the output contract can be explicit.
Now imagine every worker receiving the full company knowledge base, searching the same documents and reviewing every other worker indefinitely. The names “researcher,” “critic” and “manager” do not make that efficient. Without boundaries, the pipeline can spend its budget discussing work rather than completing it.
Give each worker a contract
I would give each worker a narrow scope, an input contract, an output format, a source requirement and a budget. The coordinator should know what counts as a missing result, when to retry and when to continue with a visible limitation. Shared state needs an owner; competing writes need coordination outside a natural-language conversation.
An evaluator is useful when its criteria are specific enough to change a decision. Asking another model “does this look good?” can add confidence without adding evidence. For a research brief, checks might concern source coverage, unsupported claims, contradictions and whether the requested questions were answered. A person may still need to assess relevance to the business decision.
Compare against a simpler baseline
To choose the architecture, I would compare a single-agent baseline with the proposed multi-agent design on the same cases. Track accepted outcomes, elapsed time, total tokens, tool charges and review burden. Include failures and integration work. A speed improvement is less compelling if it creates more correction effort.
There are good reasons to use multiple agents: independent investigation, distinct tool environments, parallel implementation with clear ownership, or specialised evaluation. There are equally practical reasons to keep one agent inside a straightforward workflow.
My aim is a system the client can understand and maintain. Every additional agent should have a job that is necessary, bounded and observable. Architecture becomes more convincing when the team can explain what would get worse if that component were removed—and can show evidence that the added coordination is worthwhile.
For a review of agent architecture and workflow complexity, contact hi@fdo.codes.
