Google's Agent2Agent (A2A) Protocol, Explained: How AI Agents Talk to Each Other

The gap A2A was built to close

By 2025, most companies shipping AI agents had solved the "agent talks to its own tools" problem — usually with Model Context Protocol (MCP), which gives one agent a standard way to call tools and pull context from data sources. What nobody had standardized was the next layer up: what happens when Agent A, built by one team on LangGraph, needs to hand off a task to Agent B, built by a different team on AutoGen or a completely custom stack? Without a shared contract, every pair of agents needs custom glue code, and that glue breaks the moment either side changes its internal implementation.

Google's Agent2Agent (A2A) protocol, released as an open standard and later contributed to the Linux Foundation, targets exactly that gap. It defines how independent, opaque agents advertise what they can do, how a client agent requests work from them, and how results come back — without either side needing to know anything about the other's internal framework, prompts, or model.

The core idea: agents as black boxes with a discoverable interface

A2A is deliberately opinionated about one thing: it does not try to standardize how an agent thinks. Your planning logic, your model choice, your internal tool use — all of that stays private to the agent. What A2A standardizes is the boundary: a JSON-RPC-style HTTP interface that any agent can implement so that other agents can discover its capabilities and hand it tasks, the same way REST gave web services a common boundary without dictating their internal architecture.

That design choice matters for interviews and for real systems: it means A2A composes with whatever orchestration framework you already use internally. A LangGraph-based supervisor agent can delegate a subtask to a remote agent built on a completely different stack, as long as that remote agent exposes an A2A-compliant endpoint.

Agent Cards: how discovery works

Every A2A-compliant agent publishes an "Agent Card" — a JSON document, conventionally served at a well-known URL, describing what the agent can do, what input/output formats it supports, and how to authenticate to it. A client agent fetches this card before sending any work, the same way a browser fetches a robots.txt or a service fetches OpenAPI metadata before calling an unfamiliar API.

{
  "name": "resume-review-agent",
  "description": "Reviews resumes against a target role and returns structured feedback",
  "url": "https://agents.example.com/resume-review",
  "version": "1.2.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false
  },
  "skills": [
    {
      "id": "review-resume",
      "description": "Scores a resume against a job title and returns strengths, gaps, and rewrite suggestions",
      "inputModes": ["text", "file"],
      "outputModes": ["text"]
    }
  ],
  "authentication": {
    "schemes": ["bearer"]
  }
}

Tasks and Messages: how the actual work happens

Once a client agent knows what a remote agent can do, it sends a Task — a unit of work identified by a task ID, containing one or more Messages (the actual request content, which can include text, files, or structured data). The remote agent works the task and reports status transitions: submitted, working, input-required (if it needs clarification back from the client, which is where multi-turn exchanges come in), completed, or failed.

Results come back as Artifacts — the output the task produced, which can itself contain multiple parts (text, a file, structured JSON) — and for long-running work, A2A supports streaming updates over Server-Sent Events so the client is not stuck polling blind. This task/message/artifact split is the part most engineers coming from single-agent frameworks find unfamiliar: you are not calling a function and getting a return value, you are managing the lifecycle of a task that might take seconds or minutes and might need a follow-up message mid-flight.

A2A vs. MCP: they solve different problems

The most common confusion is treating A2A and MCP as competitors. They are not — they sit at different layers and are commonly used together. MCP is agent-to-tool: it gives one agent a standard way to call a function, query a database, or read a file through a context server it controls. A2A is agent-to-agent: it gives one autonomous agent a standard way to delegate work to another autonomous agent it does not control and cannot see inside of.

A useful mental model: if your system has one agent calling a calculator, a search API, and a code sandbox, that is MCP's job. If your system has a triage agent handing a subtask to a specialist agent built by a different team — or a different company — that is A2A's job. Production multi-agent systems increasingly use both: MCP inside each agent for its own tools, A2A between agents for delegation.

Why this is starting to show up in interviews

Multi-agent system design questions used to stop at "how do your agents coordinate," with the implicit assumption that every agent shares one framework and one codebase. As real production systems increasingly stitch together agents from different vendors and teams, interviewers have started adding a follow-up: "what happens when the agents you are coordinating were not built by you?" That is an A2A-shaped question even when the interviewer does not name the protocol — the answer they are listening for is capability discovery, a stable task/message contract, and treating the remote agent as untrusted input, not a shared-memory subroutine.

Our multi-agent orchestration system design lab covers the coordination side of this in depth — planning, task decomposition, and failure isolation across agents. A2A is the piece that extends those same ideas across a trust and framework boundary, which is worth naming explicitly if an interviewer pushes on cross-team or cross-vendor agent systems.