When to multi-agent

Spectrum of LLM interaction patterns

Multi-agency is the next step in the evolution of large language model interaction patterns.

• Completions/Chats: A single LLM interaction.
• Chains: Multiple LLM interactions in sequence. Steps can involve further LLM calls.
• Constrained Agents:
• Not fully autonomous, but capable of partial agency.
• Often acts as a router or dispatcher, triggering one chain from its menu.
• Complex systems may need multiple levels of dispatch. This can be seen as primitive multi-agency.
• Autonomous Agent:
• A single agent with autonomy.
• The LLM decides when to call which tools, in what order, and when to return.
• Use autonomy only when needed. Defining logical tool sequences often improves quality and guardrail adherence.
• Multi-agents: Several (autonomous) agents.

Multi-what?

A development team can organize their code with an agent abstraction.

Does that make it a true multi-agent system? These agents might run in a single Python process. Inter-agent communication are method calls. Effectively, this is object oriented programming, leveraging a framework that introduces an Agent class (LangGraph, CrewAI, AutoGen, etc.). The latter is a wrapper around an LLM call, with instructions, a set of tools and some state to update across invocations.

Though it can help to break down the problem solving like a human team, I have seen little gain in sophistication. The hello-world for multi-agent frameworks is still writing a blog with an editor, researcher, writer and reviser.

Instead, if you want to deploy agents in production, I recommend constraining the workflow as much as possible. A more straightforward abstraction can be graphs; sub-graphs also function as a form of lightweight multi-agency.

When to multi-agent?

True value emerges when agents operate across different companies or teams. They run as distinct applications, communicate via an agent protocol, and discover each other's services. Natural language is the common interface. An example might be an internal agent delegating research tasks to an external agent e.g., a university, then sharing a summary with stakeholders through a Salesforce provided Slack agent.

Addendum (2025-04-23): Why to multi-agent?

I have been critical of multi-agent approaches, as I often see them used in scenarios where they're detrimental rather than beneficial. Here I elaborate on three reasons why to consider multiple agents:

1. Crossing organizational boundaries as mentioned above. The agent is a flexible abstraction to a system or some functionality. For example, using Google's A2A or Agent Protocol.
2. In scenarios with extreme open-endedness and non-determinism, as demonstrated in projects like Manus and Google's Co-Scientist.
   When tools and data begin to fragment extensively, orchestrating multiple specialized agents begins to make sense. Similarly, when a system benefits from having multiple concurrent agents, having multiple instances of one agent allows to cast a wider net (map-reduce style) given a fixed wall time budget.
   These systems can effectively mimic organizational dynamics, with various experts collaborating where the sum becomes more than its individual parts. However, avoid specialization in an already narrow and deterministic domain. Here, losing control as well as the bigger picture might outweigh the benefits mentioned above.
3. When agents need to run with a different lifecycle. For example a dedicated memory agent that reads conversations, and updates memory. Here specialization is clearly warranted. One can debate, though, whether this is truly multi-agent or simply multiple "single-agents" operating independently, as they don't necessarily interact directly.