The First Version Was Too Naive
The first wave of multi-agent systems was mostly theatre. People imagined a room full of autonomous agents debating, writing, reviewing, planning, and magically converging on the right answer.
In practice, it usually broke.
The problem was not that the models were stupid. The problem was that every agent made its own hidden decisions. One agent chose a style. Another chose a different edge case. A third invented a slightly different interpretation of the task. By the end, the system had many pieces of work, but no single mind holding the product together.
This is why most useful agent systems stayed simple for a long time. One agent did the work. Other tools helped with search, retrieval, or analysis. It was not very glamorous, but it was much easier to trust.
Parallel Work Creates Parallel Decisions
The hard part of software is rarely typing code. The hard part is making decisions.
When multiple agents write at the same time, they do not just produce more code. They also produce more decisions. Some of those decisions are explicit, but many are hidden inside the implementation.
This is where systems become fragile.
An agent deciding how to handle permissions is making a product decision. An agent choosing what error state to show is making a UX decision. An agent deciding which abstraction to reuse is making an architecture decision.
If five agents make those choices independently, you do not get five times the output. You get five competing versions of the product.
The Pattern That Works
The practical pattern is not a swarm. It is a manager.
One agent should own the main thread of work. It holds the user goal, the plan, the tradeoffs, and the final decision-making. Other agents can help, but they should contribute intelligence before the main agent takes action.
This gives you the benefit of multiple perspectives without fragmenting ownership.
A reviewer can inspect the diff with fresh eyes. A research agent can find missing context. A stronger model can be called in when the primary agent is uncertain. A planning agent can challenge the approach before implementation begins.
But the write path should stay narrow.
This is the difference between collaboration and chaos. The system can use many minds, but it still needs one place where judgment is synthesized.
Clean Context Is a Feature
One of the most counterintuitive lessons is that agents often perform better when they do not share all the same history.
This feels wrong at first. We assume that more context means better decisions. But context has a cost. Long conversations carry old assumptions, failed attempts, irrelevant details, and half-resolved ideas. The agent has to keep reading all of it and decide what still matters.
A reviewer with clean context can be sharper because it starts from the actual output. It does not know the emotional history of the task. It does not remember why the first approach failed. It simply looks at the result and asks: does this work?
That distance is useful.
The same applies to planning and debugging. Sometimes the best agent is not the one that has seen everything. It is the one that sees only the right slice of the problem.
Review Loops Are Underrated
The most boring multi-agent pattern is also one of the most useful: one agent builds, another reviews.
This works because generation and verification are different jobs. The builder is deep in the task. It carries the plan, the constraints, and all the small compromises made along the way. The reviewer can come in cold and look for logic errors, missing edge cases, security problems, and places where the implementation does not match the intent.
The important part is not that the reviewer is always right. It is not.
The important part is that the main agent has to synthesize the feedback. It should not blindly apply every comment. It should compare the review against the original goal, reject out-of-scope suggestions, and fix the real issues.
This is where the manager pattern matters again. Review is intelligence. The main thread still owns judgment.
The Smart Friend Pattern
Another useful pattern is giving a working agent access to a smarter or more expensive model only when needed.
Most tasks do not need the strongest possible model at every step. A smaller or faster model can handle routine work. But sometimes the task becomes tricky: a deep architecture question, a confusing bug, a merge conflict, a security-sensitive change, or a decision with unclear tradeoffs.
In those moments, the agent can call a "smart friend."
This sounds simple, but the hard part is calibration. A weaker agent needs to know when it is out of its depth. It also needs to ask the right question and send enough context for the stronger model to help.
If it sends too little, the answer is generic. If it sends everything, the stronger model inherits the same messy context. If it asks the wrong question, it may get a confident answer to the wrong problem.
This is why multi-agent systems are mostly context engineering. The value is not just in having another model available. The value is in designing the handoff.
Swarms Are Mostly a Distraction
The internet likes the idea of agent swarms because it looks futuristic. Many agents talking to each other sounds like intelligence at scale.
But most real work does not need a swarm. It needs coordination.
A useful system looks more like a product team than a crowd. There is a clear owner. Work is split into understandable pieces. Each contributor has a defined role. Discoveries are reported back. Someone decides what matters.
This is especially true in software, where success is not only "does it compile?" The real question is whether the result matches the product taste, business goal, existing architecture, security model, and user experience.
Those things do not emerge automatically from a crowd of agents. They need direction.
The Real Bottleneck Is Communication
The open problems in multi-agent systems are not only about model intelligence. They are about communication.
How does one agent tell another what matters without dumping the entire context? How does a child agent surface a discovery that should change the plan? How does a reviewer point out a real bug without pulling the implementation away from the user request? How does a smaller model know when to escalate?
These are product questions as much as technical questions.
The best systems will not be the ones with the most agents. They will be the ones with the cleanest handoffs, the clearest ownership, and the best judgment about when to bring in another perspective.
Coordination Over Swarms
Multi-agent systems are becoming useful, but the useful version is more disciplined than the popular version.
Do not build a swarm first. Build a single strong agent with clear ownership. Then add other agents where they improve the work: review, research, planning, debugging, testing, or escalation to a stronger model.
Keep writes controlled. Keep context clean. Treat handoffs as architecture.
The future of agent systems is not a hundred independent workers making their own decisions. It is a coordinated system that scales judgment without losing coherence.