Agent Systems: Multiple-Agent Cooperation

Figure

Figure: specialized agents return typed artifacts through a shared message protocol; the coordinator aggregates and verifies the result.

In one sentence. Divide work across specialists exchanging typed artifacts; the cost is coordination, and agreement between agents is not correctness.

Problem

A complex task may require incompatible skills, independent exploration, or different permissions. One general agent can become a bottleneck and a single point of failure.

Intent and structures

The main forms are a supervisor that delegates to specialists, a peer group that exchanges artifacts, a pipeline in which each agent owns a stage, and a debate in which agents critique alternatives. The choice should be driven by task dependencies, not by a desire to maximize agent count.

Agents as tools

One composition mechanism deserves separate mention because it dissolves the distinction between a specialist agent and a tool. An agent can be wrapped so that it presents the ordinary tool interface — a description telling the caller when to use it, and a single task parameter — while keeping its own model, tools, memory, and configuration behind that interface. A coordinator then calls a specialist exactly as it calls a function.

This is the variation-point argument applied to agents: the caller depends on the contract, so a specialist can use a cheap model for routine lookups and an expensive one for analysis without the coordinator knowing or caring.

It also carries a consequence that is easy to miss. What returns from the specialist is a design decision, not a default. Returning only the final message gives maximum context isolation — the specialist may spend thirty thousand tokens internally while the coordinator’s context grows by a two-hundred-token summary — but loses information when the final message is uninformative and the substance appeared earlier. Returning everything preserves detail and reintroduces the context explosion the delegation was meant to prevent. Each layer of a hierarchy therefore has to set its own return policy; see context engineering.

Stable interface

Every subtask needs an owner, input contract, expected artifact, status, evidence format, and completion condition. The coordinator aggregates artifacts and owns the global termination decision.

Mathematical example

Separate search for examples, retrieval of known results, proof construction, and proof criticism. Specialization is useful only if the outputs can be reconciled and checked.

Forces and failure modes

Multiple agents improve diversity and throughput but create coordination cost, duplicate work, inconsistent assumptions, and error amplification. Shared truth must be guarded by an evaluator or verifier; consensus is not correctness.

Real-world application

An incident-response system can assign log analysis, dependency lookup, and remediation planning to separate specialists. A coordinator merges their typed artifacts and sends only the agreed incident state to the operator; specialists do not need to share hidden conversational context.

Reference basis

The pattern follows Gulli, Agentic Design Patterns, Chapter 7, and Dibia, Designing Multi-Agent Systems, Chapters 2 and 7; multi-agent collaboration is Pattern 23 in Lakshmanan and Hapke, Generative AI Design Patterns. The agents-as-tools mechanism and the return-policy trade-off between context isolation and informativeness are Dibia, Chapter 4, Section 4.11. Published system examples include AutoGen’s multi-agent conversation paper and Microsoft’s Magentic-One report.

Related systems

This figure is a teaching abstraction of supervisor-style coordination. Compare Victor Dibia’s multi-agent systems book and companion material for explicit orchestration patterns. For a research system with an orchestrator directing specialized agents, see Microsoft’s Magentic-One overview and technical report.