In short
A multi-agent system distributes a complex problem across several specialized agents that cooperate. Effectiveness rests on standardized communication protocols and a shared ontology — without both, collaboration produces noise rather than value. Six interrelation models describe the available architectures, each with its own trade-offs between centralized control, resilience, and operational complexity.
In short: adding agents is not like adding servers — coordination does not scale linearly. Beyond 3-4 agents without a strict protocol, the noise produced often exceeds the specialization gain.
Why a single agent is not always enough
A monolithic LLM agent hits concrete limits: its context window is finite, its tools are generic, and its processing is sequential. For tasks that exceed these constraints — multi-source research, parallel generation and critique, long pipelines — the solution is not a larger model but decomposition into specialized agents.
The logic mirrors the division of labor: a researcher agent extracts facts, a writer agent produces text, a critic agent evaluates conformance. Each agent operates within its domain of competence with a limited, relevant context.
But decomposition creates a new dependency: coordination. Agents that do not understand each other produce incoherent outputs. Hence the importance of protocols and a shared ontology.
The six interrelation models
Gulli (2025) identifies six fundamental architectures for organizing interactions between agents:
1. Single agent (autonomous)
One agent with no interaction with other agents. Simple to implement and debug, but limited in scope. Suited to unit tasks that require no specialization.
2. Peer-to-peer network (P2P)
Agents communicate directly with each other without a central node. Resilient architecture: the failure of one agent does not interrupt the entire system. Limit: coordination overhead can become prohibitive at scale, and output consistency is harder to guarantee.
3. Supervisor
A central agent coordinates subordinate agents, delegates tasks, and synthesizes results. Clear and predictable architecture. Limit: the supervisor is a single point of failure — if it fails, the system stops. It can also become a bottleneck as the volume of subtasks grows.
4. Supervisor as tool
A variant of the preceding model: the supervisor provides resources and guidance without directly commanding execution. Less hierarchical rigidity, but also less control over task scheduling.
5. Hierarchical
Multiple layers of supervisors, each managing a subgroup of agents. Suited to highly complex problems decomposable into levels of abstraction. Limit: the logistics are heavy — errors can propagate across layers before being detected.
6. Custom
Hybrid combinations or emergent architectures optimized for specific domain constraints. This model acknowledges that no taxonomy covers all real-world cases — production systems often combine several patterns.
When collaboration adds value
Multi-agent collaboration is beneficial in three specific situations:
Genuine specialization. If subtasks require distinct competencies (data extraction, legal analysis, writing), separate agents with specialized prompts outperform a generalist agent. The value comes from context specialization, not from the number of agents.
Independent parallelization. When subtasks are independent, running them in parallel reduces total latency. The fire-and-consolidate pattern — launching N agents in parallel, waiting for convergence, consolidating — is the dominant mechanism (Gulli, 2025, Ch.3).
Critique and revision. Separating generation and evaluation eliminates self-serving bias. One agent produces, a separate agent critiques against explicit criteria. This separation is structurally different from self-revision.
When collaboration adds noise
Several situations produce the opposite effect:
Absence of a shared ontology. If agents use different terms for the same concept, outputs silently diverge. A shared ontology is not optional: it is the semantic contract that makes interoperability possible.
Coordination overhead exceeds the gain. For a simple task, orchestrating three agents costs more (latency, tokens, debugging complexity) than delegating execution to one. Adding agents without prior analysis of subtask independence is the primary cause of over-engineering.
Absent or incompatible communication protocols. Without a standardized exchange format — defined JSON structure, naming conventions, error handling — each agent interprets the others’ outputs in its own way. Errors accumulate at every handoff.
Hidden dependencies. If subtasks are actually sequential (task B depends on the result of A), running them in parallel forces synchronizations that cancel the benefit of parallelization.
Choosing the multi-agent architecture
| Context | Recommendation | Why |
|---|---|---|
| Simple task, a single expected result | Autonomous agent | Coordination is pure overhead, specialisation gains nil |
| Pipeline with strict dependencies (extract → analyse → write) | Sequential handoff + structured output | Maximum traceability, debugging step by step |
| N independent sub-tasks, one aggregated deliverable | Fire-and-consolidate (parallel + synthesis) | Latency cut proportionally, coherence enforced by the consolidator |
| Critical decision, diversity of angles required | Producer-Critic, or debate | Removes self-congratulation bias, produces a quality score |
| Large-scale production system, heterogeneous frameworks | A2A + MCP architecture | Decoupling, composability, cross-vendor agents |
Communication protocols and ontology
Two technical elements determine the reliability of a multi-agent system:
The communication protocol standardizes how agents exchange data and coordinate their actions. It defines input and output formats, error conventions, and subtask delegation mechanisms. Without standardization, adding a new agent to the system requires modifying all existing agents.
The shared ontology provides the common vocabulary and interoperability semantics. It guarantees that when agent A refers to a “customer,” agent B understands the same entity. In practice, it materializes in system prompts, shared data schemas, and role definitions.
Two standardized protocols are emerging in the ecosystem: MCP (Model Context Protocol) for dynamic tool discovery and consumption between agent and environment, and A2A (Agent-to-Agent) for interoperability between agents from different frameworks, via JSON Agent Cards declaring each agent’s capabilities and endpoints (Gulli, 2025, Ch.10 and Ch.15).
Common collaboration patterns
| Pattern | Description | When to use |
|---|---|---|
| Sequential handoff | Each agent completes its task and passes to the next | Pipeline with strict dependencies |
| Parallel processing | N agents simultaneously handle independent portions | Truly independent subtasks |
| Debate and consensus | Agents with varied perspectives deliberate before deciding | High-uncertainty decisions |
| Critique-revision | One agent generates, a group evaluates, revision based on feedback | Critical output quality |
| Expert teams | Distinct specialists (researcher, writer, editor) on a deliverable | Complex multi-dimensional deliverables |
Key takeaways
- Six interrelation models cover the spectrum of multi-agent architectures: from the single agent to the hierarchical system. Each model implies a trade-off between control, resilience, and complexity.
- The value of a multi-agent system emerges from coordination, not from the number of agents. Poorly coordinated agents produce less reliable results than a single well-configured agent.
- The communication protocol and shared ontology are necessary conditions — not sufficient — for collaboration to be productive. Their absence is the primary cause of failure.
- The fire-and-consolidate pattern (parallelization + convergence + synthesis) is the dominant architecture for tasks decomposable into independent subtasks.
- The open protocols MCP and A2A reduce coupling between agents, enabling composability across different frameworks.