The A2A core repository passed 22,000 GitHub stars in April 2026, and three weeks into production someone on an enterprise team asked: "Wait, which agent authorized that $50,000 vendor payment at 2 am?" That gap - between a well-designed communication standard and actual organizational accountability - is the most honest way to enter this post.
A2A hit v1.0 in March 2026 with 150+ supporting organizations, Linux Foundation governance, and integrations across Google, Microsoft, and AWS platforms. That is not a draft spec and a few enthusiasts. It is a stable, versioned protocol with SDKs in five languages and production deployments in supply chain, financial services, and IT operations. It deserves a precise explanation - not a hype cycle summary and not a dismissal.
What A2A actually does, and what it does not
A2A is an open standard for communication between AI agents - software agents that can plan, call tools, exchange messages, and complete tasks on a user's behalf. Like HTTP standardized communication between browsers and servers, A2A standardizes how agents talk to other agents, even when they come from different vendors, frameworks, or infrastructure.
The key constraint that A2A respects: agents can discover each other's capabilities and skills, send structured requests, return results, and coordinate work without needing access to one another's internal prompts, memory, or tool stacks. A2A focuses on the interface and contract, not the internals.
The protocol runs on technology every engineering team already knows. It reuses existing, well-understood standards - HTTP, JSON-RPC 2.0, and Server-Sent Events.
Interaction modes include synchronous request/response, streaming for real-time updates, and asynchronous push notifications for long-running tasks.
It is worth being precise about the scope. Where MCP addresses an agent's interaction with its environment - data and tools - A2A targets a different challenge: enabling communication and coordination among the agents themselves.
The production pattern is A2A between agents and MCP between agents and tools. A specialist agent is an MCP client internally and an A2A peer externally. Those are not the same job.
How Agent Cards work - and where they fall short
The foundation of A2A discoverability is the Agent Card - a machine-readable JSON manifest hosted at a well-known endpoint (/.well-known/agent.json). It advertises what the agent can do, how to authenticate, and where to send tasks - analogous to an OpenAPI spec but for autonomous agents rather than REST endpoints.
A client agent can fetch the card from that well-known path and quickly learn whether that remote agent is relevant for the job: does it handle network incidents, can it modify firewall policy, can it query an inventory source, does it support streaming updates, what format does it return?
The card may be signed using JWS, giving a remote caller integrity over the advertised metadata and a cryptographic link to a publisher key.
Here is the production reality that most coverage skips: most production multi-agent deployments in early 2026 use static configuration - agent URLs, credentials, and capabilities are hardcoded or environment-variable-driven.
The protocol specifications describe how agents communicate once discovered; the harder problem is finding the right agents in the first place.
A piece published this week from API Evangelist, who was building an Agent Card section for APIs.io, put it bluntly:
the interesting part is not the section - it is what they found when they went looking. The A2A Protocol, now at v1.0 and governed by the Linux Foundation after being contributed by Google, defines an Agent Card as a JSON manifest an agent publishes at /.well-known/agent-card.json.
Most cards they found were not actually spec-compliant.
The governance gap the spec does not address
This is the non-obvious part, and it matters for anyone building multi-agent systems in a real organization.
Agent interoperability protocols - MCP, A2A, ACP, ANP, and ERC-8004 - have rapidly matured to enable identity, capability discovery, tool access, and message exchange between autonomous agents. However, as enterprises deploy heterogeneous agent fleets that must make collective decisions under governance constraints, a question arises: can these protocols support governed agent communities, or only task-oriented coordination?
A June 2026 arXiv paper ran a systematic gap analysis against six governance dimensions. The resulting gap matrix reveals that voting and dissent preservation are universally absent across all five protocols, and deliberation is absent or at most partial.
A2A is delegation-centric: it answers "which agent can handle this task?" Four official example extensions exist (Secure Passport, Timestamp, Traceability, Agent Gateway Protocol); none addresses governance.
The practical consequence: A2A and ACP are so effective at eliminating integration friction that they have removed the natural "brakes" that used to force governance conversations. The plumbing problem has been solved brilliantly. In doing so, a new class of integration debt has been created - one where organizations borrow speed today at the cost of accountability tomorrow.
AWS Bedrock AgentCore - GA across 15 regions - provides a production agent registry with semantic search, A2A Agent Cards, Cedar-based authorization, lifecycle management, and CloudTrail audit - yet encodes no trust scoring, behavioral reputation, capability verification, or governance primitives. That is not a criticism of AWS. That is the spec as written.
Beagle in action#ops-agents, 10:47amWhere A2A fits in the current agent stack
The stack has settled. By mid-2026, the AI agent protocol ecosystem has converged on a clear stack: MCP for tool access (97M monthly downloads, 5,800+ servers), A2A for agent coordination (150+ organizations, Linux Foundation governance), and AP2 for agent-to-agent payments.
Here is how those layers relate:
| Layer | Protocol | Job | Transport |
|---|---|---|---|
| Tool access | MCP | Agent → external capability | HTTP / JSON-RPC |
| Agent coordination | A2A | Agent → agent task delegation | HTTP / JSON-RPC / SSE |
| Payments | AP2 | Agent → agent transactions | A2A extension |
| Agent-to-user | AG-UI | Agent → human interface | Varies |
Multi-agent systems face a fundamental problem: agents built with different frameworks - LangGraph, CrewAI, ADK, AutoGen - cannot talk to each other. Each framework has its own internal communication protocol, and cross-framework orchestration requires custom adapters, brittle message-format translations, and shared database schemas that do not scale. A2A is the answer to that specific problem. Nothing more and nothing less.
A2A should solve a real boundary problem that exists in the architecture. If there is no genuine boundary - no independent deployment, no separate ownership, no distinct security perimeter - there is probably no need for A2A.
The core data models and protocol bindings are stable. Architects should still expect to engineer application-level workarounds for gaps - per-skill body schemas, token downscoping, registry standardization - but the protocol itself is no longer a moving target.
A2A protocol: common questions
What is the A2A protocol and how does it differ from MCP?
A2A (Agent-to-Agent) is an open standard for communication between independent AI agents - task delegation, capability discovery, and message exchange across framework and organizational boundaries. MCP connects a single agent to external tools and data sources. They address different layers and are designed to be used together: MCP inside each agent, A2A between agents.
Is A2A v1.0 stable enough to build on in 2026?
Yes, with caveats. A2A v1.0 is the current stable release, governed under the Linux Foundation. The core data models and protocol bindings are stable. The gaps to engineer around at the application level are registry standardization, per-skill schema validation, and - most importantly - governance primitives like human escalation and audit replay.
How does an A2A agent card work?
Each A2A-compliant agent publishes a small metadata document (typically JSON) that describes what the agent is, what it can do, how to talk to it, and what authentication it requires.
It lives at /.well-known/agent.json, and may be signed with JWS for cryptographic integrity. A client agent fetches it to decide whether to delegate a task - in theory. In practice, most teams are still using static configuration.
What frameworks have native A2A support?
Native support ships in Google ADK, LangGraph, CrewAI, LlamaIndex, Semantic Kernel, AutoGen, and Microsoft Agent Framework for .NET.
Microsoft integrated A2A into Azure AI Foundry and Copilot Studio; AWS added support via Amazon Bedrock AgentCore Runtime.
What does A2A not cover that teams assume it does?
It does not cover governance. Five critical gaps have been identified: semantic intent verification, recursive delegation accountability, agent identity integrity, governance opacity and enforcement, and operational sustainability
- none of which the current spec resolves. If your multi-agent system needs to answer "which agent authorized this?" or "what happens when two agents disagree?", that logic is yours to write.