Shaam

Posted on Sep 18 Originally published at aitecharchive.com

A2A Protocol Explained: How to Make AI Agents Talk to Each Other (2026 Guide)

#a2aprotocol #multiagentsystems #aiagents #mcp

Running one capable AI agent is easy. The hard part shows up when you have two or three and you are the one shuttling their outputs between tabs. The A2A (Agent2Agent) protocol is the open standard that fixes that: it defines how agents from different vendors discover each other, authenticate, and hand off tasks, so the agents do the handoffs instead of you. Google announced A2A in April 2025, donated it to the Linux Foundation in June 2025, and more than 150 organizations now back it. This guide explains what A2A actually does, how it complements MCP rather than replacing it, and the practical architecture of a multi-agent system built around shared memory and agent-to-agent handoffs.

Last verified: 2026-08-25

A2A = agents talking to agents; MCP = agents talking to tools. You need both.

A2A was launched by Google in April 2025 and moved to the Linux Foundation in June 2025 with over 100 backing companies; adoption has since passed 150 organizations.

The two design decisions that make multi-agent setups actually work: one shared memory every agent reads and writes, and a central task log so a human can audit every handoff.

Start with two agents and one workflow before you scale up. Most failures come from skipping the shared memory layer, not from the protocol.

What is the A2A protocol, in plain terms?

A2A is an open interoperability protocol for AI agents: a standard way for an agent to discover another agent's capabilities, open a session, and coordinate on a task, even if the two agents were built with different frameworks or by different vendors (Google Developers Blog, April 2025).

A concrete example. Say a research agent on your machine has finished a report and you want your coding agent to act on it. Without a standard, you either copy and paste the output yourself, or you build a custom integration between those two specific products. With A2A, Agent A describes what it offers (in a public "Agent Card"), Agent B discovers it, authenticates using standard web security (TLS, JWTs, OpenID Connect), and they exchange the task and its results over JSON-RPC 2.0 (InfoQ, July 2025; Wikipedia, Agent2Agent).

The key skills A2A standardizes:

Capability discovery - agents publish what they can do, so others can find and invoke them.
Task coordination - long-running jobs can be handed off, tracked, and resumed.
Secure messaging - authentication and transport reuse established web standards, not bespoke schemes.

Google donated A2A, its specification, and its SDKs to the Linux Foundation on June 23, 2025, which means the standard is now community-governed rather than controlled by one vendor (Linux Foundation press release).

How is A2A different from MCP?

A2A connects agents to agents; MCP (Model Context Protocol) connects agents to tools and data. They solve different halves of the same problem and are designed to be used together, not chosen between (Wikipedia, Agent2Agent).

	MCP	A2A
Connects	Agent -> tools, APIs, data sources	Agent -> agent
Introduced	Anthropic, November 2024	Google, April 2025
Typical job	"Read this file", "query this database", "post to Slack"	"Hand this brief to the writer agent", "ask the research agent for today's results"
Governance	Anthropic-led, open source	Linux Foundation project, 150+ organizations

Think of it this way: MCP is the plumbing that gives one agent hands. A2A is the phone line that lets one agent delegate to another. A mature multi-agent system gives each agent its own MCP tools and registers it on the A2A network so it can be found and tasked by the others.

Why does most multi-agent automation fail without a protocol?

Most ad-hoc multi-agent setups break down for a human reason, not a technical one: the person becomes the middleware. Every context switch between tools destroys working memory, every manual copy-paste loses formatting and structure, and every handoff is invisible, so when something goes wrong there is no log to inspect.

Three failure modes show up repeatedly:

Context loss. Output pasted from one chat window into another arrives without the reasoning, the sources, or the intermediate state. The receiving agent re-does work.
No audit trail. When Agent B produces something wrong, you cannot trace which input from Agent A caused it, because the handoff lived in your clipboard.
Lock-in. A hard-coded integration between two specific products breaks the moment you swap one of them out.

A protocol-based setup answers each of these mechanically: structured handoffs preserve state, every message is logged, and discovery means you can replace a component without rewiring the rest.

What does a working multi-agent architecture look like?

A practical multi-agent system has four layers, and A2A only covers one of them. Miss the other three and the protocol alone will not save you:

Shared memory (the knowledge layer). Every agent reads and writes to one common store - notes, task logs, decisions, and results. File-based options work well: plain markdown notes are local, owned by you, and durable. When you come back after a day away, every agent's work is accumulated there, already loaded, with nothing to re-explain. We cover how to build this compounding memory layer in our Claude + Obsidian persistent memory guide.
Agent communication (the A2A layer). Agents register their capabilities and exchange tasks using the protocol, so handoffs are structured and auditable.
Tool access (the MCP layer). Each agent connects to its own tools through MCP servers - for the stateless-vs-session tradeoffs in the current spec, see our MCP 2026 migration guide.
Orchestration and audit (the control layer). One dashboard or log where a human can see which agent is running, what it did, and what is queued. This is what turns "automation" into "a system you can trust while you sleep."

A workflow built on these layers might run like this: a research agent pulls overnight trends into the shared memory, a writer agent picks the top item and drafts, a quality agent checks the draft against a checklist, and a publisher agent pushes the pass to a CMS - with every handoff logged and inspectable. If you want the broader build sequence for that kind of system, our multi-agent AI operating system guide walks through the full stack, and the Agent OS daily operations playbook covers how to run it day to day.

How do you build your first two-agent A2A setup?

Start small. Two agents, one shared memory folder, one workflow. That is enough to learn everything the hard lessons teach.

Pick the workflow with the most manual handoffs today. Usually research -> draft, or monitor -> summarize -> notify. Choose the one you personally copy-paste every day.
Stand up the shared memory first. A single local folder of plain markdown notes both agents can read and append to. This is cheap, inspectable, and impossible to lock you in.
Give each agent its own tools via MCP. Research agent gets search and fetch; writer agent gets the file system and the CMS.
Connect them over A2A. Have each agent expose an Agent Card describing its skills, then have the orchestration layer route tasks between them through the protocol rather than through you.
Log every handoff. Minimum: timestamp, sending agent, receiving agent, task, artifact pointer. When quality drops, this log is the first place you look. For the discipline of judging agent output, our evaluation floor-raising method is the companion piece.
Add a third agent only when the first two are stable. Most teams that fail at multi-agent skip steps 2 and 5, not the protocol wiring.

What does all of this cost and who should actually build it?

The protocols themselves are free and open source. Your costs are model inference and whatever hosting you choose. A two-agent personal setup can run on a consumer machine with open-weight models for research and drafting, against effectively zero software cost; heavier workloads scale with API usage.

The honest sizing rule: if you currently spend under an hour a day shuttling context between AI tools, a single well-configured agent with good memory will do. The A2A layer earns its complexity once you have recurring workflows where multiple specialized agents each outperform a generalist - research, writing, monitoring, QA as separate roles with separate tools.

What this means for you

If you are solo or a small team, build the memory layer this week and connect your two most-handoff-heavy agents next. If you are already juggling three or more AI tools manually, go straight to the four-layer architecture above - the protocol is the easy 20%, the shared memory and audit log are the 80% that make it trustworthy. Either way, run one end-to-end workflow with full logging before you automate anything you publish or send to customers.

FAQ

Q: Is A2A owned by Google?
A: No. Google created it and announced it in April 2025, then donated the protocol, spec, and SDKs to the Linux Foundation in June 2025, where it is governed as a vendor-neutral open project with more than 150 supporting organizations.

Q: Does A2A replace MCP?
A: No. MCP connects an agent to tools and data sources; A2A connects agents to each other. A real multi-agent system uses both: each agent gets its tools over MCP and finds and delegates to other agents over A2A.

Q: Do I need A2A if I only run one AI agent?
A: No. A2A solves the agent-to-agent handoff problem. With a single agent, invest in MCP tool connections and a persistent memory layer instead - those deliver almost all of the practical benefit.

Q: Is A2A secure enough for business use?
A: Its security stack reuses established web standards - TLS, JSON Web Tokens, and OpenID Connect - rather than inventing new ones. You still need your own access controls and audit logging on top, exactly as with any internal service.

Q: What is the cheapest way to try a multi-agent setup?
A: Two agents, one shared folder of markdown notes as memory, one recurring workflow, and open-weight or free-tier models for inference. The total software cost can be zero; the real cost is the time spent designing the handoffs and the audit log.

Q: What breaks first when teams scale to five or more agents?
A: Shared memory contention and missing handoff logs, in our experience the two skipped steps. Agents overwrite each other's notes without a write convention, and without a central log a bad output becomes untraceable to the input that caused it.

Sources

Updates & Corrections

2026-08-25 - Initial publication; verified A2A timeline (April 2025 launch, June 2025 Linux Foundation donation, 150+ supporting organizations) and MCP/A2A division of responsibilities against the sources above.

Researched and drafted with AI agents; reviewed and fact-checked under human editorial oversight. How we work.

DEV Community