.webp)
The field of agentic AI - where autonomous, specialized agents handle complex tasks - has moved from theoretical research into practical application at a remarkable pace.
But not every agentic system is the same. Perhaps the most exciting field of work, and the field we’re going to learn about today, is multi-agent systems (MASs).
If you need a reminder of what an agent is, click here.
From chains to graphs: Complex solutions to difficult problems
When building an agentic solution, the first thing a developer needs to think about is the relative complexity of the task it’s designed to complete.
Some are simple, with a straightforward process that can be repeatably followed to get the desired result. But many, particularly in business planning, require more complex workflows to achieve success.
Based on the complexity of the task at hand, a developer will choose to either employ a chain or a graph workflow.
A chain is a straightforward, linear sequence of steps or actions linked together. Each step receives input from the previous one, processes or transforms the data, and then passes it along to the next stage in the sequence.
This approach is familiar to anyone who has worked with automation tools or built simple macros - direct, easy to follow, and highly predictable. For example:
- Searching for a document in a repository
- Reading and extracting relevant information
- Summarizing that information
- Sending or publishing the summary to the intended recipient
But chain workflows cannot easily handle tasks that need conditional branching, feedback loops, or the simultaneous coordination of multiple actions.
A graph workflow, by contrast, is designed for complexity and adaptability. Instead of progressing in a straight line, a graph is composed of interconnected nodes, each representing a decision point, subtask, or agent.
These nodes can branch into multiple paths, loop back to earlier stages, or even operate in parallel. This flexibility enables a wide range of dynamic behaviors that would be extremely cumbersome (if not impossible) to replicate with chains.
Putting together a team
Each agent in an MAS will be specialized in completing specific tasks that contribute to an overall goal.
But why not just train one agent that can do everything?
There are a few different reasons:
1. Specialists are efficient
The first reason boils down to the same logic as in real life: a team of specialists working together produce better results than one person trying to do everything.
A generalist agent would need a significantly broader range of expertise, have mastery over a much larger set of tools, and maintain larger context windows (the number of tokens held in memory).
Ultimately this would mean weaker reasoning capabilities, slower responses, and more hallucinations.
2. Tasks can be handled in parallel
A generalist agent needs to carry out actions sequentially. A multi-agent framework could see multiple agents instructed to carry out instructions in parallel, coordinated by a supervisor agent.
When the use case is complex, this will save end-users a significant amount of time.
3. Collaborative reasoning and emergent behavior
In a multi-agent system, agents can cooperate, negotiate, and learn from each other, often solving problems more efficiently than a monolithic system.
Sometimes, in the course of this happening we see the development of useful emergent behaviors that weren’t explicitly programmed.
4. Modularity
A modular system makes it much easier to add, remove, or edit agents on the team without impacting the performance of the others.
Choose your formation
There are many different ways to construct the graph workflows that determine how MASs work, each with their own benefits.
.webp)
Network
In this setup, all agents can freely communicate with one another. Each agent independently decides which other agent to interact with next.
Supervisor
Every agent communicates with a central supervisor agent. The supervisor is responsible for determining which agent should be invoked at each step.
In our customer support example above, you’d likely use a supervisor agent to monitor the user’s inputs and assign the correct agent to answer their request.
Hierarchical
This model extends the supervisor approach by introducing layers of supervision—supervisors can themselves be managed by higher-level supervisors.
This structure enables more sophisticated and modular control flows.
Custom
In this flexible configuration, agents communicate only with specific subsets of other agents. Certain parts of the workflow follow a predefined path, while decision-making about agent invocation is limited to selected agents, allowing for partial autonomy within a constrained flow.
How does it work in Pigment?
Our own multi-agent system is built around a Supervisor Agent that controls three domain expert agents (the Analyst, Planner, and Modeler), as well as a Reporter Agent.
The Supervisor acts as the team leader, coordinating the other agents to complete tasks and communicating with the user where necessary, while the Reporter is specialized in generating and publishing charts and data.
In the next article, you’ll get to see them all in action. Stay tuned!
