What is A2A?
A shared language for agents.

A2A is a communication protocol, not an agent builder.

Agent2Agent (A2A) is an open protocol for communication between independent AI agent systems. They may use different models, languages, frameworks, or vendors. A2A gives them a common way to describe what they can do, exchange requests, and return work.

The protocol does not require an agent to disclose its internal reasoning, private memory, or implementation. A client can ask a remote agent to perform a task and communicate through the agreed interface. The remote system decides how it carries out the work behind that boundary.

A2A describes the communication boundary. It does not decide whether delegation is appropriate, whether an agent is reliable, or whether a returned result is correct.

One connects agents to agents. The other connects an agent to tools.

A2A and MCP address different parts of an agentic system. An orchestrating agent might use A2A to ask a specialist agent for work; that specialist could use MCP to reach its own databases, APIs, or tools.

For example, a planning agent could ask a supplier agent to return a structured delivery estimate. The supplier agent might then consult its own inventory service through MCP. A2A handles the request between agents; MCP may handle the connection between one agent and a tool.

Neither protocol replaces the application’s orchestration and permissions. Read the guide to MCP and tool connections ↗ for the other side of this architecture.

An Agent Card describes an endpoint; it does not certify it.

An A2A Agent Card is a machine-readable description of an agent. It can list the agent’s name and skills, supported input and output types, available protocol interfaces, optional capabilities, and declared authentication schemes. In version 1.0, the well-known public card location is /.well-known/agent-card.json; deployments may also use other discovery mechanisms.

The card helps a client decide whether an interface looks compatible. It is not proof that the operator is trustworthy, that a skill description is accurate, or that the agent will complete a task well. A card can be signed, and clients can verify a signature when one is supplied. Sensitive cards can require authentication; credentials belong in the authentication flow, not in a public card.

Check that the endpoint, protocol version, authentication method, data scope, and task type match what your application is prepared to send. Do not rely on an advertised optional capability until both sides confirm they support it.

A task can finish quickly or continue in the background.

A client sends a message with a request. If the answer is immediate, the remote agent can reply with a message. If the work needs more time, it can return a task that the client can follow as it progresses. The agent may also ask for clarification or further input during the exchange.

Clients can receive updates through polling or streaming. Push notifications are another option when the server advertises and supports them. These are delivery choices rather than guarantees that every A2A implementation exposes every feature.

For the calling application, the important part is making progress observable: retain task identifiers, show meaningful status, handle timeouts and errors, and give people a way to stop work that no longer serves the request.

Delegate a result, not unrestricted control.

Imagine a logistics application that needs a delivery estimate. Its coordinator asks a supplier agent for an estimate by a specific date and requests a structured response with the price, available window, and assumptions. The supplier agent can do its own work and return a result without giving the coordinator access to its private systems.

The calling application still owns the user experience and the decision about what happens next. It can compare the returned estimate, show its source and status, ask a person to approve a purchase, or reject a result that does not meet the requested format. Delegation moves a task across a boundary; it does not transfer authority over the caller’s application.

This separation is useful when a partner system has information or capabilities the caller does not own. It also makes failures easier to locate: request, transport, remote execution, returned artifact, and the application’s final decision are distinct steps.

Every remote agent becomes part of your trust boundary.

A shared protocol standardizes how systems communicate; it does not create trust between them. The A2A specification relies on standard authentication and authorization practices. Each deployment must define who can call it, what data a task may access, and which results or side effects are allowed.

Treat remote text, files, and structured results as untrusted input. An artifact may be useful evidence, but it can still be wrong or contain instructions intended to influence the next step. Keep returned content separate from trusted system policy and define what evidence would count as success.

For the broader risks of instructions hidden in data, read the guide to prompt injection ↗. For permissions around the tools an agent can call, see permissions at the tool boundary ↗.

Four distinctions worth keeping.