About This Catalog

This is the ninth volume in a catalog of the working vocabulary of agentic AI. The eight prior volumes covered patterns (the timing of agent runs), skills (model instructions in packaged form), tools (the function-calling primitives), events and triggers (what activates the agent), fabric (the substrate beneath orchestration), memory (state, context, and recall), human-in-the-loop (approval, observation, and interaction), and evaluation and guardrails (the governance layer). This ninth volume covers the layer that distinguishes serious 2026 agent architectures from the chatbots that came before: how multiple agents coordinate, communicate, and collaborate to accomplish what a single agent cannot.

The catalog opens with a warning. The dominant industry trend in 2025—2026 was to default to multi-agent architectures --- every product brochure features a diagram of agents passing messages to other agents --- and this default is usually wrong. Multi-agent systems pay real costs: latency multiplies, errors compound, debugging becomes harder, information loses fidelity in hand-offs between agents, token consumption climbs by an order of magnitude (Anthropic’s own research found roughly 15× token usage for multi-agent versus single-agent on comparable tasks). A single agent with good tools handles most cases better than two agents with mediocre coordination. Multi-agent is a power tool: useful when the lift genuinely justifies the cost, harmful when reached for as a default.

With that caveat established, this catalog covers the cases where multi-agent earns its cost --- tasks too large for one context window, phases that benefit from genuine parallelism, work that decomposes naturally into specialist roles, critique-and-revision loops where separation of producer from reviewer matters --- and the substrates that make multi-agent coordination work: communication protocols (MCP, A2A, the editor-facing Agent Client Protocol, and the agent payment protocols), frameworks (LangGraph, Google ADK, AG2, CrewAI, OpenAI Agents SDK), coordination patterns (agents-as-tools, with planner-executor and critic loops covered in Volume 1), shared-state mechanisms (the blackboard and its scratchpad variant), and the tracing infrastructure that makes multi-agent systems debuggable.

Scope

Coverage:

Communication protocols: MCP (Model Context Protocol), A2A (Agent-to-Agent), Agent Client Protocol (editor-to-agent), agent payment protocols (AP2, Agentic Commerce Protocol, x402).
Graph-and-supervisor frameworks: LangGraph multi-agent, Google Agent Development Kit, AutoGen / AG2.
Role-based and hand-off frameworks: CrewAI, OpenAI Agents SDK.
Research frameworks: Microsoft Magentic-One.
Coordination patterns as code: agents-as-tools.
Shared-state patterns: blackboard (with the shared scratchpad as its unstructured variant).
Multi-agent observability: how Volume 7’s tracing tools extend to multi-agent systems.
Discovery and directories: the AGNTCY Agent Directory.

Out of scope:

Single-agent systems --- covered by Volumes 1 (Patterns) and 3 (Tools).
General-purpose distributed systems frameworks (Akka, Erlang OTP, Ray) when not specifically used for AI agent coordination.
Message brokers and queue systems (RabbitMQ, Kafka, NATS) when used outside the multi-agent context.
Game-theoretic multi-agent research (cooperative game theory, mechanism design) that hasn’t productized into working frameworks.
Agent simulation environments (Stanford’s generative agents, ChatDev) when treated as research artifacts rather than production substrates.

How to read this catalog

Part 1 (“The Narratives”) is conceptual orientation: when (and when not) to use multi-agent, the five coordination topologies, the communication protocol landscape, the three axes of agent specialization, and the hand-off problem that pervades multi-agent design. Five diagrams sit in Part 1; everything in Part 2 is text and code.

Part 2 (“The Substrates”) is reference material organized by section. Each section opens with a short essay on what its entries have in common and how they relate to alternatives. Representative substrates appear in the Fowler-style template established by the prior eight volumes.

Part 1 — The Narratives

Five short essays frame the design space for multi-agent coordination. The reference entries in Part 2 assume the vocabulary established here.

Chapter 1. When (and When Not) to Use Multi-Agent

Start with the case against. The current industry rhetoric --- every agent product positions itself as a multi-agent platform; every architecture diagram features agents passing messages to other agents --- obscures a basic engineering fact: multi-agent systems pay real costs, and the costs only earn out when the multi-agent design genuinely solves a problem the single-agent design couldn’t. Reaching for multi-agent as a default produces systems that are slower, less reliable, harder to debug, and dramatically more expensive than their single-agent equivalents, with no quality lift to justify any of it.

When to use multi-agent — The default is single agent with good tools. Multi-agent is a power tool; reach for it when the specific situation earns its cost.

The costs are concrete. Latency multiplies: a sequential pipeline of three agents takes roughly three times as long as one agent doing the same work, assuming the work doesn’t naturally parallelize. Errors compound: each hand-off between agents is a fresh opportunity for misunderstanding; small misalignments amplify across stages. Debugging gets harder by an order of magnitude: a single trace tree (Volume 7’s observability layer) becomes a forest, and root-causing why the system did the wrong thing requires reconstructing the conversation between multiple agents rather than reading one agent’s reasoning. Token consumption explodes: Anthropic’s own multi-agent research paper found roughly 15× token usage for multi-agent designs versus single-agent on comparable research tasks --- the agents talk to each other, summarize for each other, re-establish context with each other, and the bill arrives accordingly. Information loses fidelity in every hand-off (Chapter 5 covers this in detail), which means the multi-agent system often produces lower-quality outputs than a hypothetical perfect single agent would, even when the multi-agent design seemed to promise improvement.

The benefits are real but conditional. Multi-agent earns its cost when (1) the task is genuinely too large for a single agent’s context window --- a long research project, a multi-step coding task with many files, a document that exceeds context limits; (2) phases can run in parallel for real wall-clock speedup --- four agents researching four sub-topics simultaneously rather than one agent doing them sequentially; (3) different phases need genuinely different prompts and tools --- a researcher with web-search tools versus a writer with no tool access versus a critic with structured-output requirements; (4) critique and revision benefit from separation --- a critic agent reviewing a writer agent’s output produces better results than the same model self-reviewing, because the critic’s prompt can be unambiguously adversarial without confusing the writer’s flow; (5) domain isolation has compliance value --- a finance agent and a customer-data agent with different access controls satisfies enterprise security requirements that a single agent with all permissions cannot.

The default test is uncomfortably simple: would a single agent with the right tools handle this? If yes, build the single agent. Tool calls already give the agent the effect of consulting specialists --- the agent calling a web-search tool is not architecturally different from the agent talking to a search agent, but it’s far simpler to implement, debug, and operate. The cases where multi-agent earns its cost are real and not rare, but they’re also not the default; they’re the cases where careful design specifically identifies a problem that a multi-agent structure solves. A team that defaults to multi-agent and only reaches for single-agent when forced has the relationship backward, and ships systems whose costs the team will spend the next year explaining away.

Chapter 2. The Five Coordination Topologies

If the multi-agent design has earned its place, the next question is shape. Five topologies capture nearly all the working patterns; each has characteristic strengths, characteristic failure modes, and characteristic production examples.

Hierarchical topology has a manager agent that decomposes the task, dispatches sub-tasks to worker agents, and aggregates their results. The manager owns the planning; the workers own the execution; the structure is recursive (a worker may itself be a manager of its own sub-workers). This is the topology most production multi-agent systems converge on after iteration, because it maps cleanly onto how humans organize complex work --- a project lead breaking down a project, delegating, and reviewing. The bottleneck is the manager: every step routes through it, so its latency and context budget cap the system’s. The strength is legibility: a hierarchical trace tells a coherent story; reasoning about its behavior is tractable. LangGraph’s supervisor pattern and CrewAI’s hierarchical-process mode both implement this directly.

Sequential topology is the pipeline: agent A produces output, agent B receives A’s output and produces something, agent C receives B’s output, and so on to the final stage. This is the simplest multi-agent topology and the easiest to implement; it’s also the most prone to information loss across the hand-off boundaries (Chapter 5). Sequential works when each stage genuinely transforms the input into something the next stage operates on --- extract-then-analyze-then-summarize --- and works poorly when the later stages need context the earlier stages stripped away. CrewAI’s sequential-process mode and LangGraph’s linear chains both implement this; it’s also what happens implicitly in many tool-call sequences.

Peer-network topology lets agents talk to each other freely --- any agent can address any other agent, conversations can be multi-turn and many-to-many, the structure is emergent rather than designed. This is the topology that looks most like “agents collaborating” in marketing diagrams; it’s also the topology that’s hardest to debug, the topology where conversation explosion is a real risk (agents talking endlessly to each other), and the topology where the failure mode “the agents got into a loop” shows up most. Peer networks work in research and exploratory settings where the emergent behavior is the point; in production they require firm orchestration scaffolding (termination conditions, conversation budgets, supervisor agents that step in when things go off the rails). AutoGen’s GroupChat is the canonical peer-network implementation.

Hub-and-spoke topology has a central router agent that doesn’t do work itself but routes incoming requests to specialist agents based on the request’s nature. This is similar to hierarchical but with a different center of gravity: hierarchical is plan-and-delegate, hub-and-spoke is classify-and-route. It’s the right topology for customer-support systems (route to the billing agent, the technical agent, or the returns agent based on the question), enterprise assistant systems (route to the finance agent, the HR agent, or the engineering agent based on intent), and multi-domain applications generally. OpenAI Agents SDK’s handoff mechanism implements this directly; CrewAI can be configured to work this way; the pattern is also implementable directly on top of plain tool calls with one routing agent and several callable specialist agents.

Blackboard topology is the classical AI pattern that turns out to be unexpectedly modern. All agents read from and write to a shared workspace (the blackboard); no agent directly talks to any other agent; coordination emerges from each agent looking at the current state of the blackboard and contributing when it has something to contribute. This decouples the agents --- they don’t need to know about each other --- and avoids the hand-off problem entirely (everyone sees the same world). The pattern shows up in LangGraph’s shared state model, in CrewAI’s context-sharing mechanism, in AutoGen’s group-chat shared history, and explicitly in dedicated blackboard frameworks. It’s often the right topology when agents need to coordinate but their interactions are too irregular for a fixed protocol.

Two cross-cutting observations. First, real production systems usually combine topologies: a hierarchical structure at the top level with hub-and-spoke for routing within each level, blackboard for the cases where shared state matters more than message-passing, sequential for the genuinely pipeline-shaped sub-tasks. Picking one topology and forcing all coordination through it produces awkward designs; mixing topologies thoughtfully produces good ones. Second, the topology is not the architecture: a hierarchical manager-worker design and a blackboard design can implement the same business logic; the topology choice is about the coordination shape, not about what the system does.

Chapter 3. The Communication Protocol Landscape

Beneath the framework layer is a protocol layer. When agent X needs to communicate with agent Y --- to delegate a task, to request information, to coordinate on shared work --- the message has to follow some agreed format. Through 2024 the answer was “whatever the framework uses internally,” which meant multi-agent systems were locked to a single framework. Through 2025 three open agent-to-agent protocols emerged to bridge frameworks, and within the year they had largely converged: as of late 2026 MCP and A2A carry most cross-framework traffic, both under Linux Foundation governance.

Communication protocols — MCP (started by Anthropic) for tools and context, A2A (started by Google) for agent-to-agent. Both now sit under the Linux Foundation; IBM's ACP merged into A2A in 2025.

MCP (Model Context Protocol), introduced by Anthropic in November 2024 and donated to the Linux Foundation’s Agentic AI Foundation in December 2025, started as a protocol for connecting agents to tools and data sources. The original vision was infrastructure-shaped: external MCP servers expose tools, data, or context; agents consume them via JSON-RPC; agent authors don’t need to write custom integrations for every system the agent talks to. Through 2025 the protocol’s scope expanded toward agent-as-server: an MCP server can wrap a whole agent and expose it as a callable resource, effectively making MCP a multi-agent protocol by extension. The strength is the ecosystem --- Anthropic counted more than 10,000 active public MCP servers in December 2025, covering tools, databases, SaaS products, and internal systems --- and the strength compounds because new tools naturally publish as MCP servers. The trade-off is that MCP wasn’t designed for agent-to-agent semantics from the start; some patterns natural in a peer-communication protocol require workarounds in MCP.

A2A (Agent-to-Agent Protocol), introduced by Google in April 2025 and contributed to the Linux Foundation in June 2025, is the first major protocol designed for agent-to-agent communication from day one. The model is: agents publish Agent Cards (JSON metadata describing their capabilities, endpoints, and authentication); clients discover agents by capability; tasks are delegated through a defined task-and-message lifecycle; the protocol handles streaming responses, long-running tasks, and capability negotiation. JSON-RPC, gRPC and HTTP+JSON are the defined bindings; the model maps naturally onto the case where an agent in one organization needs to invoke an agent in another organization. The strength is purpose-built design --- A2A handles things like agent discovery and capability advertisement that MCP retrofits awkwardly. The trade-off is the ecosystem gap; MCP has years of head start and broader tool coverage.

A third protocol, IBM’s ACP (Agent Communication Protocol, from the BeeAI project), covered the same ground as A2A under Linux Foundation governance. In August 2025 it merged into A2A and its repository was archived, which removed the main governance argument for choosing between them. Two other projects share the ACP acronym and are easy to confuse with it: AGNTCY’s Agent Connect Protocol (also archived; AGNTCY now builds on A2A and MCP) and the Agent Client Protocol, which connects coding agents to editors (Section A).

The mid-2026 picture is roughly: MCP for tool access (the dominant use case, with the strongest ecosystem), A2A for agent-to-agent peer communication, and gateways or framework adapters where a system needs both. Whether MCP’s agent-as-server use and A2A converge further or settle into a stable two-protocol world (tool plus agent) is still open. Building against the protocol that fits the use case and accepting that some translation work may be required later is the pragmatic posture.

Two practical recommendations. First, instrument for portability: any agent built today should expose its capabilities through whatever protocol the team is currently using, but the underlying agent logic should be protocol-agnostic. Switching from MCP to A2A is a translation layer change if the agent’s capabilities are cleanly separated from the protocol bindings; it’s a rewrite if they’re entangled. Second, don’t bet on a single protocol winning. The OpenAPI and gRPC coexistence in conventional API design is the more likely template than the one-protocol-wins HTTP outcome; expect multiple protocols to coexist with gateways translating between them.

Chapter 4. The Three Axes of Agent Specialization

If multi-agent has earned its place and the topology is chosen, the next question is what each agent does --- how to split the work across agents. Three axes capture the working patterns: role, domain, and skill. Each axis has characteristic use cases, characteristic failure modes, and characteristic frameworks. Most production designs combine all three; understanding the axes separately makes the combination thoughtful rather than accidental.

Three axes of specialization — Role splits by what kind of work; domain splits by topic area; skill splits by capability type. Production systems combine all three.

Role-based specialization splits by what kind of work the agent does. The canonical examples come from research and content production: a researcher agent that gathers and synthesizes information, a writer agent that produces the prose, a critic agent that reviews and suggests revisions, an editor agent that polishes the final output. Each role has a distinct prompt (the researcher’s system prompt is about thoroughness; the writer’s is about clarity; the critic’s is about adversarial review); each role may have distinct tools (the researcher gets web search; the writer doesn’t); the roles compose into a workflow that mirrors how human teams produce content. CrewAI is the framework most explicitly built around this pattern; AutoGen and LangGraph implement it through their respective abstractions. Role-based works well when the roles are genuinely different in their cognitive shape; it works poorly when the roles overlap so much that the specialization is theatrical rather than functional.

Domain-based specialization splits by topic area. A finance agent handles financial queries with finance-specific data sources and compliance rules; a legal agent handles legal queries with case-law databases and disclaimer requirements; a customer-service agent handles customer queries with CRM access; an engineering agent handles technical queries with code repositories and runbooks. Each agent owns a domain in the same way a department owns a function in a human organization; routing happens at the boundary (the hub-and-spoke topology from Chapter 2). The strength of domain specialization is compliance: when finance and legal advice must follow different rules, having separate agents with separate prompts and separate access controls produces auditable separation. The weakness is that domain boundaries are rarely as clean in practice as they look on the org chart; a question about a contract dispute touches both legal and finance, and the routing decision is itself a meaningful design choice.

Skill-based specialization splits by capability type. A planner agent decomposes tasks and produces structured plans; an executor agent takes a plan step and carries it out; an evaluator agent scores the executor’s outputs against the plan’s success criteria; a reflector agent watches the overall loop and produces meta-observations for the next iteration. The split is engineering-clean --- each agent has a clear input/output contract, each can be tested independently --- but conceptually distant from how non-engineers think about the work. “Which department handles this” maps to domain; “who on the team does this” maps to role; “what capability type is needed at this step” doesn’t have an obvious human analog. Skill-based shows up most in framework code and research papers (LangGraph’s planner-executor-reflector tutorial implementations, the ReAct-style cognitive loops); it shows up less in product-facing descriptions because the vocabulary is awkward.

Production systems combine the axes. A serious enterprise customer-support agent might split domain at the top level (billing, technical, returns) via hub-and-spoke routing; within each domain split role (researcher who looks up customer context, responder who drafts the reply, reviewer who checks the reply against policy); within each role apply skill (planner, executor, evaluator) as needed for the more complex tasks. The result is not a flat three-agent system but a hierarchical structure with specialization at every level. Designing this consciously --- choosing where each axis applies and where it doesn’t --- produces systems that are coherent. Letting the axes accumulate without deliberate choice produces systems where it’s unclear why any particular agent exists.

Chapter 5. The Hand-off Problem

The fundamental difficulty of multi-agent systems isn’t the topology or the protocol or the specialization. It’s that whenever agent A finishes its work and passes control to agent B, information is lost. The hand-off problem pervades every multi-agent design; addressing it well is what separates multi-agent systems that work from multi-agent systems that look impressive in diagrams but underperform single agents in practice.

Three mechanisms cause the information loss. Compression: agent A’s natural output is a paragraph of free-form text summarizing its findings; that paragraph contains a fraction of the reasoning, tool outputs, and intermediate state agent A actually accumulated. When agent B receives the summary, it receives the destination but not the journey. If agent B needs to reason about why agent A reached its conclusion --- to verify, to extend, to course-correct --- the summary has stripped exactly the information needed. Format mismatch: agent A’s output shape doesn’t match agent B’s input expectations; either agent A produces something agent B can’t parse cleanly, or agent A bends its output to match agent B’s format and loses information in the bending. Context truncation: agent B operates on agent A’s message, not on agent A’s full conversation; the surrounding context that gave agent A’s message its meaning is absent.

The naive multi-agent design ignores all three causes. Agent A produces a summary, the summary goes to agent B, agent B produces its output based on what it can extract from the summary, the next stage repeats. Each hand-off compounds the loss; by the time the system reaches its final stage, the original task has been refracted through several lenses and the output reflects the cumulative compression rather than the original work. This is why multi-agent systems frequently underperform single agents on the same task: the single agent retains all of its own context throughout; the multi-agent system loses information at every boundary.

Three mitigations address the problem at increasing levels of effectiveness. The first, structured hand-offs: replace free-form summaries with typed messages. Agent A produces a structured output with named fields --- task, context, constraints, reasoning_trace, tool_outputs, confidence, open_questions --- and agent B parses the structure to access exactly the information it needs. The structure preserves what the free-form summary loses; the trade-off is that designing the structure requires anticipating what downstream agents will need, which gets expensive as the agent graph grows.

The second mitigation, conversation passing: instead of summarizing, pass the full conversation history (or relevant slices of it) to the next agent. Agent B sees not just agent A’s conclusion but agent A’s reasoning, tool outputs, and intermediate state. This works but doesn’t scale --- the context window has limits; passing full conversations through three or four hand-offs exceeds those limits quickly --- so in practice this is the right move for shallow agent graphs and the wrong move for deep ones.

The third mitigation, and the one that scales best, is the shared workspace pattern (the blackboard topology from Chapter 2). Rather than passing information between agents, all agents read from and write to a common state object. There is no hand-off to lose information at; each agent sees the same world the previous agents saw, plus whatever the previous agents added to the workspace. The hand-off problem becomes a state-synchronization problem, which is technically easier to address --- it’s a well-understood problem in conventional distributed systems with known solutions. LangGraph’s state model and CrewAI’s context-sharing mechanism both implement this; AutoGen’s group-chat shared history is a less-disciplined variant of the same pattern. When the multi-agent design uses shared state effectively, the information-loss problem largely dissolves.

The practical recommendation: default to shared workspace designs. Use structured hand-offs only when the hand-off crosses a genuine boundary --- a boundary between organizations, a boundary between trust zones, a boundary between agents that legitimately should not share state --- and accept the engineering cost of designing the structure carefully when it must be done. Treat free-form summary hand-offs as a smell: they’re what the system devolves to when no one designed the hand-off, and the cost shows up in output quality the team has trouble explaining. The hand-off problem is the unsolved problem of multi-agent systems in the sense that there’s no protocol or framework that eliminates it entirely; it’s a solved problem in the sense that the working patterns are known. The difference between multi-agent systems that work and those that don’t is mostly whether the design took the hand-off problem seriously.

Part 2 — The Substrates

Eight sections follow. Each opens with a short essay on what its entries have in common and how they relate to alternatives. Representative substrates are presented in the same Fowler-style template used by the prior eight catalogs.

Sections at a glance

Section A --- Communication protocols
Section B --- Graph-and-supervisor frameworks
Section C --- Role-based and hand-off frameworks
Section D --- Research frameworks
Section E --- Coordination patterns as code
Section F --- Shared-state patterns
Section G --- Multi-agent observability
Section H --- Discovery and directories

Section A — Communication protocols

MCP, A2A, Agent Client Protocol and the payment protocols: the wire formats for agent communication

Two protocols dominate the agent-communication category as of late 2026, both now under Linux Foundation governance. MCP (Anthropic, November 2024; Agentic AI Foundation since December 2025) started as a tool-and-data protocol and expanded toward agent-as-server. A2A (Google, April 2025; Linux Foundation since June 2025) was designed from day one for agent-to-agent semantics with capability discovery via Agent Cards, and absorbed IBM’s Agent Communication Protocol (ACP) in August 2025. Two narrower protocols sit beside them: the Agent Client Protocol, which connects coding agents to editors, and the agent payment protocols (AP2, Agentic Commerce Protocol, x402), which let an agent pay on a user’s behalf.

MCP and A2A overlap at the edges (an MCP server can wrap an agent); frameworks increasingly speak both. Building against the protocol that fits the immediate use case, with the agent’s capabilities cleanly separated from the protocol bindings, is the pragmatic posture against protocol churn.

Pattern · 1 of 16

MCP — Model Context Protocol

Pattern page →

Classification Tool-and-context protocol extended toward agent-to-agent.

Source: github.com/modelcontextprotocol (Agentic AI Foundation / Linux Foundation; MIT moving to Apache-2.0)

Intent

Provide a JSON-RPC-based protocol for connecting LLM agents to external tools, data sources, and (increasingly) other agents, with a standardized server interface that any compatible client can consume.

Motivating Problem

Agent frameworks historically required custom integration code for every external system the agent talks to --- a different adapter for each database, each SaaS product, each internal tool. The result was that agents were locked to whichever integrations their framework happened to ship. MCP’s answer is a protocol: an external system implements an MCP server exposing tools, resources, or prompts; any MCP-compatible client (Claude Desktop, Cursor, custom agent frameworks) consumes the server. The integration shape is once, the consumption shape is everywhere.

How It Works

An MCP server is a process exposing three primitive types over JSON-RPC: Tools (callable functions the agent can invoke), Resources (data the agent can read), and Prompts (templated prompts the user can invoke). The transport is configurable: stdio for local servers, Streamable HTTP for remote servers. The protocol handles per-request version and capability declaration (with server/discover for up-front discovery), request/response correlation, streaming, and error propagation. The 2026-07-28 revision removed the initialize handshake and protocol-level sessions, so each request carries its protocol version and client capabilities in _meta.

Through 2025 the agent-as-server pattern emerged: rather than exposing low-level tools, an MCP server can wrap a whole agent and expose it as a single high-level tool. A client agent calling the server effectively delegates work to the server’s agent. This makes MCP a de facto agent-to-agent protocol for cases where the parties are willing to use it that way, even though A2A is more purpose-built for the role.

The ecosystem matters. More than 10,000 public MCP servers exist (Anthropic’s count, December 2025) for tools, databases, SaaS products, and internal systems. Anthropic, OpenAI (ChatGPT), Google (Gemini), Microsoft (Copilot, VS Code), Cursor, Zed and many others ship MCP support. Servers are discovered through the MCP Registry (registry.modelcontextprotocol.io), the community index that public and private registries mirror; Volume 5, Agent fabric registry (private), covers the fabric-level choice between a public registry, a private one, or both. Since December 2025 the protocol has been governed by the Agentic AI Foundation, a Linux Foundation directed fund co-founded by Anthropic, Block and OpenAI. Building against MCP means inheriting the existing ecosystem; building against A2A means a smaller but more agent-specific ecosystem.

When to Use It

Connecting agents to tools and data sources. Building integrations once and reusing them across multiple agent frameworks and clients. Cases where the underlying need is tool access more than peer agent communication.

Alternatives --- A2A for first-class agent-to-agent communication. Custom integration code when the protocol abstractions don’t fit the use case.

Sources

github.com/modelcontextprotocol
modelcontextprotocol.io/specification/2026-07-28/changelog
registry.modelcontextprotocol.io
linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation

Example artifacts

Code.

# MCP server in Python exposing a custom tool (MCP Python SDK 2.x;
# MCPServer was called FastMCP in 1.x)
from mcp.server import MCPServer

mcp = MCPServer("customer-lookup")

@mcp.tool()
async def lookup_customer(customer_id: str, include_orders: bool = True) -> str:
    """Look up a customer by ID and return their profile and order history."""
    profile = await fetch_customer(customer_id, include_orders)
    return str(profile)

if __name__ == "__main__":
    mcp.run(transport="stdio")

Pattern · 2 of 16

MCP primitives — tools, resources, and prompts

Pattern page →

Classification The three MCP server primitives and who controls each.

Source: modelcontextprotocol.io (specification); MCP Python and TypeScript SDKs

Intent

Model an MCP server’s surface as three distinct primitives --- tools, resources, and prompts --- distinguished by who decides when each is used, so that a capability is exposed through the primitive that matches its control model rather than defaulting everything to a tool.

Motivating Problem

MCP is often reduced to “a protocol for tools,” but a server exposes three primitive types, and collapsing them loses the design distinction the protocol is built on. The distinction is not what a capability does but who initiates it: the model, the application, or the user. Exposing read-only reference data as a tool, or a reusable workflow as a tool, works but misplaces control --- the model ends up deciding things the application or the user should decide. Choosing the right primitive is the first design decision when building a server.

How It Works

Tools (model-controlled): callable functions the model chooses to invoke during a turn, each described by a name, a description, and a JSON input schema. The model decides when to call them. This is the primitive most people mean by “MCP,” and its design is the tool-design discipline of Volume 3.

Resources (application-controlled): addressable data the server exposes for the application to read and inject into context --- a file, a database record, a config snapshot --- each identified by a URI (file://, db://, config://) with a MIME type. The application, not the model, decides which resources to load and when; the model consumes what it is handed. Resources support listing (resources/list), reading (resources/read), and optional change notifications through subscriptions/listen.

Prompts (user-controlled): parameterized prompt templates the server offers for the user to invoke deliberately --- a “summarize this document” action or a compliance-review workflow --- with typed arguments and a rendered message body. The user selects them, often from a menu; they are not fired by the model mid-turn.

The client side has its own features. Sampling (a server asking the client to run an LLM call) and roots (a client granting a server a set of directories) were deprecated in the 2026-07-28 revision (SEP-2577), along with protocol logging; they still work during the deprecation window, but new servers should call model provider APIs directly, take directories or files as tool parameters or server configuration, and log to stderr or OpenTelemetry. Roots were always advisory, since the protocol cannot stop a server from reading outside them; OS-level sandboxing (Volume 12) is the real boundary. Elicitation, where a server asks the user for input through the client, remains the supported client feature, and long-running tools still report through progress notifications.

Choosing the primitive: the decision rule is “who drives?” If the model should decide at runtime, it is a tool. If the application should supply data, it is a resource. If the user should trigger a reusable interaction, it is a prompt. One underlying system often exposes all three --- a tool to act, resources to read, prompts to launch common workflows.

When to Use It

Whenever you build, rather than merely consume, an MCP server. The primitive split is the server author’s core design choice; getting it right keeps the model’s decision surface small and puts application and user decisions where they belong. Consumers of existing servers benefit from the same mental model when deciding what to wire into context.

Alternatives --- exposing everything as a tool when the client only implements tools (some clients do not yet support resources or prompts); the base MCP pattern (above) for the protocol and ecosystem overview.

Sources

modelcontextprotocol.io/specification/2026-07-28/server/index
modelcontextprotocol.io/specification/2026-07-28/deprecated

Example artifacts

Code.

from mcp.server import MCPServer      # FastMCP in SDK 1.x

mcp = MCPServer("customer-lookup")

@mcp.tool()                          # model-controlled: the model calls it
def refund_order(order_id: str) -> str:
    ...

@mcp.resource("db://customers/{id}")  # application-controlled: the app reads it
def customer(id: str) -> str:
    ...

@mcp.prompt()                        # user-controlled: the user invokes it
def quarterly_review(quarter: str) -> str:
    ...

Pattern · 3 of 16

MCP transports — stdio and Streamable HTTP

Pattern page →

Classification MCP transport options: local stdio and remote Streamable HTTP.

Source: modelcontextprotocol.io (transport specification)

Intent

Choose how an MCP client and server exchange messages --- stdio for a local subprocess, Streamable HTTP for a remote service --- matching the transport to whether the server runs beside the client and whether it must serve multiple users.

Motivating Problem

An MCP server’s primitives are the same regardless of how bytes move between client and server, but the transport determines where the server can run, how it is deployed, and whether it holds state. A transport chosen by default rather than by fit leaves teams with a local-only server they cannot host, or a remote server carrying per-connection state it cannot scale. The transport is a deployment decision made at build time.

How It Works

stdio: the client launches the server as a child process and exchanges newline-delimited JSON-RPC over the process’s stdin and stdout. Zero network configuration, single-user, lifecycle tied to the subprocess, stateful by nature (in-memory state lives as long as the process). This is how local servers run --- and how Claude Code runs its MCP servers natively.

Streamable HTTP: the server binds to a port and serves JSON-RPC over HTTP; each POST is answered with JSON or an SSE stream scoped to that request, and change notifications use subscriptions/listen. SSE is a component of this transport, not a separate transport of its own. Since the 2026-07-28 revision there is no standalone server-to-client stream; a request the server needs to make of the client is embedded in its result. This suits remote servers, multiple concurrent clients, and production APIs.

Stateful vs. stateless: stdio servers are stateful per process. Streamable HTTP is stateless at the protocol level since 2026-07-28, which makes it simple to scale behind a load balancer; a server that needs continuity mints its own handle and has the client pass it as a tool argument. Revisions 2025-03-26 to 2025-11-25 used an Mcp-Session-Id header for this instead.

Production requirements follow the transport: a remote HTTP server needs TLS, authentication on every request, and usually a load balancer; a local stdio server needs none of these because it is not reachable off-box. Selecting the transport therefore also selects the security surface (see least privilege in Volume 12).

When to Use It

stdio for local integrations, developer tools, and anything running beside the client (Claude Desktop, Claude Code, IDE plugins). Streamable HTTP for hosted servers, multi-user deployments, and any server exposed as a production API. Build the server so its primitives are independent of the transport, so the same server can be offered either way.

Alternatives --- the deprecated standalone HTTP+SSE transport that Streamable HTTP superseded; custom transports for constrained environments, which the SDKs allow but few need.

Sources

modelcontextprotocol.io/specification/2026-07-28/basic/transports
modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http

Example artifacts

Code.

# The same server, two transports; the primitives do not change
from mcp.server import MCPServer      # FastMCP in SDK 1.x

mcp = MCPServer("customer-lookup")
# ... register tools / resources / prompts ...

if __name__ == "__main__":
    # Local: Claude Desktop / Claude Code launch this as a subprocess
    mcp.run(transport="stdio")
    # Remote instead:
    # mcp.run(transport="streamable-http", host="0.0.0.0", port=8000)

Pattern · 4 of 16

A2A — Agent-to-Agent Protocol

Pattern page →

Classification Purpose-built agent-to-agent communication protocol.

Source: github.com/a2aproject/A2A (Linux Foundation; Apache-2.0)

Intent

Provide a protocol with JSON-RPC, gRPC and HTTP+JSON bindings, designed specifically for agent-to-agent communication, with first-class agent discovery (via Agent Cards), capability advertisement, task delegation with streaming, and a well-defined task lifecycle.

Motivating Problem

When agent X needs to ask agent Y to perform a task, the natural pattern is request-response with capability negotiation: X discovers what Y can do, sends a structured task request, receives streaming progress updates, and gets a typed result. MCP can be bent to this pattern but wasn’t designed for it; A2A is the design. Agent Cards advertise capabilities; clients fetch an agent’s Agent Card from its well-known URL or from a curated catalog; tasks are delegated through a defined lifecycle (submitted, working, input-required, auth-required, completed, failed, canceled, rejected); streaming responses handle long-running work.

How It Works

An A2A-compatible agent publishes an Agent Card at /.well-known/agent-card.json: a JSON document with the agent’s name, description and version, its supportedInterfaces (each a URL plus a protocol binding), a capabilities object of flags such as streaming and pushNotifications, its securitySchemes, default input and output modes, and a list of skills (each with an id, name, description and tags). The specification defines no registry; clients find agents through the well-known URL, direct configuration, or a curated catalog outside the spec (the AGNTCY directory in Section H is one).

The client sends a message to one of the agent’s interfaces. The agent returns a task ID and begins work. Status polling, streaming, or push notifications give the client visibility into progress. The task lifecycle includes an input-required state for HITL scenarios (the agent needs more information from the user before continuing) and a completed state with the final structured output. Long-running tasks survive client disconnects --- the protocol assumes asynchronous delegation.

Multi-modal communication is first-class. A task can include text, images, structured data, and references to external content; agent responses can stream multiple parts (a chart, then a summary, then a follow-up question). The protocol’s design anticipates the agent-collaboration cases that emerged as 2025 progressed.

Governance moved in 2025. Google contributed A2A to the Linux Foundation in June 2025, and in August 2025 IBM’s Agent Communication Protocol (ACP) merged into it, so the open-governance alternative that earlier drafts of this catalog listed no longer exists separately. Version 1.0.1 was released in May 2026.

When to Use It

Agent-to-agent communication where the agents may be developed by different teams or organizations. Cases needing first-class capability discovery and advertisement. Streaming long-running task delegation. Production multi-agent systems with cross-organizational components.

Alternatives --- MCP when the underlying need is tool access more than peer communication. Agents-as-tools (Section E) when both agents run in one process and framework.

Sources

github.com/a2aproject/A2A
a2a-protocol.org/latest/specification/
research.ibm.com/projects/agent-communication-protocol

Example artifacts

Schema / config.

{
  "name": "Customer Research Agent",
  "description": "Researches customer profiles from CRM and public sources",
  "version": "1.2.0",
  "supportedInterfaces": [
    {"url": "https://my-agent.example.com/a2a/v1", "protocolBinding": "JSONRPC"}
  ],
  "capabilities": {"streaming": true, "pushNotifications": false},
  "securitySchemes": {
    "oidc": {"openIdConnectSecurityScheme": {
      "openIdConnectUrl": "https://login.example.com/.well-known/openid-configuration"}}
  },
  "defaultInputModes": ["text/plain", "application/json"],
  "defaultOutputModes": ["application/json"],
  "skills": [
    {
      "id": "research_customer",
      "name": "Customer research",
      "description": "Produces a structured research report on a customer",
      "tags": ["crm", "research"]
    }
  ]
}

Served at https://my-agent.example.com/.well-known/agent-card.json.

Pattern · 5 of 16

Agent Client Protocol (editor-to-agent)

Pattern page →

Classification Protocol connecting coding agents to editors and IDEs, modelled on the Language Server Protocol.

Source: github.com/agentclientprotocol/agent-client-protocol (Zed and JetBrains; Apache-2.0)

Intent

Standardize how a code editor talks to a coding agent, so that any agent implementing the protocol works in any editor that supports it, the way the Language Server Protocol decoupled language tooling from editors.

Motivating Problem

Coding agents and editors were coupled pairwise: each editor built a custom integration for each agent, and each agent implemented editor-specific APIs to reach users. A team that chose an agent also chose its editors. The Agent Client Protocol (also abbreviated ACP) breaks the pairing. It is unrelated to IBM’s Agent Communication Protocol, which merged into A2A, and to AGNTCY’s archived Agent Connect Protocol; the shared acronym is a frequent source of confusion.

How It Works

The editor is the client and the agent is the server. A local agent runs as a subprocess of the editor and exchanges JSON-RPC over stdio; remote agents over HTTP or WebSocket are supported but, per the docs, still a work in progress. The protocol reuses MCP’s JSON representations where it can and adds types for coding UX: sessions, prompt turns, tool calls, file system access, terminals, agent plans, diffs, and slash commands. User-readable text is Markdown.

Adoption is broad on both sides. The agent list includes Claude Agent (through Zed’s SDK adapter), Codex CLI (through an adapter), Gemini CLI, GitHub Copilot (in preview), Goose, Cline, Cursor, OpenHands and Junie; clients include Zed, JetBrains IDEs, Neovim and Emacs plugins, and Obsidian. An ACP Registry lists installable agents. Zed and JetBrains govern the protocol jointly under an interim model while working toward an independent foundation.

In the protocol stack it sits beside MCP and A2A rather than competing with them: MCP connects an agent to tools, A2A connects agents to each other, and the Agent Client Protocol connects an agent to the human’s editor.

When to Use It

Building a coding agent that should run inside more than one editor, or an editor or developer tool that should host third-party agents. Not for agent-to-agent delegation (use A2A) or tool access (use MCP).

Alternatives --- a native extension per editor (VS Code extension API, JetBrains plugin) when only one editor matters; MCP when the editor only needs to call the agent’s tools rather than host a session with it.

Sources

agentclientprotocol.com/get-started/introduction
agentclientprotocol.com/get-started/agents
agentclientprotocol.com/community/governance
github.com/agentclientprotocol/agent-client-protocol

Pattern · 6 of 16

Agent payment protocols (AP2, Agentic Commerce Protocol, x402)

Pattern page →

Classification Protocols for an agent to authorize and make payments on a user's behalf.

Source: ap2-protocol.org (Google; Apache-2.0); agenticcommerce.dev (OpenAI and Stripe; Apache-2.0); github.com/x402-foundation/x402 (x402 Foundation, started by Coinbase)

Intent

Let an agent buy something for a user in a way the merchant, the payment network and the user can all verify: proof of what the user authorized, a checkout the merchant controls, and a payment credential the agent never sees in the clear.

Motivating Problem

Payment systems assume a human clicks “buy” on a site they trust. When an agent initiates the payment, three questions have no answer in today’s rails: did the user authorize this specific purchase, does the request reflect the user’s intent rather than a model error, and who is accountable if it goes wrong. Without a shared protocol each agent platform and each merchant builds a proprietary integration. Three open protocols address different parts of the problem.

How It Works

AP2 (Agent Payments Protocol), announced by Google in September 2025, is an extension to A2A (and to the Universal Commerce Protocol) built around mandates: tamper-evident, cryptographically signed verifiable digital credentials. A Checkout Mandate records the items and terms agreed with the merchant; a Payment Mandate authorizes payment against a specific instrument. Each has an open form (the user’s constraints, such as a budget, for an agent acting while the user is away) and a closed form (authorization of one finalized checkout). The chain of mandates is the audit trail for disputes. Standardization continues in FIDO Alliance working groups.

The Agentic Commerce Protocol, developed by Stripe and OpenAI, standardizes the checkout itself. A business implements agent-facing checkout endpoints (REST or MCP) and stays merchant of record; the agent platform passes a secure payment token rather than the buyer’s card details. ChatGPT was the first agent platform to implement it and Stripe the first payment provider, with its Shared Payment Token.

x402 revives the HTTP 402 Payment Required status for per-request payment. The server answers a request with 402 and a PAYMENT-REQUIRED header listing accepted schemes and networks; the client retries with a PAYMENT-SIGNATURE header carrying a signed payment payload; the server verifies it locally or through a facilitator and serves the resource. It aims to support crypto and fiat networks but commits to never deprioritizing on-chain payments such as stablecoins, which suits machine-to-machine micropayments such as an agent paying per API call. AP2 ships x402 samples for agents paying without a human present.

The three compose rather than compete: AP2 for proving authorization, the Agentic Commerce Protocol for the merchant checkout, x402 for settling small payments in-band over HTTP. Volume 17 (The AI Agent Economics Catalog) covers the cost side.

When to Use It

Any agent that spends money for a user: shopping and booking assistants, procurement agents, agents paying for data or compute per call. Use mandates (AP2) when the agent acts without the user present; use x402 when the counterparty is an API rather than a store.

Alternatives --- a human approval step before every purchase (Volume 7) when volumes are low; a corporate card with platform-side spending limits when the agent buys from a small, known set of vendors.

Sources

ap2-protocol.org
agenticcommerce.dev
github.com/agentic-commerce-protocol/agentic-commerce-protocol
github.com/x402-foundation/x402

Section B — Graph-and-supervisor frameworks

LangGraph multi-agent, Google ADK and AutoGen / AG2: the explicit-graph approach

Three frameworks cover the graph-and-supervisor approach to multi-agent coordination. LangGraph (from the LangChain team) models multi-agent systems as state graphs where nodes are agents and edges are transitions, with the supervisor pattern as the canonical hierarchical topology. Google’s Agent Development Kit combines deterministic workflow agents and graphs with LLM-driven delegation to sub-agents, and speaks A2A natively. AutoGen (Microsoft, now succeeded by Microsoft Agent Framework) and its community continuation AG2 model multi-agent systems as conversations among agents with configurable conversation patterns (sequential, group chat, hierarchical), with the GroupChat abstraction as the canonical peer-network topology.

The frameworks reflect two design instincts, with ADK sitting between them. LangGraph treats multi-agent as graph engineering: the structure is explicit, every transition is named, the state model is typed. AutoGen treats multi-agent as conversation engineering: agents talk to each other in conversations, the structure emerges from the conversation flow. Both work; teams choose by preference for explicit-graph design versus emergent-conversation design.

Pattern · 7 of 16

LangGraph (multi-agent)

Pattern page →

Classification State-graph framework with explicit multi-agent patterns (supervisor, hierarchical, network).

Source: github.com/langchain-ai/langgraph (MIT; Python and TypeScript)

Intent

Provide a state-graph framework where multi-agent systems are designed as explicit graphs with named agent nodes, typed state, and named transitions, with built-in patterns for supervisor (one manager dispatches to workers), hierarchical (managers of managers), and network (peer-to-peer) topologies.

Motivating Problem

For teams that want their multi-agent system’s structure to be explicit, auditable, and testable, the conversation-based approach (AutoGen) is too emergent. LangGraph’s answer is graph-as-architecture: the multi-agent system is a directed graph, agents are nodes, transitions between agents are edges, the shared state is a typed object that flows through the graph. The structure is visible in the code; the runtime executes the graph faithfully; the trace shows exactly which agents ran in which order.

How It Works

Define an agent state schema (a TypedDict or Pydantic class). Add agent nodes --- each is a function that takes the state and returns a state update. Add edges connecting nodes --- either unconditional (always go from A to B) or conditional (a router function decides where to go next based on state). Compile the graph; invoke with an initial state; the runtime executes the graph until termination, producing the final state.

The supervisor pattern is the canonical hierarchical implementation. A supervisor node receives the current state, decides which worker should run next, and routes accordingly; worker nodes do specialized work and return state updates; the supervisor sees the worker’s updates and decides the next step. The pattern composes recursively: a worker can itself be a sub-graph with its own supervisor.

Shared state addresses the hand-off problem (Chapter 5) directly. All agents read from the same state object and write updates to it; no agent receives a compressed summary of another agent’s work --- it receives the full state object with all prior agents’ contributions visible. The pattern maps onto the blackboard topology naturally.

Integration with Volume 7’s HITL primitives (interrupts) and Volume 7’s tracing (LangSmith) is first-class. Execution follows a Pregel-inspired model: nodes run in supersteps, and a checkpointer (in-memory, SQLite or Postgres) snapshots state at every transition, so a multi-agent run survives a process restart and can resume. A multi-agent system built on LangGraph inherits this durable-execution and observability machinery without separate integration work. Volume 6 (LangGraph state and checkpointers) and Volume 7 (LangGraph interrupts) cover those facets.

When to Use It

Production multi-agent systems where the structure should be explicit and auditable. Hierarchical or supervisor-style coordination. Cases needing typed shared state and structured transitions. Teams that prefer graph engineering over conversation engineering.

Alternatives --- AutoGen / AG2 for the conversation-based equivalent. CrewAI for role-based with less graph engineering. Custom orchestration when the framework abstractions don’t fit.

Sources

github.com/langchain-ai/langgraph
docs.langchain.com/oss/python/langchain/multi-agent

Example artifacts

Code.

from typing import TypedDict, Annotated, Literal

from langgraph.graph import StateGraph, END

from langgraph.types import Command

from langchain_anthropic import ChatAnthropic

class ResearchState(TypedDict):

task: str

research_notes: list[str]

draft: str

critique: str

final: str

llm = ChatAnthropic(model="claude-opus-4-7")

def supervisor(state: ResearchState) ->
Command[Literal["researcher", "writer", "critic",
"__end__"]]:

"""Decide which agent should run next based on current
state."""

if not state["research_notes"]:

return Command(goto="researcher")

if not state["draft"]:

return Command(goto="writer")

if not state["critique"]:

return Command(goto="critic")

if state["critique"] and "approved" not in
state["critique"].lower():

return Command(goto="writer") # revise based on critique

return Command(goto="__end__", update={"final":
state["draft"]})

def researcher(state: ResearchState) -> dict:

notes = llm.invoke(f"Research the topic:
{state['task']}").content

return {"research_notes": [notes]}

def writer(state: ResearchState) -> dict:

draft = llm.invoke(

f"Task: {state['task']}\nNotes:
{state['research_notes']}\n"

f"Previous draft: {state['draft']}\nCritique:
{state['critique']}\n"

"Produce or revise the draft accordingly."

).content

return {"draft": draft, "critique": ""} # clear critique on
revision

def critic(state: ResearchState) -> dict:

critique = llm.invoke(

f"Review this draft against the task. If acceptable, say
'APPROVED'.\n"

f"Task: {state['task']}\nDraft: {state['draft']}"

).content

return {"critique": critique}

graph = (

StateGraph(ResearchState)

.add_node("supervisor", supervisor)

.add_node("researcher", researcher)

.add_node("writer", writer)

.add_node("critic", critic)

.set_entry_point("supervisor")

.add_edge("researcher", "supervisor")

.add_edge("writer", "supervisor")

.add_edge("critic", "supervisor")

.compile()

)

result = graph.invoke({"task": "Survey current state of vector
databases",

"research_notes": [], "draft": "", "critique": "",
"final": ""})

Pattern · 8 of 16

Google Agent Development Kit (ADK, multi-agent)

Pattern page →

Classification Code-first agent framework combining deterministic workflow agents, LLM-driven sub-agent delegation, and native A2A.

Source: github.com/google/adk-python (Google; Apache-2.0; also Java, Kotlin, Go and TypeScript)

Intent

Build multi-agent systems from one agent type tree in which some agents follow fixed control flow (sequence, parallel, loop, graph), others delegate to sub-agents by LLM decision, and any agent can be exposed to or consume a remote agent over A2A.

Motivating Problem

Most frameworks make teams pick one coordination style: explicit graphs (LangGraph), conversations (AG2), or hand-offs (OpenAI Agents SDK). Real systems mix them: a fixed pipeline for the steps that must run in order, a coordinator that picks a specialist at runtime, and a remote agent owned by another team. ADK treats all of these as agents in one tree, so the mix is a matter of composition rather than of switching frameworks.

How It Works

An LlmAgent has a model, an instruction, tools, and optionally a list of sub_agents. Workflow agents control their sub-agents without consulting a model: SequentialAgent runs them in order, ParallelAgent runs them concurrently, and LoopAgent repeats them until a termination condition. ADK calls these template workflows; ADK 2.0 (Python and Go) supersedes them with graph-based workflows (agents and deterministic nodes in a graph with decision branches) and dynamic workflows (composition in ordinary code). Agents pass results through shared session state: an agent’s output_key names the state field its final response is written to, which the next agent reads.

Delegation comes in two forms, and the docs draw the line explicitly. A sub-agent takes over: when a coordinator transfers to it (the transfer_to_agent action), the sub-agent answers the user from then on, which ADK 2.0 calls a collaborative workflow. An AgentTool keeps control with the caller: the wrapped agent’s answer returns to the calling agent as a tool result (Section E, Agents-as-tools).

A2A support is built in, though marked experimental. to_a2a(root_agent) serves an agent over A2A and generates its Agent Card; adk api_server —a2a does the same from the CLI; RemoteA2aAgent takes an Agent Card URL and lets a remote agent act as a local sub-agent.

When to Use It

Systems that need fixed pipelines and LLM-driven delegation in the same tree. Teams on Google Cloud (ADK deploys to Vertex AI Agent Engine, Cloud Run and GKE) or teams that want A2A exposure without writing the protocol layer. Polyglot organizations, since the same model exists in five languages.

Alternatives --- LangGraph for a single explicit-graph model with mature checkpointing. OpenAI Agents SDK for hand-off-centric designs. CrewAI for role-first configuration.

Sources

github.com/google/adk-python
adk.dev/workflows/
adk.dev/agents/workflow-agents/
adk.dev/a2a/

Example artifacts

Code.

from google.adk.agents.llm_agent import LlmAgent
from google.adk.agents.parallel_agent import ParallelAgent
from google.adk.agents.sequential_agent import SequentialAgent

web = LlmAgent(name="WebResearcher", model="gemini-2.5-flash",
               instruction="Research the topic on the web.", output_key="web_notes")
docs = LlmAgent(name="DocsResearcher", model="gemini-2.5-flash",
                instruction="Research the topic in internal docs.", output_key="doc_notes")
writer = LlmAgent(name="Writer", model="gemini-2.5-flash",
                  instruction="Write a brief from {web_notes} and {doc_notes}.")

# Deterministic shape: research in parallel, then write
root_agent = SequentialAgent(
    name="ResearchPipeline",
    sub_agents=[ParallelAgent(name="Research", sub_agents=[web, docs]), writer],
)

Pattern · 9 of 16

AutoGen / AG2

Pattern page →

Classification Conversation-based multi-agent framework with configurable conversation patterns.

Source: github.com/ag2ai/ag2 (Apache-2.0); github.com/microsoft/autogen (no longer maintained; successor github.com/microsoft/agent-framework)

Intent

Provide a framework where multi-agent systems are designed as conversations among agents, with configurable conversation patterns (sequential, group chat, hierarchical), termination conditions, and the ability to mix LLM agents, code-executor agents, and human-input agents in the same conversation.

Motivating Problem

For teams that find conversation a more natural primitive than graph for multi-agent design, AutoGen’s answer is agents-as-conversational-participants. An AssistantAgent (LLM-driven), UserProxyAgent (human-in-the-loop or code executor), and GroupChatManager (orchestrator) compose into conversations where the agents take turns responding. The structure is emergent within the constraints of the configured conversation pattern; the framework handles message routing, turn-taking, and termination.

How It Works

Define agents with system messages describing their roles. The simplest two-agent pattern: AssistantAgent and UserProxyAgent in a back-and-forth conversation. The GroupChat pattern: multiple AssistantAgents plus a GroupChatManager that selects which agent speaks next based on configurable speaker-selection logic (auto-LLM-driven, round-robin, or custom). Termination conditions stop the conversation when met (max rounds, specific message pattern, agent vote).

The conversation history is the shared state --- every agent in a GroupChat sees the full history of what every other agent has said. This naturally addresses the hand-off problem (Chapter 5) because there is no hand-off; there’s shared conversational context. The trade-off is that the conversation can grow large quickly, and context-window limits become a practical concern in long multi-agent runs.

AG2 (the community fork) emerged in late 2024 / early 2025 over governance disagreements with Microsoft. The two projects have since separated for good: Microsoft’s AutoGen README now marks the project as no longer maintained, advises against production use, and points new users to Microsoft Agent Framework (Volume 5), which reached 1.0 with a migration guide from AutoGen. AG2 continues the conversation-based design as an actively developed community project, so new conversation-style work belongs on AG2 or on Agent Framework’s group-chat orchestration.

AutoGen 0.4 (previewed late 2024, stable January 2025) shifted to an actor-model architecture with stronger async support and explicit agent-runtime separation, in three layers: Core (single-threaded actors processing messages from a mailbox, with a runtime that handles serialization and distributed deployment), AgentChat (the higher-level conversational API), and Extensions (model clients, tools, code executors). It shipped for Python and .NET.

When to Use It

Multi-agent systems where conversation is a natural primitive for the design. Cases needing flexible speaker-selection logic (LLM-driven “whose turn is it”). Mixing LLM agents with code-executor agents and human-input agents in a single coordinated flow. Research workflows where emergent conversational behavior is part of the value. For existing AutoGen deployments, plan a migration to AG2 or Microsoft Agent Framework rather than new production work on AutoGen.

Alternatives --- Microsoft Agent Framework for the supported Microsoft successor. LangGraph for explicit-graph engineering. CrewAI for the role-based equivalent with simpler ergonomics. OpenAI Agents SDK for the hand-off-centric alternative.

Sources

github.com/ag2ai/ag2
github.com/microsoft/autogen
learn.microsoft.com/en-us/agent-framework/migration-guide/from-autogen/

Section C — Role-based and hand-off frameworks

CrewAI and OpenAI Agents SDK

Two frameworks dominate the role-based and hand-off approach. CrewAI is the canonical role-first framework: agents are configured with explicit roles, goals, and backstories; tasks have assigned agents; the crew executes the tasks in defined order. OpenAI Agents SDK (the production successor to OpenAI Swarm, released in 2025) is the hand-off-centric framework: agents are functions, hand-offs between agents are tool calls, the framework handles the orchestration. Claude’s subagents (isolated sub-instances that a main agent spawns for delegated work) are the product form of Volume 1’s Orchestrator-Workers pattern; for their configuration in Claude Code and the Claude Agent SDK, see Volume 18, Project subagents and The Claude Agent SDK.

Both share a design instinct: the structure is conceptually closer to how humans organize work than how engineers organize code. Roles and hand-offs map onto familiar mental models, which makes these frameworks accessible to non-engineers configuring agent behavior. The trade-off is that the structure is less explicit than LangGraph’s graphs and less flexible than AutoGen’s conversations.

Pattern · 10 of 16

CrewAI

Pattern page →

Classification Role-first multi-agent framework with task-and-crew orchestration.

Source: github.com/crewAIInc/crewai (Python; MIT)

Intent

Provide a framework where multi-agent systems are designed as crews of role-defined agents executing structured tasks, with explicit roles, goals, and backstories per agent and clear task definitions including expected outputs.

Motivating Problem

For teams that find the role abstraction natural --- the Researcher, the Writer, the Critic, the Editor --- CrewAI structures multi-agent design around that abstraction. Each agent has a role (a one-line description of what kind of work it does), a goal (what it’s optimizing for), a backstory (the context that shapes its perspective), and optionally a set of tools. Tasks are first-class objects with descriptions, expected outputs, and assigned agents. A crew is a collection of agents executing a sequence of tasks; the framework handles the orchestration.

How It Works

Define agents: each gets role, goal, backstory, optional tools, optional LLM choice, optional max iterations. Define tasks: each gets description, expected_output, agent (the assigned agent), optional context (which tasks’ outputs feed in). Build a Crew with the agents and tasks, choose a process (Process.sequential for pipeline ordering or Process.hierarchical for manager-dispatches-workers), and call kickoff() to execute.

Context-sharing across tasks is the canonical hand-off mechanism: each task’s output becomes available as context to subsequent tasks. The framework handles the plumbing automatically. For finer control, task definitions can specify which prior tasks’ outputs they need, and the framework wires only those contexts.

Hierarchical process mode adds a manager: instead of pre-defining the task sequence, a manager agent (an LLM with a manager-style prompt) decides which agent should execute next based on the task and current state. The pattern is the supervisor topology from Chapter 2, implemented at the CrewAI abstraction level.

The framework’s opinionated structure is the trade-off. CrewAI is fastest to adopt for the cases it fits well --- content production, research workflows, structured-output generation --- and least flexible for cases that don’t map onto roles-and-tasks. Teams hitting those edges often migrate to LangGraph or AG2 for more direct control.

When to Use It

Multi-agent systems where roles map cleanly onto the work. Content production, research synthesis, structured analysis tasks. Teams that want to configure agents declaratively rather than engineering coordination logic. Quick prototyping of role-based agent designs.

Alternatives --- LangGraph for explicit-graph control. AG2 for conversation-based design. OpenAI Agents SDK for hand-off-centric orchestration. CrewAI Flows (Volume 4) when the work is an event-driven pipeline rather than a crew. Custom code when CrewAI’s opinionated structure fights the problem.

Sources

github.com/crewAIInc/crewai
docs.crewai.com

Example artifacts

Code.

from crewai import Agent, Task, Crew, Process

researcher = Agent(

role="Senior Research Analyst",

goal="Find and synthesize information about the vector database
market",

backstory="You are an experienced market analyst with deep knowledge
of "

"the infrastructure software space and a track record of producing
"

"comprehensive market overviews.",

tools=[web_search_tool, scrape_website_tool],

verbose=True,

)

writer = Agent(

role="Technical Writer",

goal="Produce a clear, well-structured market overview",

backstory="You write for a technically sophisticated audience and
excel at "

"organizing complex topics into readable structure.",

verbose=True,

)

critic = Agent(

role="Editorial Reviewer",

goal="Ensure factual accuracy and clear structure in the final
draft",

backstory="You are an experienced editor with a strong eye for
unsupported "

"claims and a low tolerance for muddy prose.",

verbose=True,

)

research_task = Task(

description="Survey the current state of vector databases as of
2026. Cover "

"market leaders, open-source landscape, and recent trends.",

expected_output="A bulleted list of findings with sources, organized
by theme.",

agent=researcher,

)

write_task = Task(

description="Write a 1500-word market overview based on the research
notes.",

expected_output="A complete article in markdown with clear section
structure.",

agent=writer,

context=[research_task],

)

review_task = Task(

description="Review the draft. Flag any unsupported claims, weak
prose, or "

"structural issues. Either return 'APPROVED' or specific revision
notes.",

expected_output="Either 'APPROVED' or a bulleted list of specific
issues.",

agent=critic,

context=[write_task],

)

crew = Crew(

agents=[researcher, writer, critic],

tasks=[research_task, write_task, review_task],

process=Process.sequential,

verbose=True,

)

result = crew.kickoff()

Pattern · 11 of 16

OpenAI Agents SDK

Pattern page →

Classification Hand-off-centric multi-agent framework, production successor to OpenAI Swarm.

Source: github.com/openai/openai-agents-python (OpenAI; MIT)

Intent

Provide a lightweight framework where multi-agent systems are designed as networks of agents connected by hand-offs (agent-to-agent transitions implemented as tool calls), with the framework handling routing and the agents themselves being simple functions.

Motivating Problem

OpenAI Swarm (released 2024 as an educational reference) demonstrated that multi-agent coordination could be modeled as hand-offs: agent A finishes its work and explicitly transfers control to agent B via a tool call. The Agents SDK (released 2025 as the production successor) productized this pattern with first-class hand-off primitives, structured outputs, integrated tracing, and the support tier OpenAI couldn’t provide for Swarm. The result is a framework that’s lightweight relative to LangGraph’s graph engineering and AutoGen’s conversation patterns, with hand-off as the central abstraction.

How It Works

Define agents: each is a function with a name, instructions (the system prompt), tools, and a list of agents it can hand off to. The framework treats hand-offs as a special kind of tool call --- the agent decides at runtime whether to invoke a tool or transfer to another agent. The Runner executes the conversation: it invokes the current agent, processes the response (which may be a hand-off, a tool call, or a final output), and continues until a final output is produced.

The hand-off is explicit and traceable: the agent’s decision to hand off appears in the trace as a typed event; the receiving agent gets the full conversation history; the routing logic is visible in code (which agents can hand off to which other agents).

Integration with structured outputs (Pydantic-style schemas as the agent’s output type), tracing (OpenAI’s built-in tracing UI or external observability platforms), and guardrails (input and output checks per Volume 8’s patterns) is first-class. The framework is intentionally small --- a few thousand lines of code --- because the abstractions are deliberately minimal.

When to Use It

Multi-agent systems where hand-offs (route to billing agent, escalate to manager agent, transfer to specialist) are the natural coordination primitive. Customer-support routing systems. Hub-and-spoke topologies (Chapter 2) with explicit routing logic. Teams that prefer lightweight frameworks over heavyweight orchestration.

Alternatives --- CrewAI for role-based with task-and-crew structure. LangGraph for explicit graph control. AG2 for conversation-based design. Within the SDK itself, agent.as_tool() when the triage agent should keep control rather than hand off (Section E, Agents-as-tools). Direct API code when the framework abstractions don’t add value.

Sources

github.com/openai/openai-agents-python
openai.github.io/openai-agents-python/

Example artifacts

Code.

from agents import Agent, Runner, function_tool

\@function_tool

def check_account_balance(account_id: str) -> dict:

return fetch_balance(account_id)

\@function_tool

def look_up_order(order_id: str) -> dict:

return fetch_order(order_id)

billing_agent = Agent(

name="Billing Specialist",

instructions="You handle billing questions. Always verify account
before discussing charges.",

tools=[check_account_balance],

)

order_agent = Agent(

name="Order Specialist",

instructions="You handle order-related questions: status, returns,
exchanges.",

tools=[look_up_order],

)

triage_agent = Agent(

name="Customer Support Triage",

instructions=(

"You are the first line of customer support. Identify whether the "

"customer's issue is about billing or orders, and hand off to the
"

"appropriate specialist. Do not attempt to resolve the issue
yourself."

),

handoffs=[billing_agent, order_agent], # explicit routing options

)

result = Runner.run_sync(

starting_agent=triage_agent,

input="I think I was charged twice for order #12345",

)

print(result.final_output)

Section D — Research frameworks

Microsoft Magentic-One

Magentic-One sits outside the dominant graph, role and conversation patterns. It is a research-oriented system (released late 2024) targeting open-ended tasks that mix web browsing, file system access, and code execution, the kinds of tasks that benefit from a manager agent orchestrating specialists with concrete tools. It has less production adoption than the entries in Sections B and C, but the manager-with-specialists pattern it demonstrates is a concrete instance of the hierarchical topology with strong empirical results on GAIA and other agent benchmarks, and Microsoft Agent Framework now ships it as a built-in orchestration.

For event-driven coordination with typed events between steps, see Volume 4, LlamaIndex Workflows.

Pattern · 12 of 16

Microsoft Magentic-One

Pattern page →

Classification Research-oriented multi-agent framework with manager-plus-specialists pattern.

Source: arxiv.org/abs/2411.04468; Magentic orchestration in Microsoft Agent Framework (learn.microsoft.com/en-us/agent-framework/user-guide/workflows/orchestrations/magentic)

Intent

Provide a research-grade implementation of the manager-plus-specialists hierarchical pattern, with concrete specialists for web browsing (WebSurfer), file operations (FileSurfer), code execution (Coder, ComputerTerminal), and an Orchestrator that manages the team.

Motivating Problem

For the class of agent tasks that mix web browsing, file system access, and code execution --- the kind of work that benchmark suites like GAIA, AssistantBench, and WebArena test --- a manager-plus-specialists architecture with concrete tools has produced state-of-the-art results in 2024—2025 research. Magentic-One is Microsoft’s reference implementation: an Orchestrator agent that maintains a task ledger and a progress ledger, deciding what to do next and which specialist to dispatch; four specialist agents with focused tools. The original implementation was layered on AutoGen v0.4 (its standalone package was folded into AutoGen’s MagenticOneGroupChat); with AutoGen no longer maintained, Microsoft Agent Framework carries the pattern forward as its Magentic orchestration, in which a Magentic manager keeps shared context, tracks progress and picks the next agent.

How It Works

The Orchestrator maintains two ledgers. The task ledger tracks what needs to be done: known facts about the task, key facts to gather, plan steps. The progress ledger tracks whether each step is making progress, with explicit decisions to advance, retry, or replan. On each iteration, the Orchestrator consults the ledgers and dispatches the appropriate specialist.

WebSurfer drives a browser (Playwright-based) to navigate, read pages, and interact with web UIs. FileSurfer reads and navigates the file system. Coder writes code; ComputerTerminal executes shell commands. Each specialist has a tightly scoped tool surface, which makes their behavior predictable and their errors interpretable.

The pattern’s contribution is the explicit ledger design and the demonstration that hierarchical-with-concrete-specialists outperforms more emergent patterns on benchmark suites. Magentic-One as a deployable framework is research-grade rather than production-grade; the pattern itself is influential and is reimplemented in production frameworks (LangGraph and CrewAI both have manager-plus-specialists tutorials echoing the design).

When to Use It

Research benchmarking on open-ended agent tasks. Reference implementation for the manager-plus-specialists pattern. Studies of how explicit ledger design affects agent behavior. Cases where the specialist-toolset model (web, file, code, terminal) matches the deployment target.

Alternatives --- production frameworks (LangGraph, CrewAI, AG2) implementing similar patterns for production use cases. Browser-use, Aider, Devin-style products for the specific verticals Magentic-One demonstrates.

Sources

arxiv.org/abs/2411.04468
learn.microsoft.com/en-us/agent-framework/user-guide/workflows/orchestrations/magentic

Section E — Coordination patterns as code

Agents-as-tools, with planner-executor and critic loops in Volume 1

Some coordination patterns recur across frameworks and are worth treating as patterns rather than as framework features: when the design calls for one, the framework is the substrate and the pattern is the actual architectural decision.

Two of them are single-workflow patterns that Volume 1 owns. For planner-executor, see Volume 1, Plan-and-Execute. The multi-agent version adds one design decision worth stating here: whether the executor only reports failures back to the planner, or the planner reviews progress on a schedule and replans from what execution has actually learned; Magentic-One’s task and progress ledgers (Section D) are the worked example of the second. For critic-and-reflection loops (a producer and a critic iterating to approval under an iteration cap), see Volume 1, Evaluator-Optimizer and Reflexion; running the critic on a different model from the producer reduces self-preference bias (Volume 8).

The pattern this section covers is the one that is specific to multi-agent design: calling another agent as a tool, so the caller keeps control.

Pattern · 13 of 16

Agents-as-tools

Pattern page →

Classification Coordination pattern: an orchestrator calls specialist agents as tools and keeps control of the conversation.

Source: OpenAI Agents SDK (agent.as_tool); Strands Agents; Google ADK (AgentTool)

Intent

Let an orchestrator agent delegate a sub-task to a specialist agent through an ordinary tool call, receive the specialist’s answer as the tool result, and keep ownership of the conversation, instead of transferring control to the specialist.

Motivating Problem

Hand-offs (OpenAI Agents SDK, ADK sub-agent transfer) move the conversation to the specialist: once the triage agent hands off to billing, billing answers the user from then on. That is right for routing, and wrong when one request needs several specialists’ answers combined, or when one agent must stay accountable for the reply. Letting the orchestrator call specialists as tools keeps a single owner, and gives each specialist a fresh, focused context instead of the whole conversation.

How It Works

The framework wraps an agent as a tool with a name and description. When the orchestrator’s model calls that tool, the framework runs the wrapped agent on the tool input in its own run, then returns its final output to the orchestrator as the tool result. The orchestrator can call several specialists in one turn, compare or merge their answers, and decide what the user sees. ADK’s documentation states the contrast with sub-agents directly: with Agent-as-a-Tool, Agent A gets Agent B’s answer back and keeps handling the user; with a sub-agent, responsibility for answering passes to Agent B.

The pattern is a first-class API in several frameworks. OpenAI Agents SDK has agent.as_tool(), with options for max_turns, structured input, approval gates (needs_approval) and custom output extraction. Strands Agents accepts agents directly in a tools list, through .as_tool(), or wrapped in its @tool decorator, and can call remote agents over A2A. ADK wraps an agent with AgentTool, with an option to skip the summarization step when the specialist’s output is already well formed. An MCP server that wraps an agent (Section A) is the same pattern across a process boundary.

Context isolation is the trade-off. The specialist sees only the tool input, not the orchestrator’s conversation, so the orchestrator has to pass what the specialist needs; and the orchestrator sees only the result, not the specialist’s reasoning. This is the structured hand-off of Chapter 5 by design. Claude’s subagents work the same way (Volume 18, Project subagents).

When to Use It

Requests that need answers from several specialists combined into one reply. Designs where one agent must remain accountable for every response. Delegating context-heavy sub-tasks so they do not fill the orchestrator’s context window. Hierarchical topologies (Chapter 2) built on plain tool calls.

Alternatives --- hand-offs (OpenAI Agents SDK, ADK sub-agents) when the specialist should take over the conversation; shared state (Section F) when agents need to see each other’s full work; plain function tools when the “specialist” does not need its own model loop.

Sources

openai.github.io/openai-agents-python/tools/#agents-as-tools
strandsagents.com/latest/documentation/docs/user-guide/concepts/multi-agent/agents-as-tools/
adk.dev/tools-custom/function-tools/

Example artifacts

Code.

from agents import Agent, Runner

spanish = Agent(name="Spanish agent", instructions="Translate the user's message to Spanish.")
french = Agent(name="French agent", instructions="Translate the user's message to French.")

orchestrator = Agent(
    name="Translator",
    instructions="Use your tools to translate. For several languages, call each tool.",
    tools=[
        spanish.as_tool(tool_name="translate_to_spanish",
                        tool_description="Translate the user's message to Spanish"),
        french.as_tool(tool_name="translate_to_french",
                       tool_description="Translate the user's message to French"),
    ],
)

result = Runner.run_sync(orchestrator, "Say 'Hello, how are you?' in Spanish and French.")
print(result.final_output)   # the orchestrator, not a specialist, writes the reply

Section F — Shared-state patterns

The blackboard and its scratchpad variant: avoiding hand-offs by avoiding hand-offs

The hand-off problem (Chapter 5) is structurally avoidable when agents share state instead of passing messages. The blackboard pattern is the structured form: a central workspace where each agent contributes typed artifacts (research findings, draft sections, critiques) and agents are activated based on what artifacts are present. Its unstructured variant, the shared scratchpad, drops the typed slots and activation rules: agents simply read and write a common state dictionary in an order fixed at design time. The entry below covers both.

The pattern is implementable in LangGraph (via the shared state model), CrewAI (via context-sharing), and AG2 (via group-chat shared history). The scratchpad variant is sufficient for most cases; the full blackboard pays for itself when many agents contribute many artifact types.

Pattern · 14 of 16

The blackboard pattern

Pattern page →

Classification Coordination pattern: structured shared workspace with typed artifacts.

Source: Classical AI pattern (1980s); modern implementations in LangGraph and custom frameworks

Intent

Provide a structured shared workspace where each agent contributes typed artifacts and agent activation depends on which artifacts are present, supporting opportunistic and emergent coordination patterns.

Motivating Problem

Message-passing between agents loses information (Chapter 5); shared state removes the loss by making the state visible to all agents at all times. The simplest form, a shared scratchpad, is the multi-agent equivalent of a global variable and works for designs where the coordination is fixed at design time. For designs where the coordination is dynamic --- different agents activate based on what’s currently on the workspace, the order is not predetermined, multiple agents may contribute to the same artifact type --- the blackboard pattern adds structure: typed artifact slots, agent activation conditions, and explicit support for opportunistic coordination.

How It Works

Scratchpad variant first: define a state schema (TypedDict, Pydantic model, or framework equivalent); each agent takes the current state and returns an update; the framework applies the update and passes the new state on, so every agent sees the cumulative state. The schema is the coordination contract (which fields each agent reads and writes), so naming matters. When several agents write the same field, last write wins unless each field has a merge function (concatenation for lists, set union, max); LangGraph supports a custom reducer per field for exactly this.

The full blackboard is a structured workspace with named artifact slots: research_findings (list), draft_sections (dict by section name), critiques (list), decisions (list), and so on. Each agent has an activation condition (“activate when research_findings has at least 3 entries and draft_sections is empty”) and a contribution pattern (“when activated, produce draft_sections entries”). A scheduler activates agents whose conditions are met; agents contribute artifacts; the scheduler reevaluates conditions; the loop continues until termination (no agents activate, or a designated completion condition is reached).

The pattern’s strengths are emergent coordination (the system can handle workflows that weren’t pre-specified) and opportunistic parallelism (agents whose conditions are simultaneously met can run in parallel). The trade-offs are debugging difficulty (the trace shows what happened but not why this particular order emerged) and termination correctness (designing termination conditions that catch all the legitimate completion cases without false positives or infinite loops).

Modern multi-agent frameworks implement the pattern with varying degrees of explicitness. LangGraph state with conditional routing approximates it; CrewAI’s context-and-task model leans toward it for hierarchical processes; AutoGen’s group chat with speaker selection logic implements a version of it. Dedicated blackboard frameworks exist but have less adoption than the general-purpose alternatives.

When to Use It

Multi-agent designs with dynamic coordination patterns. Workflows where agent activation depends on workspace state rather than a fixed plan. Research-style workflows with opportunistic discovery. Production systems where the work shape varies enough that a fixed pipeline would be wrong.

Alternatives --- the scratchpad variant for simpler designs. Explicit graphs (LangGraph supervisor pattern) for designs that can be fixed at design time. Explicit message-passing when the agents legitimately should not share state (cross-organization boundaries, trust zones). Custom orchestration when the framework abstractions don’t fit.

Sources

Engelmore & Morgan, Blackboard Systems (Addison-Wesley, 1988)
docs.langchain.com/oss/python/langgraph/graph-api (state and reducers)

Section G — Multi-agent observability

How Volume 7’s tracing tools extend to multi-agent systems

Multi-agent systems need everything Volume 7’s observability layer provides (trace trees, audit records, debug surfaces) plus several multi-agent-specific concerns: cross-agent trace correlation (when agent A calls agent B, the trace must span both), agent identity (which agent made this decision), conversation reconstruction (replaying the agent-to-agent conversation), and inter-agent metrics (how often did agent A invoke agent B, what was the success rate of that hand-off). The good news is that the major observability platforms (LangSmith, Phoenix, Langfuse) extend naturally to multi-agent through the same trace-tree mental model; the additional structure is handled through span metadata rather than fundamentally new abstractions.

Pattern · 15 of 16

Multi-agent tracing across LangSmith, Phoenix, Langfuse

Pattern page →

Classification Observability pattern for tracing multi-agent systems.

Source: Volume 7’s observability platforms, extended via OpenInference multi-agent conventions

Intent

Extend the trace-tree mental model from Volume 7 to multi-agent systems by adding agent identity to spans, correlating cross-agent calls, and capturing inter-agent metrics, with the major observability platforms providing native support through OpenInference’s multi-agent attribute conventions.

Motivating Problem

A trace tree for a single-agent run has a clear shape: one thread, one or more runs, steps within runs, LLM and tool calls within steps. A trace tree for a multi-agent run has the same shape but with additional structure: each span belongs to a specific agent; cross-agent calls span agent boundaries; the trace UI needs to make agent identity visible so engineers can answer questions like “which agent made this decision” and “how many times did the supervisor invoke each worker.”

How It Works

The OpenInference specification (Volume 7, OpenInference) has agent-specific attributes: openinference.span.kind = “AGENT” for spans representing whole agent invocations; agent.name for the agent’s identifier; and session.id to group cross-agent calls into a single logical conversation. The OpenTelemetry GenAI conventions use gen_ai.agent.name and gen_ai.conversation.id for the same two jobs. Spans tagged with these attributes render in observability platforms with agent identity made visible.

Cross-agent call correlation works through standard OTel context propagation. When agent A calls agent B (whether through an in-process function call, an MCP server call, an A2A protocol call, or any other mechanism), the trace context propagates with the call, and agent B’s spans become children of agent A’s span in the trace tree. The trace then shows the full cross-agent flow as a single connected tree.

Inter-agent metrics are derivable from the trace data. Hand-off counts, agent latency distributions, success and failure rates per agent, conversation length distributions, branching factor at supervisor decisions --- all of these are aggregations over the trace data that the observability platforms compute and surface. Production deployments use these metrics to identify which agents are bottlenecks, which hand-offs frequently fail, and which conversation patterns produce the best outcomes.

When to Use It

Any production multi-agent deployment needing observability. Debugging cross-agent failures. Operational visibility into which agents are doing what. Audit and compliance documentation for agent decisions.

Alternatives --- custom logging when the framework integration doesn’t fit. Print-debugging during early development before observability matters. Application-specific dashboards for the high-level metrics that the generic platforms surface but don’t prioritize.

Sources

github.com/Arize-ai/openinference/blob/main/spec/semantic_conventions.md

Section H — Discovery and directories

The AGNTCY Agent Directory

For multi-agent systems that may need to discover agents from outside the local deployment --- agents in other organizations, agents from third-party vendors, agents whose endpoints aren’t known at design time --- a directory service is the missing piece. A2A deliberately leaves registries out of its specification, so directories sit beside it. The AGNTCY Agent Directory (Linux Foundation) is one open cross-organization agent directory, alongside the MCP Registry for MCP servers (Section A; Volume 5). For ecosystem-tracking resources (curated lists, research feeds), see Appendix D.

Pattern · 16 of 16

AGNTCY Agent Directory

Pattern page →

Classification Discovery infrastructure: a distributed, cross-organization agent directory.

Source: github.com/agntcy/dir (AGNTCY, Linux Foundation; Apache-2.0)

Intent

Let agents be published, found and checked across organizations through a shared directory of signed, structured records, so a client can find an agent by what it can do rather than by a URL it already knows.

Motivating Problem

Multi-agent systems that stay within one organization can use private agent registries or configured URLs; multi-agent systems that span organizations need cross-organization discovery, a way to match capabilities to a need, and a way to trust what a listing claims. A2A’s well-known Agent Card URL answers “what can this agent do” only once you know where the agent is. The AGNTCY directory addresses the step before that.

How It Works

Agents publish OASF (Open Agentic Schema Framework) records to the directory; a record describes the agent’s capabilities in a hierarchical taxonomy and can reference an A2A Agent Card or an MCP server. Clients search the directory by attributes and constraints. Records are content-addressed and signed, so a client can verify integrity and where a record came from, and records can be linked (version histories, dependencies between composite agents). The directory runs as a peer-to-peer network of nodes using distributed hash tables, with a CLI, SDKs and gRPC APIs.

AGNTCY itself was open-sourced by Cisco in March 2025 with LangChain and Galileo and joined the Linux Foundation in July 2025, with Cisco, Dell, Google Cloud, Oracle and Red Hat as formative members. Its earlier wire protocol (Agent Connect Protocol) is archived; the project now builds on A2A and MCP and supplies the surrounding infrastructure: the directory, OASF, identity, and the SLIM messaging transport.

When to Use It

Cross-organization agent discovery where clients do not know agent endpoints in advance. Marketplaces or internal catalogs that need verifiable, signed agent listings. Not needed when every agent a system calls is configured by URL.

Alternatives --- a private registry or configuration file for agents inside one organization; the MCP Registry when what is being discovered is MCP servers; curated A2A catalogs.

Sources

github.com/agntcy/dir
github.com/agntcy/oasf
linuxfoundation.org/press/linux-foundation-welcomes-the-agntcy-project-to-standardize-open-multi-agent-system-infrastructure-and-break-down-ai-agent-silos

Appendix A --- Topology Reference Table

Cross-reference between the five coordination topologies (Chapter 2) and their representative implementations.

Topology	Characteristic	Representative implementations
Hierarchical	Manager dispatches; workers execute	LangGraph supervisor, CrewAI hierarchical
Sequential	Pipeline; each agent transforms	CrewAI sequential, linear LangGraph chains
Peer network	Agents talk freely; emergent structure	AG2 GroupChat
Hub-and-spoke	Central router; specialist endpoints	OpenAI Agents SDK handoffs
Blackboard	Shared workspace; opportunistic	LangGraph shared state, CrewAI context

Appendix B --- The Series

This catalog joined the eight prior volumes to form a nine-layer vocabulary for agentic AI; the series has since grown to nineteen volumes. The volumes are independent and the reading order is flexible; the cross-references make whichever path the reader chooses coherent.

Volume 1 --- Patterns of AI Agent Workflows --- the timing of agent runs.
Volume 2 --- The Claude Skills Catalog --- model instructions in packaged form.
Volume 3 --- The AI Agent Tools Catalog --- the function-calling primitives.
Volume 4 --- The AI Agent Events & Triggers Catalog --- the activation layer.
Volume 5 --- The AI Agent Fabric Catalog --- the infrastructure substrate.
Volume 6 --- The AI Agent Memory Catalog --- the state and context layer.
Volume 7 --- The Human-in-the-Loop Catalog --- the human-agent interaction layer.
Volume 8 --- The Evaluation & Guardrails Catalog --- the governance layer.
Volume 9 --- The Multi-Agent Coordination Catalog (this volume) --- the agent-to-agent communication layer.

Nine layers. The first eight describe what a single agent system needs (patterns, skills, tools, events, fabric, memory, human interaction, governance). The ninth describes what happens when a single agent isn’t enough --- when multiple agents need to coordinate, communicate, and collaborate. Volume 9 builds on every prior volume: agents need patterns for their runs, skills and tools for their work, events to trigger them, fabric to run on, memory to persist, humans to approve and observe, evaluation and guardrails to govern, and --- in the multi-agent case --- protocols and frameworks to communicate.

The series can be read top-down for the agent designer’s sequence: how do individual agent runs compose, what do they know, what can they call, what triggers them, where do they run, what state do they carry, how do humans interact with them, how is the system tested and defended, and --- if more than one agent --- how do they coordinate. It can be read bottom-up for the operator’s sequence: how do humans approve and observe, what state lives where, what fabric supports it, what events drive it, what tools the agents use, what skills ship with them, what patterns their runs follow, how the whole thing is governed, and how the agents communicate when there are multiple. The multi-agent volume sits at the top of the stack in the sense that it presumes everything beneath; it sits at the periphery of the stack in the sense that most applications don’t need it.

Appendix C --- The Multi-Agent Anti-Patterns

Seven recurring mistakes that distinguish working multi-agent designs from the rest. Avoiding these is most of the practical wisdom in the field:

Defaulting to multi-agent. Most applications don’t need multi-agent. Single-agent-with-good-tools handles most cases better. Multi-agent is a power tool; reaching for it as a default produces slower, less reliable, more expensive systems with no quality lift to justify the cost.
Ignoring the hand-off problem. Free-form summary hand-offs between agents lose information at every boundary. Multi-agent systems that don’t address the hand-off problem (with structured hand-offs or shared workspaces) frequently underperform single agents on the same task.
Theatrical role specialization. Splitting a single agent’s work across multiple agents whose roles are nominally different but functionally similar produces complexity without benefit. If the researcher, writer, and critic all have the same tools and similar prompts, they’re the same agent under three names.
Peer-network designs without orchestration scaffolding. Letting agents talk to each other freely without termination conditions, conversation budgets, or supervisor scaffolding produces conversation explosion: agents talking endlessly to each other, consuming tokens, not converging.
Coupling agent logic to specific protocols. Agents whose capabilities are tangled with MCP-specific or A2A-specific code can’t migrate when the protocol landscape shifts. Separate the agent’s capability from the protocol binding.
Skipping multi-agent observability. The trace-tree from Volume 7 is harder to extend to multi-agent but more necessary, not less. Multi-agent systems without proper tracing are nearly impossible to debug in production.
Over-engineering the topology. Mixing all five topologies in a single design produces incoherent systems. Most working multi-agent designs use two topologies thoughtfully (typically hierarchical and shared-state, or hub-and-spoke and sequential) rather than mixing all of them ad-hoc.

Appendix D --- Discovery and Standards

Resources for tracking the multi-agent coordination ecosystem as it evolves:

modelcontextprotocol.io --- MCP specification and ecosystem hub.
a2a-protocol.org: A2A protocol specification and reference implementations (Linux Foundation).
agentclientprotocol.com: Agent Client Protocol specification, agent and client lists.
ap2-protocol.org, agenticcommerce.dev, github.com/x402-foundation/x402: the agent payment protocols.
agntcy.org: Linux Foundation’s AGNTCY project, with Agent Directory, OASF, identity, and the SLIM transport.
Anthropic’s multi-agent research papers --- honest empirical work including the 15× token-usage finding that motivates this catalog’s opening warning.
LangGraph multi-agent documentation --- the explicit-graph reference for hierarchical and supervisor patterns.
CrewAI documentation --- the role-based reference design.
OpenAI Agents SDK --- the hand-off-centric reference design.
Magentic-One paper (arxiv.org/abs/2411.04468) --- the manager-plus-specialists pattern with benchmark results.
Conference proceedings: NeurIPS, ICLR, ICML, ACL, COLM track the academic state of multi-agent systems.
arXiv cs.MA (arxiv.org/list/cs.MA/recent): the Multi-Agent Systems category; noisier than curated lists but the most current feed of research.
GitHub topic multi-agent-systems (github.com/topics/multi-agent-systems): community-curated awesome lists (frameworks, papers, products) and projects, updated by pull request.

Two pragmatic recommendations. First, before adopting multi-agent for any production application, do the single-agent baseline. Build the single agent with good tools first; measure its performance against the target metrics; only then evaluate whether multi-agent earns the additional cost. The discipline saves significant engineering investment and produces clearer evidence of when multi-agent actually helps. Second, default to shared-state designs (LangGraph state, CrewAI context, AG2 group chat) for the cases where multi-agent is warranted. The hand-off problem is the single biggest source of multi-agent quality issues; shared-state designs dissolve it. Use explicit hand-offs only when the boundary is genuine (across organizations, trust zones, or compliance boundaries) and accept the engineering cost of designing the hand-off structure carefully when it must be done.

Appendix E --- Omissions

This catalog covers about 16 substrates across 8 sections. The wider multi-agent ecosystem is significantly larger; a non-exhaustive list of what isn’t here:

General distributed-systems frameworks (Akka, Erlang OTP, Ray Actors) when used outside the AI-specific multi-agent context.
Game-theoretic multi-agent systems research (cooperative game theory, mechanism design, market mechanisms for agent coordination) that hasn’t productized into working frameworks.
Agent simulation environments (Stanford generative agents, ChatDev, Voyager) when treated as research artifacts rather than production substrates.
Vertical-specific multi-agent products (Devin and similar coding agents, Manus and similar generalist agents) that implement specific multi-agent patterns under the hood without exposing them as frameworks.
Specialized multi-agent infrastructure (E2B, Modal, Replicate as deployment substrates for agents) when treated outside the multi-agent coordination context.
Multi-agent benchmarks (GAIA, AssistantBench, WebArena, AgentBench) which are evaluation resources rather than coordination substrates.

Appendix F --- A Note on the Moving Target

MCP shipped in November 2024. A2A in April 2025. Both moved to Linux Foundation governance within the next year, and IBM’s ACP merged into A2A in August 2025. AGNTCY joined the Linux Foundation in July 2025. LangGraph’s supervisor pattern emerged across 2024. CrewAI matured through 2024 and 2025. OpenAI Agents SDK released in 2025 as the production successor to Swarm. AutoGen v0.4 rewrote the framework on an actor model. AG2 forked from AutoGen, and Microsoft later stopped maintaining AutoGen in favor of Microsoft Agent Framework. Google’s ADK arrived with native A2A. Coding agents converged on the Agent Client Protocol for editors, and agent payments got their own protocols (AP2, Agentic Commerce Protocol, x402). Anthropic’s multi-agent research paper landed in 2025 with its 15×-token finding. Magentic-One published in late 2024. The category moved from “research and prototypes” to “production frameworks with empirical guidance” across roughly 24 months.

The deepest structural facts are stable. Multi-agent is a power tool with real costs and conditional benefits; default to single-agent unless the multi-agent design solves a specific problem the single-agent design can’t. Five coordination topologies (hierarchical, sequential, peer, hub-and-spoke, blackboard) capture the working patterns; production systems combine two or three thoughtfully. Two main communication protocols (MCP for tools and context, A2A for agent-to-agent) have absorbed most of the field, with narrower protocols for editors and payments beside them; further consolidation is possible but uncertain. Three specialization axes (role, domain, skill) carve up the work; production systems combine them. The hand-off problem is the unsolved structural difficulty of multi-agent design; shared-state patterns are the strongest mitigation. An architect who internalizes these structural facts can map any new framework or protocol onto the design space; an architect who learns only the products has to relearn the field every year.

Nine volumes at the time of writing (the series has since grown to nineteen). Patterns, Skills, Tools, Events, Fabric, Memory, Human-in-the-Loop, Evaluation & Guardrails, Multi-Agent Coordination. The vocabulary covers the full design space of agentic AI as of mid-2026. The products will change; the vocabulary will adapt; the structural understanding will hold up. That’s the value of catalogs over manuals.

--- End of The Multi-Agent Coordination Catalog v0.1 ---