ModelRefs / Agent-to-Agent Protocol (A2A) — AI Glossary

Agent-to-Agent Protocol (A2A) — AI Glossary

Google's open protocol for structured communication between AI agents, defining capability discovery, task delegation, and result exchange.

Overview

Google's Agent2Agent (A2A) protocol (2025) defines how agents advertise capabilities via Agent Cards, create tasks, exchange messages, and stream results using JSON-RPC over HTTP. Designed for enterprise multi-agent systems where agents from different vendors need to interoperate without shared infrastructure.

Reference details

Topicagents
Also known asA2A, agent-to-agent
Last reviewed2026-06-24

How it works

  1. An agent publishes an Agent Card at a well-known address describing its identity, skills, supported interaction modes and authentication requirements. Discovery is therefore fetching a document rather than relying on shared configuration.
  2. A client agent creates a task on a remote agent, and the task — not the message — is the unit of work: it carries an id, a lifecycle state and accumulated artifacts, so progress survives a dropped connection.
  3. Messages exchange content within a task, structured as parts so that text, files and structured data travel in one envelope rather than being flattened into a string.
  4. Transport is JSON-RPC over HTTP, with streaming for incremental updates and a push mechanism for long-running tasks that outlive the client's connection.
  5. Tasks have explicit states including one for requiring input, which is what lets a remote agent pause and ask a clarifying question rather than guessing or failing.
  6. Authentication and authorisation are per-agent and declared in the card, since the point of the design is agents from different organisations interoperating without shared infrastructure.

Example: What the task abstraction buys over a request-response call

A remote agent takes 8 minutes on a research task. As a plain HTTP request that is a connection held open for 480 seconds, against typical gateway and load-balancer idle timeouts of 60 seconds: the call fails roughly 480 / 60 = 8 timeout windows before it would have finished, and a client that retries restarts the work, so three attempts cost 3 x 8 = 24 minutes of compute and still return nothing. As a task, the client creates it, receives an id, and the connection can drop freely — state lives on the server, progress arrives by streaming or push, and reconnecting means querying the id rather than restarting. The retry cost falls from the whole task to one status call. The second thing the abstraction buys is the input-required state: if the agent needs a clarification at minute three, a request-response call must either guess or fail, while a task pauses and the client supplies the answer against the same id. Both properties come from the work having an identity independent of the connection that started it.

Commonly confused with

A2A and MCP solve adjacent problems and are not alternatives. MCP connects a model to tools, data and prompts — the resources an agent uses. A2A connects an agent to other agents — peers that run their own loops, hold their own context and may belong to another organisation. The practical difference is autonomy: a tool returns a value and has no state of its own, while a peer agent can refuse, ask for clarification, or take eight minutes. A system typically needs both, and choosing between them is usually a sign the question was really about whether the remote thing reasons.

When to use it

Reach for it when:

  • Agents from different vendors or organisations that must interoperate without shared infrastructure or coordinated deployment.
  • Long-running remote work, where the task abstraction makes progress survive connection loss.
  • Capability discovery at runtime, where the set of available agents is not known when the client is written.
  • Interactions that may need clarification mid-task, which the input-required state supports directly.

Reach for something else when:

  • Subagents inside one application, where an in-process call is simpler and the protocol adds a network boundary for nothing.
  • Connecting a model to tools and data, which is MCP's problem rather than this one.
  • Short deterministic operations, where request-response is adequate and the task lifecycle is overhead.
  • As a trust boundary on its own. The protocol carries authentication declarations; it does not make a remote agent's output safe to act on.

Continue your research

Use these connected ModelRefs sections to compare alternatives, inspect implementation paths, and review the evidence and governance boundaries relevant to Agent-to-Agent Protocol (A2A) — AI Glossary.

Frequently asked questions

What is Agent-to-Agent Protocol (A2A)?

Google's open protocol for structured communication between AI agents, defining capability discovery, task delegation, and result exchange.

Is Agent-to-Agent Protocol (A2A) the same as A2A?

Yes — A2A, agent-to-agent are common aliases for Agent-to-Agent Protocol (A2A).

What concepts are related to Agent-to-Agent Protocol (A2A)?

Closely related concepts include agent protocol, mcp, agent.