Somewhere in a GitHub discussion from March 2026, a team running an A2A test harness reported passing 11 of 12 security checks. The one failure: they replayed a legitimate /.well-known/agent-card.json from a different runtime, and the remote agent had no signal the caller wasn't who it claimed. That gap - between a correctly signed card and a correctly behaving agent - is the thing worth understanding before you build around A2A.
What A2A v1.0 actually specifies
Where MCP addresses an agent's interaction with its environment - data and tools - the Agent-to-Agent (A2A) protocol targets a different challenge: enabling communication and coordination among the agents themselves.
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).
Google released the A2A protocol on April 9, 2025, and donated it to the Linux Foundation. The spec reached v1.0 under a committee of Google, Microsoft, AWS, Salesforce, IBM, and others.
By August 2025, the competing Agent Communication Protocol (ACP), initiated by IBM Research and later backed by Cisco, merged with A2A under the same umbrella, consolidating what had been three competing standards into one.
The v1.0 specification defines the data model normatively in Protocol Buffers and provides three protocol bindings: JSON-RPC 2.0, gRPC, and HTTP+JSON/REST.
The protocol officially supports five language SDKs: Python, Go, JavaScript, Java, and .NET.
The architecture has three moving parts worth keeping distinct:
Agent Card - any A2A server publishes an AgentCard at
/.well-known/agent-card.jsondeclaring its skills, supported MIME types, transport bindings, and security schemes.Task lifecycle - agents communicate via JSON-RPC 2.0 using an eight-state task lifecycle: submitted, working, input_required, auth_required, completed, failed, canceled, rejected.
Opaque execution - a central design principle is opaque execution: agents collaborate based on declared capabilities and exchanged data, without exposing internal reasoning, memory, or tool implementations to one another.
That last point is a feature and a problem simultaneously.
What signed Agent Cards do - and what they don't
This is the part most write-ups glide past.
The current production version is v1.0, which formalized cryptographically signed Agent Cards using JWS (RFC 7515) with JCS canonicalization (RFC 8785) for domain verification.
The card is signed with a key whose public key is published under the same domain, letting a calling agent verify both the integrity of the metadata and the domain ownership of the server in a single check. That signature path is what made A2A acceptable to enterprises with strict identity controls. Without it, any host could publish an Agent Card claiming any skill set.
So signing solves spoofing. What it does not solve is honesty.
Agent Card signing authenticates identity but does not attest capability: it confirms who published the card, not whether the advertised skills are truthful. The specification provides no skill verification primitive. The AgentSkill object is a self-declared advertisement with no integrity binding to actual capability. The specification introduces no planned mechanism to close this gap, confirming that skill claims remain entirely trust-based in the current protocol design.
There is also a subtler problem at the runtime layer. When Agent A invokes Agent B's capability, B has no way to verify that A is actually authorized by its runtime to make that request.
Nothing in the spec today binds the card to the runtime that is actually issuing the call. In practice, a legitimate card can be replayed from a different runtime entirely, and the callee has no signal that the caller is not who it claims.
The fix the community is converging on - a runtime attestation registry with short-lived Ed25519-signed nonces bound to specific requests - is not in the spec. It's being built on top of it.
The MCP + A2A stack in practice
Production systems routinely combine both: A2A routes a task to the right specialist agent; MCP gives that agent its context and tools. The practical consequence is that you end up managing two trust models simultaneously.
MCP servers are under your direct control - you configured them, you know what tools they expose. A2A remote agents are opaque, autonomous peers whose internal state is hidden by design. A failure in an A2A-delegated subtask is harder to trace than a failure in an MCP tool call, because the remote agent's intermediate steps are invisible by protocol design.
A major difficulty is translating high-level A2A tasks into specific, correct MCP tool commands. An A2A client might ask for a summary, but the remote agent needs to figure out the exact MCP queries and tool parameters. A2A's skill descriptions often lack the detail of MCP's tool requirements, leading to potential errors at the integration point.
For a teammate like Beagle, operating inside Slack or Teams, A2A matters specifically when a workflow involves a remote specialized agent - say, one that owns your CRM data or a regulated data store. The draft-and-approve model still applies at the boundary: Beagle can identify a delegated result, surface what the remote agent returned, and hold for confirmation before acting on it.
Where A2A is right now, honestly
| Dimension | State in v1.0 |
|---|---|
| Transport | Stable: JSON-RPC 2.0, gRPC, HTTP+JSON |
| Discovery | Stable: signed Agent Cards at /.well-known/agent-card.json |
| Task lifecycle | Stable: 8 states, in-task auth flow included |
| Skill truthfulness | Unresolved: self-declared, no verification primitive |
| Runtime-to-card binding | Unresolved: community-built registries, not in spec |
| Prompt injection defense | Not addressed in spec; implementer responsibility |
Six authentication schemes are supported - APIKey, HTTP Basic, HTTP Bearer, OAuth 2.0, OpenID Connect, mTLS - but the protocol advertises them, it does not enforce them; hardening is the implementer's job.
The most common production mistake is authorization creep: 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.
Beagle in action#engineering-ops, 2:43pmThe honest summary: v1.0 is explicitly the release that fixed "v0 was functional but not production-grade." Without Signed Agent Cards, cross-organization integration was not defensible. Without multi-tenancy, SaaS providers had no real path. V1.0 filled in the last pieces needed to actually run A2A in the enterprise. But the skill-honesty and runtime-binding gaps are real, active in the wild, and not scheduled to be closed in the spec - they're being patched externally.
That's worth knowing before you route a sensitive task to an agent whose card you've only glanced at.
A2A Agent Card protocol: common questions
What is an Agent Card in the A2A protocol?
An Agent Card is a signed JSON document served at /.well-known/agent-card.json that describes an agent's skills, supported transports, and authentication requirements. In v1.0, the card is signed using JSON Web Signature so a calling agent can verify domain ownership and metadata integrity before submitting any task.
What is the difference between A2A and MCP?
MCP connects a single agent to tools and data sources - it's the vertical, agent-to-tool layer. A2A connects agents to other agents - it's the horizontal, peer-to-peer delegation layer. Production systems use both: A2A to route a task to the right specialist agent, MCP to give that agent its context and tools.
Does a signed Agent Card guarantee an agent will do what it claims?
No. The signature proves who published the card and that the metadata has not been tampered with. It does not verify that the advertised skills accurately reflect the agent's actual behavior. Skill claims are self-declared and have no cryptographic binding to runtime capability in the current v1.0 spec.
Is A2A v1.0 ready for production?
The transport, discovery, and task lifecycle layers are stable and shipping in Google, AWS, and Microsoft agent infrastructure. The open gaps - runtime-to-card binding, skill attestation, and prompt injection defense - are implementer responsibilities, not spec features. Teams in regulated sectors are adding external attestation registries and OAuth scope enforcement at the gateway.
How does A2A handle long-running tasks?
Long-running tasks are tracked across connections via SSE streaming and webhook push-notification configurations.
The eight-state task lifecycle includes an auth_required state specifically for tasks that need mid-execution human or system authorization - a design choice that signals A2A is built for workflows measured in minutes, not milliseconds.