When I first started reading about multi-agent AI, the demos looked convincing. A manager agent handed research to one specialist, another checked numbers, a third wrote the answer, and the whole thing returned with the neatness of a finished project.

I also felt slightly suspicious.

Software rarely becomes reliable because its components have job titles. Calling one agent a researcher and another a reviewer makes an architecture diagram easier to understand, but the awkward questions remain. Who can access which data? What happens when two agents disagree? Which one is allowed to spend money, edit a file or send an email? How do you trace a mistake when the final answer sounds perfectly reasonable?

That is the more interesting multi-agent story. Not a tiny office operating inside a computer, but an engineering decision about when a complicated task genuinely deserves to be divided.

The research example changed my mind a little

Anthropic built its research feature around a lead agent that delegates work to several subagents. Those agents search separate directions in parallel and return their findings for synthesis.

The company reported that this approach performed much better than a single agent on broad research tasks, particularly when a question could be broken into independent lines of investigation. It also consumed considerably more tokens, which is the kind of detail that disappears from demos but turns up quickly in a product budget.

This is a sensible use of multiple agents. A market-research task might separate into regulation, competitors, customer behaviour and technology trends. Running those investigations in parallel can produce broader coverage than asking one system to finish them sequentially.

I had expected coding to be the obvious showcase for agent teams. It is often a less comfortable fit because changes depend on one another. Two agents editing nearby parts of a codebase can create more cleanup than progress. Research may be messy in content, but it is sometimes cleaner to divide.

A refund that should have been simple

Consider an online order where the payment succeeded, but the account still shows the order as unpaid.

The company could give the case to one agent with access to billing, order history, support policy and email. It could also divide the work. A billing agent checks the payment processor. An order agent looks for a failed database update. A policy agent decides whether an immediate refund is allowed. Another drafts the reply.

The second setup sounds more advanced, and it may be safer if permissions are narrow. The writing agent should not be able to issue refunds. The policy agent probably does not need full payment details.

Then the payment processor says “authorised,” the order system says “pending,” and the refund policy was changed three days ago but has not reached the retrieval system.

The agents have not removed the uncertainty. They have distributed it.

Human colleagues can notice that a case feels unusual and ask finance what changed. AI agents need explicit routes, stopping rules and escalation points. Somebody still has to design all of that.

More agents can be an expensive way to feel modern

OpenAI’s guidance recommends getting as much as possible from a single agent before introducing a multi-agent architecture. Several agents can help when instructions or tool choices become too complicated, but they also add orchestration overhead and make maintenance and evaluation harder. A single agent with carefully designed tools is often enough.

I agree with that position, probably more strongly than the fashionable view allows.

A calendar assistant does not automatically need separate scheduling, timezone, attendee and meeting-room agents. It may only need reliable access to calendars and contacts, plus a clear approval step before invitations are sent.

There is a mild status issue here. “Multi-agent platform” sounds newer than “carefully designed workflow.” The second system may be cheaper, faster and easier to debug, but it does not look as exciting on a launch slide.

Software has been through versions of this before. A useful architecture becomes popular, teams apply it to almost everything, and a few years later they begin removing it from places where it never belonged.

The reviewer might share the same blind spot

A common design uses one agent to produce an answer and another to review it. It feels reassuring because the second system appears to offer independent judgment.

That independence can be thinner than it looks. If both agents use similar models, receive the same incomplete context and rely on the same sources, the reviewer may approve the original mistake. It might even rewrite the answer more neatly, making the problem harder to notice.

A useful reviewer needs a different responsibility, not merely a different label. It should inspect original evidence, apply explicit failure criteria and be allowed to reject the output entirely.

For sensitive actions, human approval still makes sense. Microsoft’s agent framework supports explicit orchestration, workflow state and recoverable handoffs, reflecting a broader move toward controlled processes rather than agents exchanging messages until something looks complete.

Debugging becomes part of the product

Suppose a final report includes the wrong market figure. The error may have started with a weak search query, a poor source, an over-compressed handoff or a lead agent combining two different definitions of revenue.

Looking at the finished paragraph will not reveal much.

A production system needs records of tool calls, intermediate outputs, timing, costs and decisions. It also needs evaluation cases that resemble the untidy requests users actually submit. Anthropic recommends combining automated evaluation, production monitoring and human review instead of judging an agent from a handful of successful demonstrations.

This work receives less attention because screenshots of logs do not travel far on social media. It still decides whether the product remains useful after the demo ends.

I would use several agents, just not casually

The strongest use cases are tasks that divide cleanly, benefit from parallel exploration or require strict separation of permissions. Deep research fits. Parts of compliance review may fit. A software release could justify separate testing and security agents, provided the evidence remains visible to the engineer making the decision.

For a straightforward support response or a small internal automation, I would begin with one agent. More should be added only after actual failures show where separation would help.

Users will not care how many agents participated. They will notice whether the refund was correct, whether the report included trustworthy sources and whether the system sent an unfinished email to a client.

That is less dramatic than a digital workforce holding meetings behind the screen. It is also closer to useful software.