And Microsoft also has a clear opinion on the topic: If the use case does not clearly exceed security or compliance boundaries, involves multiple teams or otherwise requires architectural separation, the Redmond-based company suggests starting with a singular prototype agent. Different roles would therefore not automatically justify multiple agents. This can also be represented with a single agent, which can take on different roles through conditional prompts and tool authorizations.
Microsoft also points out another point that deserves special attention: many apparent scaling problems are due to retrieval design, not architecture. So before adding more AI agents, make sure other things are running optimally. Approximately:
- Chunking,
- Indexing,
- Reranking,
- Prompt structure and
- Context selection.
Complexity does not disappear when you disassemble a system. She shifts. We learned this the hard way in the case of microservices: Back then, the complexity moved into the network – now it threatens to shift to hand-offs, prompts, arbitration and the state of agents. For real, distributed problems, multi-agent systems make sense. If such a problem does not exist, no. After all, distributed intelligence is still a distributed system – and such a system is neither cheap to develop nor maintain.
In my opinion, most teams that think they need to use multi-agent systems actually have completely different problems:
- Your tools are vague,
- their search functions are weak,
- Permissions too broad, and
- Repositories inadequately documented.
Adding more agents fixes none of these problems, but makes them even worse. According to Anthropic, the most successful implementations typically use simple, combinable patterns rather than complex frameworks.
In the microservices era, the spread of bad architectural ideas was at least limited by the effort required to implement them. In the Agentic AI era, however, the costs of developing another orchestration layer or another specialized role are falling rapidly. This can be liberating, even if it destroys our ability to maintain and manage systems in the long term. But lower production costs do not automatically lead to higher productivity. Often they simply make it easier to scale fragility.
