A2A and the multi-vendor future

The last protocol chapter looks at the newest and least settled layer: agents talking to other agents, across organizational and vendor boundaries. MCP connects an agent to tools; A2A, the Agent2Agent protocol, connects an agent to counterparties, other agents that plan, act, and report back. Chapter 27 already placed it as the third and rarest communication pattern, reserved for genuine cross-boundary cases. This chapter decodes the protocol properly and then does something the hype cycle rarely does: an honest accounting of what is load-bearing in 2026 versus what is still aspiration.

What A2A standardizes

Inside one platform, agents coordinate through the ledger and scheduler you built; there is no need for a protocol when everyone shares a control plane. A2A is for the case where they do not share one: your agent engaging another team's agent, another company's, another vendor's, where there is no common scheduler, no shared trust, no agreed data model. It standardizes the handshake for that:

  • Agent cards. An A2A agent publishes a card, a signed description of what it does, how to reach it, and how to authenticate. This is the discovery layer, the A2A analog of MCP's tools/list: a way to learn a counterparty's capabilities without bespoke integration. The signature matters, because a counterparty you did not write is untrusted, and a signed card is at least a verifiable identity.
  • Tasks and their lifecycle. A2A models an interaction as a task with a lifecycle (submitted, working, input-required, completed, failed), messages and artifacts flowing inside it. This is the key difference from MCP: a tool call is a request and an immediate result, but a task is long-lived, a counterparty may work for minutes, ask for clarification, and return artifacts over time, which is what "hiring an agent" rather than "calling a tool" actually requires.

The governance is part of the story and part of why it is worth taking seriously: A2A was donated to the Linux Foundation, its spec reached 1.0, and the major agent platforms (AgentCore Runtime and Strands on the AWS side) ship support. It sits in the same structural slot for cross-vendor agent interop that MCP occupies for tools, an open, governed standard rather than one vendor's API.

The honest 2026 accounting

Here the design review earns its keep by refusing the hype. A protocol existing, reaching 1.0, and gaining platform support does not make it load-bearing in production, and the candid picture is:

  • MCP is load-bearing today. It solves a problem everyone has right now (connect an agent to tools), the ecosystem is large and real, and you built it because it is genuinely in use. Adopting MCP is a present-tense decision.
  • A2A is real but early. It solves a problem fewer teams have yet, because most agent systems in 2026 are still single-organization: one company's agents doing one company's work, coordinating through a shared control plane where A2A adds nothing. The compelling cross-vendor cases, your procurement agent negotiating with a supplier's sales agent, exist and are growing, but they are the frontier, not the mainstream, and a platform built today is right to treat A2A as a capability to adopt when a real counterparty appears, not a foundation to build on speculatively.

This is not skepticism about the direction; the multi-vendor agent future is plausible and A2A is a credible standard for it. It is discipline about sequencing: build on what solves a problem you have, adopt standards for problems you are about to have, and do not architect around a future that has not arrived. The book has applied that rule throughout, and A2A is where it applies most sharply, because the temptation to build the multi-agent-internet is strongest exactly where the present need is weakest.

What to standardize, in order

Assembling the protocol advice from this part and Chapter 27 into a sequence a real platform can follow:

  1. Your own schemas first. The result and event schemas of your ledger are the platform's real internal protocol, entirely yours, and getting them right matters more than any external standard. Standardize these before looking outward.
  2. MCP for tools, now. It is mature, in use, and you understand it completely. Adopt it for shared, third-party, or separately-deployed tools; keep in-process tools in-process.
  3. A2A when a counterparty is real. When a genuine cross-boundary agent interaction appears, a supplier's agent, a partner's, a vendor's, A2A is the standard to reach for, and it will be more mature then than now. Until then, it is a capability you know exists, not a foundation you build on.

Part 10 closed: the platform meets the ecosystem

Part 10 read three pieces of the ecosystem against the platform the book built: Strands turned out to be thin conveniences over the Part 1 loop, giving you the loop's ergonomics while leaving the control plane yours; MCP was the tool protocol you already built, with genuine discovery economics and a "not for in-process tools" verdict; and A2A is the credible-but-early standard for the multi-vendor future. The through-line is the book's recurring posture, one last time: adopt the ecosystem's conveniences and standards where they solve a real problem, and keep as your own architecture the things, budgets, verification, isolation, scheduling, that no framework or protocol supplies. The frameworks structure a loop; the standards connect across boundaries; the platform is still yours to build, which is what the capstones put to work.

Don't be confused: a protocol vs a solution. A2A (or MCP, or any standard) is a protocol: an agreed way for two parties to talk. It is not a solution to the hard part, which is having two parties worth connecting and a reason to connect them. A standard makes the connection possible and portable; it does not make the cross-vendor agent interaction valuable, that comes from a real task that spans a real boundary. Adopting a protocol before you have the task is building a telephone network with no one to call, which is the exact failure mode the 2026 accounting warns against.

👉 Next, per the map: Part 11's capstones put the whole platform to work on four real jobs, a repository-audit fleet, an incident responder, a document-intake swarm, and a research service, each stating its production gates and ending in a costed, torn-down build.