Introduction (From micro-services to multi-agents)

Since the 2010s, software systems have grown a lot in size and complexity. As the number of lines of code increased, developers realized that monolithic applications are not always the best choice. This is why microservices became very popular.

Microservices work well, especially in large companies with big teams, for several reasons:

• Teams can be split by business domain (one team per department).
• Each service can use a different programming language or different dependencies.
• Big and risky upgrades are easier to avoid (for example, migrating from Python 2 to Python 3).
• Testing becomes simpler.
• Code is more reusable: the same microservice can be used by multiple teams.

Interestingly, AI agents have followed the same path: At first, people tried to build large, very smart agents that do everything. Over time, it became clear that this approach has many problems:

• The more general an agent is, the worse its performance becomes. This is similar to prompt engineering: vague prompts produce weaker results.
• Evaluating a complex agent is very hard. It is often impossible to know if it followed the right reasoning path.
• An agent without a clear mission is difficult for other teams to reuse.

For these reasons, multi-agent systems have become popular. Instead of one big agent, we build many small, specialized agents that communicate with each other.

In this article, we will explore common multi-agent architectures and walk through a practical example.

Why Use Multi-Agent Systems?

Multi-agent systems have several clear advantages:

• Each agent can use the best tools for its specific task.
• Prompts and workflows can be simple and focused.
• Current LLMs struggle when they have too many tools at once. A good practice is to limit each agent to 5–15 tools.

This makes the system easier to understand, maintain, and improve.

Common Multi-Agent Architectures

There is no perfect architecture. The best choice always depends on your use case. That said, some patterns are used very often.

1. Planner-Executor Architecture:

In this setup, one main agent (the planner) breaks a task into smaller subtasks. These subtasks are then sent to specialized agents (the executors).