Multi-Agent Systems: Use Cases and Limitations
Multi-agent systems work for read-heavy, parallelizable tasks such as research, retrieval, and exploration.
The Scaling Instinct Behind Multiple Agents
Multi-agent systems attract attention because they seem to promise a simple kind of scaling. If one agent can do useful work, it feels natural that several agents working together should do more. When a task looks too large or too complicated for a single agent, many teams reach for this idea first. This article examines that instinct. The short version is that the number of agents is not what decides whether a multi-agent design works. What decides it is less visible, and it is the part teams most often neglect.
Tracing Where Shared Context Lives
Shared context is the information that agents rely on in order to act consistently with one another. When several agents work on a task, the quality of the final result depends heavily on whether each agent can access and build on what the others have done. Follow one piece of information through a small team of two agents and a shared context store. Agent A does part of the work and records what it did. Agent B then reads that record and builds on it. The final result is only as coherent as this movement of information allows.
Notice what the diagram makes visible. The shared context is the path along which one agent's change reaches the others. If that path is weak or expensive to use, the agents cannot act on each other's work in a consistent way, no matter how many of them there are. This is why the source places the design effort on the context rather than on the head count.
Two Families of Tasks
The source sorts tasks into two broad families. The first family is read-heavy and parallelizable, and its examples are research, retrieval, and exploration. The second family is write-heavy and stateful. For this second family the source is blunt: multi-agent setups fail badly, because sub-agents cannot cheaply share context. The distinction turns on what the agents must do with shared information, not on how large the task is. A huge research job can still be a read-heavy job, and a small task can still be write-heavy and stateful.
| Aspect | Read-heavy, parallelizable | Write-heavy, stateful |
|---|---|---|
| Typical examples | Research, retrieval, exploration | Work that must keep one shared state consistent as it changes |
| What agents do with shared information | Gather or examine it | Modify it as they act |
| How results come together | Combined afterward without repeatedly changing a common record | Agents must keep the shared state consistent while they act |
| Fit for multiple agents | Good fit according to the source | Poor fit: sub-agents cannot cheaply share the context this requires |
The two task families as the source describes them
Read the two columns as a contrast in what the agents need from each other. In read-heavy work, agents gather or examine information, and their results can be combined afterward without each agent repeatedly changing a common record. In write-heavy, stateful work, agents must keep a shared state consistent as they act, and the source says that sub-agents cannot cheaply share the context this requires.
Watching Two Agents Write to One State
Two agents updating the same record
Two agents both need to update one shared value, which currently reads 100. Agent A is supposed to subtract 30 and Agent B is supposed to subtract 50. Both start from the same view of the shared state. What value should the record hold at the end, and what can go wrong?
- 1Both agents read the same starting state
Each agent sees the shared value as 100 before either has written. Neither agent knows yet what the other is about to change.
- 2Each agent computes its own update
Agent A computes 100 minus 30, which is 70. Agent B computes 100 minus 50, which is 50. Each is correct relative to the view it started with.
- 3The writes land in some order
Whichever write is applied last determines the stored value. If Agent B writes last, the record holds 50 and Agent A's change is silently lost, even though both agents did their own arithmetic correctly.
- 4Compare with the intended result
The intended result of both changes applied together is 20. The stored value is not that, because the agents did not share their updates cheaply enough to build on each other.
The final value depends on which write lands last, and an update can disappear without any agent making an obvious error. This is the kind of behavior the source describes when it says that sub-agents cannot cheaply share the context that write-heavy, stateful work needs.
Why Adding Agents Adds Connections
The source's central claim is that the effectiveness of a multi-agent system depends on the engineering of its shared context. The number of agents is not the lever. Think of what a new agent brings to a team. It can do work, but it also has to access and build on what the others have done. Each additional agent therefore adds dependencies on the shared context rather than adding a clean, independent source of progress. This is why a design that performs poorly is not automatically helped by more agents. A larger team can simply have more places where information fails to move consistently.
The source also notes that designs ignoring shared context behave erratically in production. This is the practical consequence of treating context as an afterthought. A system can appear to work during a controlled presentation, then produce inconsistent results once real inputs and real timing enter the picture. A demonstration tends to hide the timing and input variety that expose weak context handling.
Mistakes in Multi-Agent Design
Common mistake Treating agent count as the main way to improve results
Why it failsThe source says the number of agents is not the lever for effectiveness. Adding agents without fixing shared context adds dependencies rather than capacity.
Do this insteadWhen a design performs poorly, examine how agents share context before deciding to add more of them.
Common mistake Trusting a strong demonstration as proof of production behavior
Why it failsDesigns that ignore shared context may look impressive in a demonstration but behave erratically in production, once real inputs and timing appear.
Do this insteadTest the design under realistic inputs and timing, not only under a controlled showcase.
Common mistake Assuming a large task is automatically a good fit for several agents
Why it failsThe source's distinction depends on what agents must do with shared information, not on task size. A large read-heavy task fits multiple agents; a small write-heavy one may not.
Do this insteadClassify the task by whether agents read and combine, or write to shared state.
Common mistake Ignoring that concurrent writes to one state can silently overwrite each other
Judging a Proposed Task
- 1Ask whether the agents mainly gather, examine, or retrieve information. If so, the task leans toward the read-heavy, parallelizable family.
- 2Ask whether the results can be combined afterward without each agent repeatedly changing a common record. If yes, multiple agents are a reasonable fit.
- 3Ask whether the agents must modify one shared state as they act and keep it consistent. If yes, the task leans toward the write-heavy, stateful family.
- 4For write-heavy work, ask whether sub-agents could cheaply share the context they need. The source says they cannot, so this is a warning sign for a multi-agent design.
- 5Decide on the basis of these structural answers, not on how large or impressive the task sounds.
A team wants several agents to each update a shared project plan, where every edit must stay consistent with the others. Using the steps above, decide whether this is a good or poor fit for a multi-agent design, and explain which source claim supports your decision.
Hints
- Ask whether the agents read and combine, or modify shared state as they act.
- Recall the source's statement about sub-agents and cheaply shared context in write-heavy, stateful work.
Prediction Check: More Agents or Better Context
What do you think happens?
A team has a multi-agent design that performs poorly on a task. They can either double the number of agents or redesign how the agents share the context they work from. Which change is more likely to matter, and why?
Reveal answer
Redesigning how the agents share context is more likely to matter, because the source says the lever for effectiveness is the engineering of the shared context, not the number of agents.
Doubling the agents adds more connections to a context that may already be failing to move information consistently. Improving the shared context changes the path that determines whether agents can act on each other's work.
Key Takeaways
- Adding more agents does not reliably improve a multi-agent system. The source identifies the number of agents as the wrong lever for effectiveness.
- Shared context is the design lever. Its engineering determines whether agents can act consistently on each other's work.
- Read-heavy, parallelizable tasks such as research, retrieval, and exploration suit multi-agent designs, while write-heavy, stateful tasks fail badly because sub-agents cannot cheaply share context.
- The task's structure, meaning whether agents read and combine or modify shared state, decides fit. Task size does not.
- Designs that ignore shared context may look impressive in a demonstration but behave erratically in production.