What it is for

Once organisations run agents built by different teams and vendors, the interesting work crosses boundaries: a procurement agent needs something from a logistics agent that belongs to another company and another stack.

A2A is an open protocol for exactly that. It was introduced by Google with a large group of partners and has since moved to the Linux Foundation, which matters if you are being asked to bet on it — vendor-neutral governance is the difference between a standard and a product.

The distinction worth holding on to: MCP gives an agent tools. A2A lets an agent delegate to a peer that has its own reasoning, its own tools and its own opacity. A tool returns a result; a peer agent may ask you a clarifying question first.

Discovery: the agent card

An agent publishes a machine-readable description of itself — commonly called an agent card — stating who it is, what skills it offers, where to reach it, and which authentication it expects.

That is what makes discovery possible without a bespoke integration. A client agent can read the card and work out whether this peer can help and how to ask.

Describe skills in outcome terms

The card is read by another agent deciding whether to delegate. Describe what the agent achieves, not which model or framework it runs on.

The same discipline as an MCP tool description: this text is doing selection work, and vagueness produces wrong routing.

Use it when publishing any agent for others to call.
Treat the card as a public interface

Once other agents route on it, changing skill names or semantics breaks callers you may not know about.

Version it, and change it with the same care as a public API contract.

Use it when more than one consumer depends on it.

Tasks, messages and artifacts

The interaction model assumes work that takes time and may need clarification along the way — which is the normal case for agent collaboration, and the main reason a plain request-response API is a poor fit.

Tasks are long-lived and stateful

A task is the unit of delegated work, with a lifecycle rather than a single response. It can be in progress, waiting on input, completed or failed.

Design for the waiting state specifically. An agent that needs a clarification and has nowhere to put the question is an agent that guesses.

Use it when delegated work may exceed a request timeout, which is most of it.
Artifacts are the outputs

Results come back as artifacts — documents, structured data, files — rather than only as text in a conversation.

That separation matters for auditability: the artifact is the deliverable you can store and point at later, distinct from the chatter that produced it.

Use it when the outcome is a thing rather than an answer.
Streaming and notifications for long work

The protocol supports streaming updates while work proceeds, and push notification for tasks that outlive a connection.

Without one of those, the calling agent is left polling, and the user is left watching a spinner with no idea whether anything is happening.

Use it when work runs longer than a few seconds.

A2A and MCP together

They are complementary and the pairing is the intended design. Within one agent, MCP connects it to the databases, APIs and files it needs. Between agents, A2A lets it hand work to a peer.

A useful test: if the thing you are calling has no reasoning of its own and always returns the same shape for the same input, it is a tool — use MCP. If it may plan, ask you something, take minutes, or come back with a document, it is an agent — use A2A.

Security and trust

Delegating to an agent you do not operate is a genuinely different risk posture from calling an API. The peer is non-deterministic, may itself be under injection, and its output feeds your model's context.

Authenticate the peer, and be authenticated

The agent card declares the authentication scheme; use ordinary enterprise mechanisms rather than inventing something because the caller is an agent.

Know which organisation an incoming task came from. Attribution is what lets you rate-limit, bill, and revoke.

Use it when any cross-organisation delegation.
Treat peer output as untrusted

Whatever a peer agent returns lands in your agent's context. If your agent has tools, that is a path from someone else's compromised agent to your systems.

The mitigations are the same as everywhere else in this space: scoped credentials, approval gates on consequential actions, and not relying on a system prompt to hold a security boundary.

Use it when always, and especially with peers outside your organisation.
Bound the delegation

Set explicit limits on what a delegated task may cost, how long it may run, and how many times it may come back for clarification.

Two agents that can each delegate to the other need a loop guard, or you will discover one at the worst possible moment.

Use it when before the first production delegation.

Whether you need it yet

Be honest about the stage. If all your agents are yours, in one codebase, A2A adds a protocol boundary where a function call would do. The value appears when the other agent is genuinely outside your control — another vendor, another business unit with its own stack, another company.

It is worth understanding now, and worth adopting when you actually have a peer to talk to. Designing for it prematurely is the same mistake as building microservices for a single team.

Where to read more