The protocol landscape

Chapters 50 and 51 covered MCP and A2A, the two protocols this book leans on. But 2026 has produced more, and a reader deserves the whole map plus the discipline to not drown in it. The organizing insight is simple and makes the map legible at a glance: agent protocols standardize the boundaries an agent talks across, and there are only a few boundaries. Name the boundary and you name the protocol; the proliferation is mostly different groups standardizing the same few edges.

The boundaries, and their protocols

An agent talks across four boundaries, and each has an emerging or settled standard:

                    +-------------------+
   agent  --MCP-->  |  a TOOL           |   (typed call, immediate result)
                    +-------------------+
                    +-------------------+
   agent  --A2A-->  |  another AGENT    |   (long-lived task, a counterparty)
                    +-------------------+
                    +-------------------+
   agent --AG-UI--> |  a FRONTEND/USER  |   (streamed UI, human interaction)
                    +-------------------+
                    +-------------------+
   agent  --ACP-->  |  another AGENT    |   (REST-style agent comms; see below)
                    +-------------------+
  • MCP (Model Context Protocol) is the agent-to-tool boundary: JSON-RPC, tools/list, tools/call. Settled, ubiquitous, and built from scratch in this book. When an agent reaches a capability, it is MCP.
  • A2A (Agent2Agent) is the agent-to-agent boundary: signed agent cards for discovery, long-lived tasks with a lifecycle. Under the Linux Foundation, version 1.x, real but early. When an agent hires a counterparty, it is A2A.
  • AG-UI (Agent-User Interaction Protocol) is the agent-to-frontend boundary, the one MCP and A2A do not cover: a standard event stream for an agent to drive a user interface (render progress, stream tokens, request input, show tool activity) so any AG-UI frontend can talk to any AG-UI agent backend. It is the newest of the three and solves a genuinely different problem, the human-facing edge, which is why it is worth knowing rather than dismissing as redundant.
  • ACP (Agent Communication Protocol) was another agent-to-agent standard, REST-first, from the IBM/BeeAI orbit, and it is the clearest evidence of consolidation: in 2025 ACP merged into A2A under the Linux Foundation, its team winding down separate development and contributing into A2A, and BeeAI itself moving to A2A. The practical takeaway is decisive: the agent-to-agent edge did not stay fragmented, it consolidated onto A2A, so bet there. (Watch a name collision: a different "Agent Connect Protocol," also abbreviated ACP, belongs to AGNTCY below.)

Beyond these, the coalition effort AGNTCY (a Cisco-led "internet of agents" initiative, now under the Linux Foundation's agentic-AI umbrella) sits underneath the boundary protocols rather than competing with them: it standardizes discovery and identity (an Open Agent Schema Framework, and its own Agent Connect Protocol for invoking remote agents), the "how do agents find and identify each other" layer beneath A2A's "how do they talk." For a platform builder in 2026, the signal in the noise is a two-layer reference stack, MCP for agent-to-tool and A2A for agent-to-agent, with AG-UI answering the frontend boundary and AGNTCY/OASF providing discovery and identity underneath.

What to adopt, and when

The Chapter 51 discipline, extended across the map, in sequencing order:

  1. Your own schemas, always first. The result and event schemas of your ledger are the platform's real internal protocol; get them right before any external standard.
  2. MCP now, for shared, third-party, or separately-deployed tools. Mature, in use, and you understand it completely.
  3. AG-UI when you have a rich agent frontend that would otherwise need a bespoke streaming protocol between your UI and your agents, the case where a standard saves you from inventing one.
  4. A2A when a real cross-boundary counterparty appears, not speculatively, and prefer it over ACP unless a specific partner dictates otherwise, because A2A is where the agent-to-agent boundary is consolidating.

The anti-pattern the whole chapter guards against is protocol-driven architecture: adopting standards because they exist rather than because a boundary in your system needs standardizing. A single-organization platform whose agents coordinate through a shared control plane needs none of the agent-to-agent protocols, and reaching for A2A or ACP there is building a telephone network with no one to call. Name your boundaries; adopt the protocol for the boundaries you actually have.

Don't be confused: a protocol standardizes a boundary, it does not create the need to cross one. Every protocol in this chapter is an interoperability technology: it makes crossing a boundary portable and vendor-neutral. It does not make crossing the boundary valuable, that comes from a real tool worth calling, a real counterparty worth hiring, or a real frontend worth driving. The 2026 protocol boom can read as "you need all of these," when the truth is you need a protocol exactly for each boundary your architecture genuinely spans, and for most single-org platforms that is MCP for tools and nothing else until a frontend or a partner appears.

👉 Next: the supporting-platform layer, the eval, observability, and model-routing platforms (LangSmith, Langfuse, Phoenix, Braintrust, Ragas, promptfoo, LiteLLM) that surround the agent, and the buy-versus-build decision for each against the planes this book built.