Here is an uncomfortable number. Enterprise deployments show agents hitting around 60% success on a single run, dropping to roughly 25% across eight runs. Nothing changed except that the agent had to be right repeatedly.
Adding more agents does not fix that on its own. Structure does. These are the patterns that hold up, and the specific way each one falls over.
Pattern 1: Pipeline
Agents run in a fixed sequence, each taking the previous one output. Extract, then classify, then draft.
Use it when the steps genuinely have an order. It fails when an early agent is confidently wrong, because every downstream step inherits that error and adds confidence to it.
Pattern 2: Fan-Out and Gather
One request goes to several agents in parallel, then a combiner merges the results. Excellent for research, comparison and anything embarrassingly parallel.
It fails when the combiner is an afterthought. If merging is just concatenation, you have built an expensive way to produce a long document nobody reads.
Pattern 3: Supervisor
A coordinating agent decides which specialist handles what, and owns the final answer. This is the most common enterprise shape, and Microsoft documents close relatives of it as sequential, concurrent, group chat, handoff and magentic patterns.
It fails when the supervisor becomes a bottleneck with no domain knowledge, routing badly and adding a full model call of latency to every step.
Pattern 4: Handoff
One agent transfers the whole conversation to another, the way a support rep escalates a ticket. Cleaner than a supervisor when specialisation is obvious and permanent.
It fails when context does not survive the transfer. The customer explains the problem twice and you have automated the thing everyone hates about call centres.
Pattern 5: Swarm and Debate
Peers work with shared state, or argue toward an answer. Genuinely useful for hard reasoning problems where a second opinion catches errors.
It fails when cost meets reality. Three agents debating burns three times the tokens for a task a checklist would have settled.
How to Choose Without a Whiteboard Session
| If the work is… | Use | Watch out for |
|---|---|---|
| Ordered and deterministic | Pipeline | Compounding early errors |
| Parallel and comparative | Fan-out | A lazy combiner |
| Varied and needs routing | Supervisor | Latency and bad routing |
| Cleanly specialised | Handoff | Lost context on transfer |
| Genuinely hard reasoning | Debate | Token cost |
The Rule Most Teams Learn Late
Start with one agent and more tools. Add a second agent only when you can name the specific thing the first one is bad at. Multi-agent architecture is a solution to a specialisation problem, not a substitute for good tool design.
Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, largely over cost, unclear value and weak controls. Elaborate orchestration is an efficient way to join that statistic.
Conclusion
Pick the simplest pattern that matches the shape of the work, then make failure visible. Log every handoff, every routing decision and every merge. When something goes wrong in a multi-agent system, the answer is almost never the model. It is a boundary where context got dropped or an error got promoted.
Frequently Asked Questions
How many agents is too many?
If you cannot explain in one sentence what each agent is uniquely good at, you have too many.
Do I need a framework for this?
Not initially. Most patterns are a few hundred lines of ordinary code. Frameworks earn their keep once you need tracing, retries and state across many workflows.
Why do success rates drop so much over repeated runs?
Errors compound. Small failure probabilities at each step multiply, and agents rarely notice they are already off track, which is exactly why checkpoints matter more than cleverness.