On August 20, 2026, Google's A2A protocol formally joined the Agentic AI Foundation (AAIF), placing it alongside Anthropic's Model Context Protocol in a neutral ecosystem backed by every major cloud provider and model lab. That is a governance footnote if your team is still running single-agent demos. It is a procurement lever if your team is deploying multi-agent systems against real work.
Here is the short version: two protocols that together describe nearly the entire coordination layer for modern AI agents - one for how agents talk to tools, one for how agents talk to each other - now share a single vendor-neutral home. With the two core protocols of the agent stack sharing one governance home, shared neutral governance is what turns a promising spec into infrastructure people build on for a decade or more.
How A2A and MCP actually divide the work
The two protocols solve different problems at different layers. MCP focuses on vertical integration between agents and tools - it standardizes how a model accesses local resources, search results, or enterprise databases. A2A handles horizontal communication between agents: how two autonomous systems negotiate tasks, exchange identity credentials, and maintain state across organizational boundaries.
Think of it this way: MCP is the protocol your agent uses to call a Slack API or query a database. A2A is the protocol your triage agent uses to hand a task to a specialist agent running on a different vendor's platform. The two agents share no memory, see none of each other's prompts, and call none of each other's tools - that opacity is the design principle on which A2A is built. Production agents run both.
The confusion between the two is common enough that it causes real architecture mistakes. Teams pick one and assume they're covered. They're not.
Why governance consolidation is the actual news
A2A became the standard for how agents talk to each other about capability negotiation, task handoff, and replanning across agent boundaries - but while MCP became an AAIF project as part of the foundation forming in December 2025, A2A stayed at the Linux Foundation level. That split mattered because it left the two standards operating under different governance processes, different working groups, and different release cadences.
A2A will become a hosted project of the AAIF, which says it has grown from fewer than 40 members at launch to more than 250, with key backers including Google, Microsoft, Amazon, Anthropic, OpenAI, Bloomberg, Shopify, and Block.
That membership list is what makes this more than a press release. When the same foundation hosts both protocols, spec changes that affect how A2A and MCP interact can be coordinated in one working group rather than negotiated across two bodies. Security patches, versioning, and authentication standards apply consistently across the full stack.
The agent card is the primitive teams should care about
An agent publishes an agent card containing a structured description of what it can do and how to reach it. Other agents read that card, discover capabilities, and delegate tasks without a human brokering the handoff. The exchange is structured, observable, and framework agnostic.
A2A v1.0 added signed agent cards for cryptographic identity verification
- meaning an agent can now prove it is who it claims to be before another agent delegates work to it. That detail matters as soon as you're routing tasks across organizational boundaries or to external vendor agents.
A2A defines discovery through an Agent Card, typically published at /.well-known/agent-card.json, which describes the agent's identity, skills, capabilities, interfaces, and security requirements.
That URL is worth bookmarking. When evaluating any vendor claiming A2A support, check whether their agent actually publishes a valid, versioned card at that path. Many vendors claim protocol support in marketing copy before their implementation is complete. The agent card is the checkable artifact.
Beagle in action#ai-infrastructure, 10:02amWhat teams should actually do with this
Most teams are not yet running true multi-agent systems in production. When engineers in supply chain and financial services started deploying multi-agent systems in production, they encountered the same problem repeatedly: agents built on different frameworks couldn't hand off work to each other without custom integration code written specifically for that pairing. Every new vendor relationship required the same integration work from scratch. The cost wasn't in the agents themselves but in the integrations between them.
A2A and MCP under the same roof does not eliminate that integration work tomorrow. What it does is give teams a stable target to build toward. The practical steps, in order:
- Audit your current agent stack. Which agents are you running, and which of them publish agent cards? If none do, you are already accumulating integration debt.
- Ask every AI vendor the same question. "Does your agent implement A2A v1.0 and publish a signed agent card?" The answer tells you how seriously they are treating interoperability.
- Separate your MCP and A2A concerns in architecture. MCP governs what each agent can access. A2A governs how agents coordinate. Conflating them leads to architectures that are hard to debug when a task handoff fails.
- Watch the AAIF working groups. By adding A2A to related projects like MCP under the same umbrella, the move is set to give companies deploying agentic systems more flexibility to choose providers based on cost or performance. The working groups are where that flexibility gets defined in the spec.
Enterprise AI projects fail at the handoff more than anywhere else - not because the models are wrong, but because the coordination layer was never properly designed. A2A gives teams a production-ready standard for agent discovery, task delegation, and outcome tracking that scales beyond the demo.
A teammate like Beagle - living inside Slack or Teams - is exactly the kind of agent that participates in a multi-agent handoff: it receives a task from an orchestrator, handles the in-channel coordination, and returns a structured result. Whether that handoff is observable and swappable depends on whether the protocols underneath it are open. This week, the protocol layer got more stable.
A2A and MCP: common questions
What is the difference between A2A and MCP?
MCP (Model Context Protocol) connects an agent to its tools and data sources - APIs, databases, file systems. A2A (Agent2Agent) connects one agent to another, handling task delegation, capability discovery, and state handoff across organizational and vendor boundaries. Most production multi-agent systems use both.
What did A2A joining AAIF actually change?
The transfer, announced on August 20, 2026, places A2A alongside MCP in a neutral ecosystem backed by every major cloud provider and model lab. Practically, it means spec changes that affect how the two protocols interact are now coordinated in one working group, reducing the risk of incompatible versioning between the agent's tool layer and its coordination layer.
What is an agent card in A2A?
An agent card is a JSON document published at /.well-known/agent-card.json that describes an agent's identity, capabilities, supported input formats, and authentication requirements. Other agents read it to discover what the agent can do and how to reach it - without any human brokering the handoff. Signed agent cards, introduced in A2A v1.0, add cryptographic identity verification.
Does A2A prevent vendor lock-in?
It narrows the lock-in surface. A2A directly tackles the vendor lock-in issue by enabling agent interoperability across platforms and technology stacks. Through standardized A2A interfaces, organizations can deploy heterogeneous agent ecosystems combining internally built agents, third-party commercial solutions, and open-source tools. The caveat: a vendor can claim A2A compliance without a complete implementation. Checking the published agent card is the fastest way to verify the claim.
Is A2A v1.0 stable enough to build on?
A2A v1.0 shipped in March 2026, adding multi-protocol bindings, version negotiation, multi-tenancy, and signed agent cards. It is already running in production across cloud AI infrastructure, financial services, supply chain, and enterprise IT. The spec is stable enough to architect against. The ecosystem around it - tooling, observability, SDKs - is still maturing.