A LangGraph agent and a CrewAI agent can now hand off a task to each other without a single line of bespoke integration code. That's what A2A v1.0, released March 12, 2026, finally makes real - and the gap between that claim and what you still have to build yourself is the interesting part.
What A2A v1.0 actually changed
The current production version is v1.0, released March 12, 2026, which formalized cryptographically signed Agent Cards using JWS (RFC 7515) with JCS canonicalization (RFC 8785) for domain verification. That's the headline change, and it matters more than it sounds.
Before v1.0, a receiving agent had no way to verify that a card was actually issued by the domain owner - an attacker could stand up a fake Agent Card and redirect other agents into a card forgery attack. Signed Agent Cards are the trust primitive that makes decentralized discovery viable at all. The rest of v1.0 is equally pragmatic: multi-tenancy support allows a single endpoint to securely host many agents, which is the feature SaaS providers needed before they could offer A2A at all.
By the one-year mark in April 2026, the protocol counted 150+ supporting organizations and production deployments inside Microsoft Azure AI Foundry, Amazon Bedrock AgentCore, and Salesforce Agentforce. The SDK ecosystem expanded from one Python reference implementation to five: an agent built in Python can call a .NET agent and a Go agent in the same task graph without serialization shims.
On the wire, the mechanics are lean.
Any A2A server publishes an AgentCard at /.well-known/agent-card.json declaring its skills, supported MIME types, transport bindings, and security schemes. Agents communicate via JSON-RPC 2.0 using an eight-state Task lifecycle: submitted, working, input_required, auth_required, completed, failed, canceled, and rejected.
Long-running tasks are tracked across connections via SSE streaming and webhook push-notification configurations.
What v1.0 does not fix
Here is where most coverage goes quiet. A June 2026 paper "Governance Gaps in Agent Interoperability Protocols" applied a six-dimension governance taxonomy to A2A v1.0.1 and found that A2A v1.0.1 received Partial support only for membership via Agent Cards and Absent ratings for voting, dissent preservation, human escalation, and audit/replay dimensions.
Work through what "Absent" means in practice:
- Human escalation. There is no protocol mechanism for escalating to human authority. If a sub-agent hits something it should not decide alone, A2A has no native way to pause the task and surface it to a person. That logic has to live in your application.
- Voting and dissent. A2A supports task delegation and message exchange but not structured argumentation with challenge/response semantics. Messages are task-oriented, not deliberative. Multi-agent consensus is entirely out of scope.
- Audit and replay. The protocol has no built-in mechanism to record a tamper-evident log of which agent did what and why. One of the four official extensions - Traceability - addresses this partially, but it is optional and not widely implemented.
There is also a subtler problem with Signed Agent Cards. Sanitize strings from Agent Card fields before they reach an LLM, even after signature verification. Signing only proves the card came from the claimed issuer; it does not tell you the issuer was benign. Prompt injection through a well-signed, malicious Agent Card is a live attack surface.
The most common operational mistake is related: accepting a task before verifying that the calling agent holds the required scopes, then discovering the permission gap only after internal tool execution has begun. The correct pattern is to enforce least-privilege scope at the gateway before task acceptance, mapping OAuth 2.0 scopes to individual skills at the Agent Card level.
How A2A and MCP divide the work
The easiest way to get this wrong is to treat A2A and MCP as alternatives. 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.
| MCP | A2A | |
|---|---|---|
| Direction | Vertical (agent → tool) | Horizontal (agent → agent) |
| Discovery | Manual host config | /.well-known/agent-card.json |
| Task lifecycle | Stateless tool calls | 8-state tracked Task |
| Trust primitive | Transport (HTTPS) | Signed Agent Card (JWS) |
| Human escalation | Not in spec | Not in spec |
| Governance | Linux Foundation (AAIF) | Linux Foundation (AAIF) |
In December 2025, the Linux Foundation formalized consolidation of MCP, A2A, and related infrastructure through the Agentic AI Foundation (AAIF) as a neutral top-level foundation. Both protocols now share governance, which matters for long-term stability - neither is going away.
Beagle in action#eng-ops, 10:42amWhat teams building on A2A need to wire themselves
Teams building production systems should implement human-in-the-loop hooks for sensitive operations at the application layer rather than relying on the protocol to enforce them. That is not a complaint about A2A - it is how transport protocols work. HTTP doesn't enforce rate limits either.
Concretely, the checklist A2A leaves you:
An internal agent registry. Most enterprises end up running an internal registry or developer portal to catalog agent capabilities. The registry only accepts cards signed by trusted issuers, which prevents both shadowing attacks and silent rug-pulls.
Prompt sanitization on every inbound card. The agent card's description and skills fields are processed by language models; treat them as untrusted input. Capability claims should be validated against a trusted registry, not accepted at face value.
A scope gateway before task acceptance. Enforce OAuth 2.0 scopes at the entry point, not inside the task handler.
An audit log. The Traceability extension exists, but you have to implement it. Without it, your agent network has no replay capability for post-incident analysis.
An escalation path. A2A's Task lifecycle has an
input_requiredstate, which is the closest it gets to pausing for human input - but what happens next is entirely up to you.
None of this makes A2A immature. A2A v1.0 is the version that turned the spec into something production-grade. But "production-grade protocol" and "safe multi-agent system" are not the same sentence. The protocol handles the plumbing. The governance is yours.
A2A protocol: common questions
What is the A2A protocol and how does it differ from MCP?
A2A (Agent-to-Agent) is an open protocol for AI agents built on different frameworks to discover each other and exchange structured tasks. MCP connects a single agent to tools and data. A2A connects one agent to another, handling cross-org discovery, task delegation, and lifecycle tracking. Most production systems use both together: A2A to route, MCP to equip.
What did A2A v1.0 add?
V1.0, released March 12, 2026, added cryptographically Signed Agent Cards (JWS/RFC 7515), multi-tenancy support for SaaS deployments, multi-protocol bindings for heterogeneous stacks, and a migration path from pre-1.0 implementations. The core mechanics - Agent Cards, JSON-RPC tasks, SSE streaming - were unchanged.
Are Signed Agent Cards enough to trust an inbound agent?
No. Signing proves the card came from the claimed domain owner. It does not verify the card's fields are safe to pass to an LLM, that the issuing organization is trustworthy, or that the agent has only the permissions it claims. Sanitize all card fields as untrusted input and validate capability claims against your own registry.
Does A2A handle human escalation or audit logging?
Not natively. The June 2026 governance gap analysis found A2A v1.0.1 rates Absent on human escalation and audit/replay. The input_required task state is the closest the protocol gets to pausing for human input. Escalation logic and tamper-evident logging have to be built at the application layer.
Who governs A2A?
The Linux Foundation, via the Agentic AI Foundation (AAIF), which also hosts MCP. Google donated A2A to the Linux Foundation in June 2025. The AAIF was formalized in December 2025 and consolidates both protocols under neutral governance.