In April, the Linux Foundation published A2A’s one-year report card: more than 150 supporting organizations, integrations across Google Cloud, Azure, and AWS, and production deployments in supply chain, financial services, insurance, and IT operations. A year ago the protocol looked like Google’s answer to a question nobody had asked yet. The v1.0 release — and, just as importantly, where its governance landed — changed my read.
Here’s the architecture that’s crystallizing, and what I think platform teams should actually do about it.
Two layers, perpendicular problems
MCP is vertical. It standardizes how one agent reaches down into tools, data sources, and context. When your incident agent queries Prometheus, tails logs, or restarts a deployment, that’s MCP territory — the agent’s hands.
A2A is horizontal. It standardizes how agents reach sideways to other agents: discovery (“what can you do?”), task exchange, long-running coordination — across teams, vendors, and organizational boundaries. Not hands; a handshake.
The Linux Foundation’s own framing is exactly this: A2A “defines how agents communicate and coordinate with each other across organizational boundaries, while MCP defines how agents connect to internal tools and data sources.” With MCP, A2A, and ACP all now under LF governance, the convergence story has institutional weight it lacked a year ago, and the two-layer stack is quietly becoming the default answer in enterprise architecture reviews.
The composition matters more than either protocol alone. An agent that speaks MCP downward and A2A sideways is a service in every sense your platform already understands — it has an interface, an identity, dependencies, and consumers. Which means the operational playbook you already own mostly applies. Mostly.
What v1.0 shipped that an SRE should care about
Most of the v1.0 release notes are enterprise table stakes — multi-protocol support, multi-tenancy, a migration path. Two items are more than that:
Signed Agent Cards. An Agent Card is A2A’s discovery document: what an agent can do, where to reach it, what it needs. v1.0 makes them cryptographically signed — verifiable agent identity at the protocol layer. If you’ve read my argument that agents need identities, not API keys, you’ll recognize why I think this is the most important line in the release: it’s the ecosystem conceding that anonymous agents don’t survive contact with the enterprise.
Web-aligned security flows. The modernized auth story means agent-to-agent calls can ride the same OAuth-shaped rails your services already use, instead of inventing a parallel trust system your security team has never audited.
Discovery deserves a note too. Agent Cards formalize advertisement — an agent stating its capabilities. That composes with the discovery problem I wrote about in Agentic Resource Discovery: advertisement without governance is how you get a mesh of agents finding each other that nobody can enumerate. The card format is the easy half; the registry with an opinion about who may discover whom is still on you.
The new failure domain
Every cross-agent call is a distributed-systems edge with two autonomous ends. That’s the part I’d budget engineering time for, because the failure modes stack:
- The classics, amplified. Timeouts, retries, backpressure — but now a “retry” might be an agent re-running a task with side effects, and backpressure might mean an agent queueing decisions on stale context.
- Untrusted input with a friendly tone. An inbound agent message is data, and data steers models. OWASP’s agentic Top 10 tracks this as insecure inter-agent communication — I’ve mapped what that means at the platform layer, and the summary is: authenticate, validate, and never let another org’s agent output flow raw into your agent’s context.
- Compounding speed. When both ends act autonomously, a wrong answer propagates at machine speed through systems that do things. Circuit breakers between agents aren’t optional decoration; they’re the difference between one confused agent and a confused fleet.
- Observability across the boundary. When a task hops from your agent to a vendor’s and back, your trace had better hop with it. The OTel GenAI conventions give you the span vocabulary; propagating context through A2A calls is the integration work that makes a cross-org incident debuggable instead of a two-company email thread.
When you actually need this
Here’s the unfashionable part: most teams don’t need A2A yet, and adopting it early buys complexity without capability. If your “multi-agent system” is one orchestrator delegating to sub-agents it spawned inside one runtime, the framework’s internal messaging is simpler, faster, and easier to debug than a formal protocol. That’s not a failure of ambition — it matches where most teams sit on the agentic maturity curve.
A2A earns its keep at trust boundaries: your agents talking to a vendor’s agents, two business units coordinating without shared infrastructure, an ecosystem where partners’ agents interoperate. The test is concrete — can you name the boundary two agents must cross? If yes, A2A is now the obvious standard to build on. If not, file it under “watch” and keep your MCP layer clean; a well-factored vertical layer is what makes the horizontal one easy to add later.
Honest caveats
Adoption press releases count supporting organizations, not production deployments, and independent reads of A2A’s first year note the gap between logo walls and load-bearing use. Protocol landscapes this young consolidate unpredictably — ACP’s arc shows features migrating between specs, and “the stack” of 2027 may look different in the details. And a signed Agent Card verifies identity, not intent: knowing exactly who sent the message doesn’t make the message safe. The trust decisions stay yours.
What to do Monday
- Draw your agent topology and mark the trust boundaries. Agents inside one runtime, agents across teams, agents across orgs. Only the last two are A2A conversations.
- Keep the layers separate in your designs. Tool access goes through MCP and its gateway; agent coordination is a different edge with different controls. Designs that blur them inherit both layers’ failure modes with neither layer’s discipline.
- Read the Agent Card spec even if you’re not adopting A2A — it’s becoming the de facto vocabulary for describing agent capabilities, and your internal agent catalog might as well speak it.
- Extend trace propagation to any cross-agent call you already have. If a task crosses a boundary today and your traces don’t, that’s the gap to close first.
- Write the inbound-agent-message policy now. Authentication required, content validated, context quarantined. One paragraph, before the first partner integration makes it urgent.
The 2026 protocol story isn’t that agents got a new standard; it’s that agent systems are being decomposed along the same seam as everything else we operate — a vertical layer for capability, a horizontal layer for coordination. We’ve run that architecture for fifteen years. The names changed. The discipline didn’t.