A2A Protocol: How AI Agents Delegate Work Without a Human

Picture two agents inside the same company. One handles shipping. One handles inventory. The shipping agent needs to know whether 400 units of a part are actually on a shelf before it promises a delivery date. Today, in most deployments, it can’t ask. The two were built by different teams, on different frameworks, and they have no shared language. So a human stitches them together with a brittle integration, or the work just doesn’t happen.

Image Generated by AI

The A2A protocol exists to remove that human. Agent2Agent is an open standard, first announced by Google in April 2025 and contributed to the Linux Foundation in June 2025, that defines how independent agents discover each other, hand off work, and report results, without either side exposing its internal memory, tools, or model.

This is a deep-dive into the mechanics: what actually goes over the wire when one agent delegates to another.

What A2A is solving and what it deliberately isn’t

The hard part of multi-agent systems isn’t sending a message. Any two services can POST JSON at each other. The hard part is doing it without prior coordination: agent A has never met agent B, doesn’t know what B can do, can’t see inside B, and shouldn’t have to.

A2A constrains the problem into three primitives. An agent advertises itself with an Agent Card. Work is wrapped in a Task with a defined lifecycle. Everything travels over ordinary web transport. That’s the whole trick of interoperability, which comes from agreeing on the shape of the interaction, not from inventing new networking.

Image generated by AI

One design choice matters more than the rest. Agents are treated as opaque. A2A never assumes you can read the other agent’s prompts, weights, or tool list. You see its declared capabilities and the artifacts it returns. Nothing else. That opacity is what lets a LangGraph agent and a CrewAI agent talk without either codebase knowing the other exists.

Discovery: the Agent Card

Before two agents can work together, the client agent has to know the other one is there and what it does. A2A handles this with a JSON document called an Agent Card.

The card is a self-description. It lists the agent’s name and provider, the endpoint URL, which protocol bindings and transports it speaks, the security schemes it requires, and most usefully its skills which are discrete capabilities the agent will perform, each with an ID, description, and example inputs.

Image Generated by AI

A client reads this card, decides that a particular skill fits its need, confirms it can satisfy the security scheme, and only then sends work. Discovery isn't a magic service-mesh resolution. It's a document you fetch and parse.

The unit of work: a Task and its lifecycle

Once the client picks a skill, it doesn’t fire a request and hope. It opens a Task. A Task is a stateful object with a unique ID, and its whole point is that agent work is often slow, multi-step, and occasionally needs to come back and ask a question.

A Task moves through a defined set of states. Inside a Task, the two agents exchange Messages. Each message carries a role (user or agent) and one or more Parts. Parts are where A2A earns its keep, because they're typed. A Part can be plain text, a file, or structured data. So an agent can return a JSON object as a first-class result, not as text you have to scrape. The finished outputs of a Task are returned as Artifacts, which are themselves built from Parts.

Image Generated by AI

Multi-turn work is held together by a context identifier that groups related Tasks, so a follow-up question lands in the same conversation rather than starting cold.

Transport: three bindings, one model

A2A separates what agents do from how it travels. The abstract operations such as sending a message, getting a task, cancelling a task, subscribing to updates, etc, are defined once, then mapped onto concrete protocol bindings.

The core methods are small and predictable. An agent declares which bindings it supports in its Agent Card, and the client picks one. Because the operations are functionally equivalent across bindings, a gRPC client and a REST client can talk to the same logical agent.

Image Generated by AI

Two patterns handle the reality that agent work takes time:

Streaming: The server pushes incremental updates over Server-Sent Events. Status changes and partial artifacts arrive as they happen, so a long task isn't a black box until it finishes.

Push notifications: For work that runs for minutes or hours, holding a connection open is wasteful. A2A lets the client register a webhook, and the remote agent calls back when the task state changes. This is the pattern for genuinely asynchronous delegation, and it’s where you’ll want to think hardest about authenticating the callback so a third party can’t spoof a “task completed” event.

Security, and where A2A hands off to MCP

Because A2A assumes agents cross organisational boundaries, security is part of the protocol rather than an afterthought. The Agent Card declares its required scheme, and the spec supports common ones such as API keys, HTTP auth, OAuth 2.0, OpenID Connect, and mutual TLS. Authentication generally happens out-of-band, the same way it does for any web API. The client obtains credentials, then presents them on each call.

It’s worth being clear about the boundary of what A2A covers, because this is where people conflate it with the Model Context Protocol. A2A is horizontal, agent to agent. MCP is vertical, an agent to its tools and data sources. They’re complementary, not competing. An agent might use MCP internally to reach a database, then expose itself over A2A so other agents can delegate to it.

Conclusion

A2A’s strongest feature is how unremarkable it is under the hood. There’s no new transport, no proprietary handshake, just HTTP, JSON, and a disciplined interaction model built around discovery, tasks, and typed messages. That restraint is deliberate, and it’s why adoption spread quickly across major vendors.

If you’re evaluating it, start small. Stand up one agent as an A2A server, publish its Agent Card, and call it from a second agent to feel how multi-turn delegation behaves. You'll learn more from one working handoff than from any spec summary, including this one.