Don't Conflate Orchestration With MCP and A2A

MCP standardizes connecting context and tools, A2A describes the interaction of remote agents, and orchestration decides who works and when in your application. These are three different layers. MCP is agent-to-tool: discovery and invocation of an external server's capabilities from the host or agent runtime. A2A is agent-to-agent: discovery of a remote agent and a task-oriented exchange across a protocol boundary. Orchestration is control flow: topology, state, budget, permissions, retries, fan-out, and acceptance.

The presence of an MCP server doesn't turn a tool into a separate autonomous worker. The presence of an A2A endpoint doesn't decide whether to call an agent, what budget to pass, and whether the artifact can be accepted. These decisions stay with the control plane. The practical wiring looks like this: the supervisor builds a validated work item; a local worker gets tools through MCP or host functions; a remote specialist is called through A2A only at a protocol boundary; outputs are normalized into the internal Artifact schema; budget, identity, trace, and acceptance stay shared.

A protocol boundary is useful organizationally. A2A makes sense when the agent belongs to another team, service, or trust domain and must publish a contract. For two functions inside one process, an ordinary typed interface is simpler.

This book doesn't repeat the wire-level implementation of MCP and A2A from the previous volume - here the protocols are treated only as transport adapters inside a broader control system. The layers are separated. What remains is to prove usefulness - and that must be done on real, expensive tasks.