Google announced the Agent-to-Agent (A2A) protocol in April 2025 with 50+ launch partners, and by its one-year mark the protocol counted 150+ supporting organizations and production deployments inside Microsoft Azure AI Foundry, Amazon Bedrock AgentCore, and Salesforce Agentforce. That is fast adoption by any standard. But "production-ready" and "governance-ready" are different claims, and a June 2026 gap analysis from arXiv found that five dimensions out of six in a standard governance taxonomy are either absent or only partially addressed in the current spec. The question worth asking before you build on A2A is: what problem does it actually solve, and what does it leave to you?
What A2A v1.0 actually changed from v0.x
v1.0 is not just a version bump. It landed four things that matter for production deployments: signed agent identity, proper OAuth flows for headless agents, multi-tenancy, and paginated task listing. None of these appeared in v0.x.
The core mechanism is deliberately simple. An agent publishes a signed Agent Card describing what it can do, a calling agent posts a JSON-RPC task to the endpoint, the task progresses through a defined lifecycle, and the result returns either synchronously or via SSE streaming for long-running work. Agents communicate via JSON-RPC 2.0 using an eight-state task lifecycle: submitted, working, input_required, auth_required, completed, failed, canceled, rejected.
The v1.0 identity story is the biggest change. The current production version formalized cryptographically signed Agent Cards using JWS (RFC 7515) with JCS canonicalization (RFC 8785) for domain verification. That means a calling agent can verify a card's authenticity before trusting its declared capabilities or endpoints - a necessary step for any cross-organizational agent call.
A2A v1.0 aligns with core architectural principles of the web: stateless, layered architecture, standard protocol bindings, and infrastructure-friendly communication patterns. That alignment matters operationally because organizations can scale agent interactions with the same proven load balancing, gateway, security, and observability patterns they already use for web systems.
One non-obvious detail for anyone implementing today: the A2A protocol spec is at v1.0.0, but the a2a-sdk package on PyPI is at v0.3.25 stable, with a v1.0.0a0 alpha. This is not a warning sign - it is normal for a protocol-first project. The spec stabilizes first; the SDK catches up. If you need signed cards or multi-tenancy today, call the HTTP API directly.
A2A vs MCP: the right mental model
These two protocols get conflated constantly. They solve different things and are meant to be used together.
The A2A/MCP distinction is crisp: MCP is the "USB-C for tool connectivity" (vertical, agent → tool), while A2A is "HTTP for agent collaboration" (horizontal, agent → agent). Production systems routinely combine both: A2A routes a task to the right specialist agent; MCP gives that agent its context and tools.
| Dimension | MCP | A2A |
|---|---|---|
| Direction | Agent → Tool | Agent → Agent |
| Primary primitive | Tool call | Task delegation |
| Discovery | Manual host config | Agent Card at /.well-known/agent-card.json |
| Transport | Stateful (stdio/SSE) | JSON-RPC 2.0 over HTTPS, gRPC |
| Identity | None in base spec | Signed Agent Cards (v1.0) |
| Governance | Out of scope | Out of scope |
A2A fills a critical gap in the agentic AI landscape: while frameworks like LangGraph, CrewAI, and AutoGen excel at building agents internally, there was no standard for agents built on different stacks to talk to each other. That framing is accurate and useful. The gap it fills is real. The question is what it does not fill.
Beagle in action#ops-agents, 11:02amThe governance gap the spec does not close
This is the part most coverage skips. Agent interoperability protocols 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 paper (arXiv 2606.31498) applied a six-dimension taxonomy to A2A v1.0.1, MCP, ACP, ANP, and ERC-8004. The resulting gap matrix reveals that voting and dissent preservation are universally absent across all five protocols, deliberation is absent or at most partial. In plain terms: the protocols can route a task to the right agent, but they cannot express what happens when two agents disagree, who has the authority to override, or whether a human was supposed to be in the loop.
The gap is not protocol-specific - it reflects a shared design philosophy that treats agents as task workers rather than community members. Audit depends on implementation. That last sentence is the one to underline. There is no audit primitive in A2A. An API gateway can tell you "a request came from IP 10.0.3.47 and was routed to service X." It cannot tell you "Agent A (owned by the finance team, risk-level=medium) called Agent B (owned by the compliance team, capability=audit-query) and this was permitted by policy P-2847." That is the level of detail your compliance team needs. An API gateway will never give it to them.
There is also a specific security finding worth knowing. Agent card signing is optional rather than mandatory in the base profile, enabling impersonation attacks. Authorization is implementation-defined. And at the delegation layer: intermediary agents receive forwarded credentials with no protocol-level restriction on misuse; a compromised agent can retain and replay credentials beyond the intended delegation scope. An adversary controlling any intermediate agent can silently harvest credentials across repeated delegation chains.
None of this means A2A is broken. It means the protocol does what it says and no more. These protocols are necessary but not sufficient. They are the plumbing, not the governance.
What to actually do if you are building on A2A today
The protocol is stable enough to build on. The governance layer is yours to design. Here is what that means practically:
Enforce signed Agent Cards. The spec makes them optional. Make them mandatory in your deployment before you go cross-org. Authentication is declared in the Agent Card under the
securitySchemesfield, which makes security requirements discoverable before any task is submitted.Design your authorization layer explicitly. The A2A protocol supports strong authentication schemes but mandates none of them and defines no authorization framework. Authorization logic determining which agents can access which skills is the responsibility of each implementation.
Build an audit trail that spans the delegation chain. A2A task IDs give you a correlation handle; you need to attach those IDs to your own event log at every hop, not just at the edges.
Combine A2A with MCP, not instead of it. Teams building production multi-agent systems typically have a supervisor orchestrating specialist agents via A2A while each specialist accesses its own tools via MCP. Typical production stacks in 2026 combine both protocols for exactly this pattern.
Watch the SDK gap. a2a-sdk v0.3.25 works fine for quickstart-level patterns - agent discovery, task delegation, message exchange. Those APIs have not changed. v1.0.0a0 alpha is available if you want the full SDK surface for signed cards and multi-tenancy.
A teammate like Beagle, living inside Slack or Teams, sits at the human escalation layer that A2A cannot itself define - the point where an agent handoff surfaces to a person for review rather than routing silently to the next agent in the chain.
A2A agent-to-agent protocol: common questions
What does A2A v1.0 actually add over v0.x?
The v1.0 release introduces several capabilities for production environments: heterogeneous environment support through multi-protocol bindings and version negotiation so enterprises are not tied to a single vendor or platform; multi-tenancy support allowing a single endpoint to securely host many agents; and Signed Agent Cards providing cryptographic verification of agent identity across organizational boundaries.
How is A2A different from MCP?
MCP connects a single agent to tools and data - it is vertical (agent → tool). A2A connects agents to other agents - it is horizontal (agent → agent). The goal of A2A is to allow AI agents, built on different frameworks and by different vendors, to communicate securely, exchange information, and coordinate their actions. A2A is designed as a complement to MCP, not a replacement. If MCP is the "wrench" for tool access, then A2A is the "mechanics' dialogue."
Is A2A safe to use in production?
The protocol itself is stable. The risk is in what it delegates to you. Security gaps in the base profile are real: A2A v1.0 provides no specific controls against prompt injection because the protocol handles message delivery without inspecting or validating agent actions. Enforcing signed cards, defining authorization scope, and logging the delegation chain are your responsibility, not the protocol's.
Who governs A2A now?
The Agent2Agent protocol has officially been accepted as a Growth Stage project at the Agentic AI Foundation (AAIF). It provides an open standard for how autonomous AI agents discover each other, delegate tasks, and collaborate across distinct frameworks and vendor boundaries. Governance moved off Google in two phases after the April 2025 launch.
What is an Agent Card in A2A?
Agent Cards serve as a discovery mechanism through which each agent publishes a machine-readable description of its capabilities, input and output modalities, and authentication requirements, analogous to a service descriptor in microservice architectures. In v1.0, these cards can be cryptographically signed so that calling agents can verify the card before trusting its declared endpoints.