What Is the A2A Agent2Agent Protocol? Tasks, Agent Cards and MCP Compared

Agent2Agent (A2A) is the missing wire between autonomous agents. Model Context Protocol (MCP) taught clients how to call tools; A2A teaches agents how to hire each other. If you are wiring multi-agent products in 2026, you will likely run both.

Quick answers

Why another protocol appeared

Single-agent loops already strain context windows: system prompts, tool definitions, RAG chunks and skills compete for the same tokens. That pain pushed vendors toward thin prompts and thick artifacts. A2A pushes the same idea across process boundaries: a client agent should not ingest another vendor's entire tool surface — it should send a task and receive an artifact.

Google's April 2025 announcement framed the problem as enterprise silos. A hiring manager's agent might need sourcing, scheduling and background-check agents built on different stacks. Without a shared task model, every integration becomes a bespoke webhook and brittle prompt handoff.

A large cream ring routing three small green parcels outward, illustrating cross-vendor agent delegation

The specification's opaque execution principle matches how coding agents already work internally: you judge output and traces, not chain-of-thought. A2A makes that boundary explicit between organizations.

Data model: tasks, messages and artifacts

The A2A specification organizes content in three layers: canonical data model, abstract operations and protocol bindings. Builders should memorize the data model first.

Agent Card — JSON metadata describing how to talk to a remote agent: endpoint URL, authentication (aligned with OpenAPI-style schemes), declared skills and supported content types. Discovery starts here, much like fetching a well-known URL for MCP, but oriented around capabilities rather than tool lists.

Task — the unit of work. Tasks have a lifecycle (submitted, working, completed, failed, canceled) and can run for minutes or days when humans approve steps. Client and remote agents synchronize through task status, not through shared scratchpads.

Message — conversational turns attached to a task. Messages contain parts, each a typed content chunk (text, file reference, structured form, or negotiated UI affordances).

Artifact — durable output of a finished task: a PDF, a candidate shortlist, a JSON record. Artifacts are what downstream systems store; messages are how agents coordinate while producing them.

The spec's a2a.proto file is normative; JSON and SDK bindings are generated from it. If you are comparing versions, read the release notes on the site — 1.0.0 is the current released version as of this writing.

Try the lab above: walk from Get Agent Card through artifact delivery. Notice that the remote agent's tools never appear on the client side — only declared skills and returned artifacts do.

Operations builders actually implement

Layer 2 in the spec lists abstract operations. Implementations map them to JSON-RPC methods, gRPC RPCs or REST routes (Layer 3). The common JSON-RPC surface includes:

• Send Message and Send Streaming Message — open or continue a task; streaming variants emit SSE updates for long jobs.
• Get Task and List Tasks — poll or audit task state across sessions.
• Cancel Task — cooperative shutdown when a user aborts a workflow.
• Get Agent Card — capability discovery before delegation.

Security is secure by default in the design principles: enterprise auth parity with familiar HTTP schemes, no requirement to leak internal prompts, and support for human-in-the-loop pauses while a task stays working.

If you already built AWS AgentCore registry samples, you have seen similar discovery patterns. A2A standardizes the envelope so the registry entry and the wire protocol match across clouds.

A2A vs MCP: a practical split

Confusion here is expensive because both acronyms appear in the same keynote slides. Use this decision table before you design gateways:

MCP answers: "What can this model invoke right now?" A2A answers: "Which external agent owns this subprocess, and how do I get a finished deliverable back?"

In a Claude Code or Codex session, MCP carries filesystem and ticket tools. In an enterprise procurement flow, A2A might delegate supplier negotiation to a partner's agent while your agent keeps the user-facing thread.

Two connector plugs meeting along an arc, illustrating how Agent2Agent protocol complements MCP tool wiring

Neither replaces HTTPS APIs to deterministic microservices. If the remote side is a fixed JSON schema and no LLM planning, keep a normal REST client. Reach for A2A when the remote party is itself an agent that must plan, ask clarifying questions and stream partial artifacts.

How A2A sits in the 2026 agent stack

Three Linux Foundation projects now bracket the stack:

1. MCP — tool and context plumbing.
2. Agent Skills — packaged instructions agents load on demand (Anthropic donation).
3. A2A — cross-vendor delegation.

Add Open Responses if you standardize model HTTP surfaces, and OpenSandbox when agents need isolated runtimes. A2A is the collaboration layer above those primitives.

Three cream grippers placing different green shapes into one shallow tray, showing MCP, skills and A2A on one agent stack

For security architecture, pair A2A auth with the patterns in Okta cross-app access for AgentCore: treat each remote agent as its own OAuth resource server, log task IDs, and never forward end-user tokens blindly (connector routing lessons).

What people are asking

"Is A2A only Google?" Google announced it, but the spec is open source and AAIF-hosted. Partners listed in the launch post span Salesforce, SAP, MongoDB, LangChain and many SIs. Judge implementations by Agent Card quality and auth, not logo count.

"Do I need gRPC?" The spec defines bindings for JSON-RPC, gRPC and REST. Most integrators start with JSON-RPC over HTTPS plus SSE, because that matches existing API gateways and observability stacks.

"How is this different from agent relay products?" Relay tools focus on session handoff between coding agents in one org. A2A targets opaque remote agents across vendors with formal task state — closer to enterprise B2B than to terminal multiplexing.

"Will A2A fix multi-agent chaos?" It standardizes the envelope, not the planning algorithm. You still need evals, sandboxes and cost controls. A2A reduces integration surface area; it does not guarantee correct delegation.

JSON-RPC binding shape (sketch)

You do not need to memorize every field to read partner docs. A minimal mental model for JSON-RPC binding:

1. Client calls Get Agent Card on the well-known path the card advertises.
2. Client calls Send Message with a new task ID, user goal text in a Part, and authentication headers the card requires.
3. Remote returns task state submitted or working; client opens an SSE channel if the card lists streaming support.
4. Remote sends Messages with progress parts; client surfaces them to the user without interpreting hidden tool traces.
5. On completed, client downloads Artifacts by reference (file URL, structured JSON, or embedded form payload).

The specification overview names the protobuf messages that back each step. SDK generators map those to typed clients in your language. If you maintain an internal gateway, treat Agent Cards like OpenAPI documents: version them, lint them in CI, and reject cards that omit auth schemes.

This is deliberately boring HTTP. That is the point. Enterprise buyers already operate API gateways, WAF rules and SIEM parsers on JSON. A2A rides those rails instead of inventing a binary-only wire protocol.

Governance and versioning

The A2A specification site lists 1.0.0 as the latest released version and documents how renames work: new proto fields appear alongside deprecated aliases until the next major bump. If you generate clients from a2a.proto, pin the spec version in your repo and regenerate on upgrades rather than hand-editing JSON schemas.

For procurement, ask vendors three questions:

• Where is the Agent Card URL, and how often does it change?
• Which bindings do you ship in production (JSON-RPC, gRPC, REST)?
• How do you map task failure to compensating actions (refunds, ticket reopen, human queue)?

Those answers matter as much as model benchmarks. A2A is integration glue; outages look like stuck tasks, not wrong tokens.

Implementation checklist

1. Publish an Agent Card at a stable URL with accurate auth and skill descriptions.
2. Map one real workflow to a task lifecycle (include failure and cancel paths).
3. Stream status for anything over ~30 seconds; users abandon silent long tasks.
4. Keep MCP for tools on each agent; do not stuff another agent's tools into your prompt.
5. Log task and artifact IDs in your observability backend alongside model traces (NeMo Compass eval patterns).
6. Test modality negotiation when outputs include files or embedded UI parts.

Limitations and honest gaps

• Ecosystem maturity — spec 1.0.0 is real, but not every SaaS agent exposes an Agent Card yet. Plan feature flags.
• Duplication risk — teams may wrap A2A while still maintaining legacy webhooks until partners catch up.
• Evaluation — cross-agent tasks need integration tests, not only unit tests on tools. Borrow patterns from coding agent evals on real repos.
• Cost — delegation adds hops. Cache stable subtasks and prefer MCP for single-agent tool bursts.

Related reading

• What is MCP? Model Context Protocol guide
• AWS Agent Registry: MCP and A2A discovery sample
• AAIF: ten projects including A2A
• Agent harness complete guide
• Tool definition schema design
• Okta cross-app access and AgentCore
• What are Agent Skills?

Article accurate as of November 9, 2026. Check a2a-protocol.org for spec updates and binding changes.