Minimum Code

Home

Glossary

A2A Protocol

7 min read

Content

What Is A2A Protocol?

The A2A protocol, short for Agent2Agent, is an open standard for communication between AI agents built by different teams on different frameworks. It lets one agent discover another's capabilities, delegate a task to it, and track that task to completion, without either side exposing its internal prompts, models, or tools.

Key Takeaways

A2A standardizes agent-to-agent delegation the way Model Context Protocol standardizes agent-to-tool access. The two are complementary, and most serious agent stacks in 2026 use both.
Discovery runs on Agent Cards, machine-readable descriptions of what an agent can do and how to reach it, published at a well-known URL.
The unit of work is a task with a lifecycle. Tasks can be long-running, stream progress updates, and end in completed, failed, or canceled states.
Google launched A2A on April 9, 2025 with more than 50 technology partners, including Atlassian, Salesforce, SAP, ServiceNow, and PayPal [1], then donated it to the Linux Foundation, which put its governance on vendor-neutral ground.
Agents stay opaque to each other. Collaboration happens through messages and artifacts, never by sharing internal state, which keeps organizational boundaries intact.

How It Works

A2A is built on familiar web plumbing: JSON-RPC over HTTP, with server-sent events for streaming and push notifications for very long jobs. Interaction starts with discovery. An agent that wants help fetches another agent's Agent Card, a JSON document describing its skills, endpoint, supported content types, and authentication requirements. Cards are typically served from a well-known path on the agent's domain, so finding a partner agent works much like finding a site's robots.txt.

Once a client agent picks a remote agent, it opens a task. The remote agent accepts and works it through a defined lifecycle, emitting status updates along the way. A task can also pause in an input-required state, letting the remote agent ask a clarifying question mid-flight. Results come back as artifacts, which can be text, structured data, or files. Because everything rides on HTTP with standard enterprise authentication, existing infrastructure for routing, monitoring, and access control applies without modification. Tooling support has kept pace: the Linux Foundation reported in April 2026 that the core A2A repository passed 22,000 GitHub stars in its first year while the SDK ecosystem expanded from a single Python implementation to five production-ready languages [2].

The design principle that separates A2A from a shared multi-agent framework is opacity. The client agent never sees how the remote agent works, only what it delivers. That is what makes cross-vendor and cross-company collaboration plausible: a procurement agent at one company can hand a task to a supplier's fulfillment agent while both keep their internals, and their security posture, to themselves.

Example

An enterprise runs an HR onboarding agent in one framework and an IT provisioning agent, built by a different team, in another. On a new hire, the HR agent discovers the IT agent through its Agent Card, opens a task to provision laptop, accounts, and access groups, and attaches the role profile as structured data. The IT agent streams progress as each system completes, pauses once in input-required to confirm an unusual access request, then returns an artifact summarizing everything provisioned. Neither team rewrote their agent to match the other's stack; the protocol was the contract between them.

What People Get Wrong

The frequent misreading is that A2A and MCP are competing standards and a team must pick one. They operate at different layers. MCP connects an agent to tools and data, things without agency that respond to calls. A2A connects an agent to other agents, peers that reason, hold their own context, and may take minutes or days to finish. In a mature architecture the same agent speaks both: MCP downward to its tools, A2A sideways to its peers.

FAQ

Who created the Agent2Agent protocol? Google announced it in April 2025 with support from more than fifty technology and consulting partners, and later contributed it to the Linux Foundation so no single vendor controls the specification. By the protocol's first anniversary in April 2026, the Linux Foundation counted more than 150 supporting organizations, up from the 50-plus at launch [3].

When should I use A2A instead of just building one bigger agent? Reach for A2A at organizational boundaries: different teams, different vendors, different companies. Inside a single codebase owned by one team, direct orchestration or subagents are simpler. The protocol earns its overhead when the collaborating agents cannot or should not share internals.

Does A2A handle security between agents? It builds on standard web authentication and authorization, and Agent Cards declare each agent's requirements. What it cannot do is make a remote agent trustworthy. Delegating a task means trusting another system's output, so treat received artifacts as untrusted input and validate them like any external data.