Short answer: The A2A protocol — short for Agent2Agent — is an open standard that lets independent AI agents discover each other, delegate tasks, and exchange results without custom integration code. Where the Model Context Protocol (MCP) connects a single agent to its tools and data, A2A connects agents to other agents: one handles the horizontal link between peers, the other the vertical link down to tools. An agent advertises what it can do through a machine-readable "agent card," other agents read that card to decide who to delegate to, and the two exchange structured tasks over HTTP with built-in authentication. A2A was introduced by Google in 2025 with more than 50 industry partners, donated to the Linux Foundation, and at its one-year mark passed 150 supporting organizations with integrations across Google, Microsoft, and AWS. It is real, it is standardized, and — like every agentic technology — the demo is easy and production is not.
The interesting question is not "what is A2A." It is what changes when agents can talk to agents instead of only to tools. A single agent with good tools can do a lot. But the moment you want a research agent to hand off to a writing agent, or a procurement agent to negotiate with a supplier's agent built by a different company on a different framework, you need a shared language for that conversation. A2A is the attempt to standardize it. Below: what the protocol actually is, how agent-to-agent communication works step by step, how A2A differs from MCP, why production is hard, and how we approach multi-agent systems at Moai Team.
What the A2A protocol actually is
A2A is a specification for how two AI agents communicate when they were not built together. Before it, every multi-agent system was a closed world: agents from the same team, on the same framework, wired together with bespoke glue code. If you wanted an agent built in LangGraph to delegate to an agent built on the OpenAI Agents SDK, you wrote a custom adapter — and rewrote it every time either side changed. A2A replaces that N-by-M problem with one protocol, the same way MCP did for tool integrations.
The design goals are narrow and worth stating plainly. A2A handles capability discovery (how an agent learns what another agent can do), task delegation (how it hands work over), modality negotiation (text, structured data, files, streams), and secure information sharing (proving identity and protecting the exchange). It deliberately does not tell you how to build an agent internally. Two agents can use completely different models, frameworks, memory systems, and reasoning loops; A2A only governs the wire between them. That opacity is the point — you delegate to an agent based on what it advertises, not on knowing how it works inside.
In 2026 this stopped being a thought experiment. The protocol reached a 1.0 release, the Linux Foundation reported more than 150 organizations supporting the standard, and the major cloud platforms — Google, Microsoft, AWS — shipped integrations. Reported production use spans supply chain, financial services, insurance, and IT operations: domains where work already crosses tools, vendors, and teams, and where a shared coordination layer pays for itself.
How agent-to-agent communication works
The mechanics are simpler than the hype suggests. A2A runs on ordinary web foundations — HTTP, JSON, and familiar auth — which is most of why it spread quickly.
It starts with the agent card. An A2A-capable agent publishes a structured descriptor, served at a well-known endpoint, that states its identity, its capabilities, the task types it accepts, the modalities it supports, and its authentication requirements. Think of it as a business card a machine can read: it tells another agent "here is what I do and here is how to reach me," without exposing any internal implementation. Discovery is just fetching and reading these cards.
From there a delegation follows a clear lifecycle:
- Discovery. A client agent fetches the candidate agent's card to confirm it can handle the task and to learn its endpoint and auth requirements.
- Authentication. The two establish trust using the scheme the card declares — A2A supports OAuth 2.0, OpenID Connect, API keys, standard HTTP auth, and mutual TLS, and agents can sign their cards so the recipient can verify identity and integrity.
- Task submission. The client sends a structured task — a request with the inputs and the expected output shape — rather than a free-form chat message.
- Execution with state. The remote agent works the task through well-defined lifecycle states (submitted, working, completed, failed) and can stream progress back for long-running jobs instead of blocking until done.
- Result return. The remote agent returns structured output. The client agent collects results — often from several delegated agents working in parallel — and assembles the final answer.
The unit that matters is the task, not the message. Older agent-communication ideas leaned on passing messages back and forth; A2A leans on tasks with explicit states and lifecycles, which is what makes a delegation observable and recoverable rather than a black-box chat. You can ask "what state is this task in," retry a failed one, and trace a request across agents — properties you need the moment more than one agent is involved.
A2A vs MCP: horizontal and vertical
The most common confusion is whether A2A competes with MCP. It does not. They solve different problems and are designed to compose.
MCP is vertical: it connects one agent down to its tools, data sources, and APIs. When an agent queries a database, reads a document, or calls an internal service, that is MCP's territory — the agent-to-tool link. We cover it in depth in MCP Explained and the build in how to build an MCP server.
A2A is horizontal: it connects one agent across to another agent. When a research agent delegates writing to a separate writing agent, or a coordinator splits a job across specialists, that is A2A's territory — the agent-to-agent link.
A clean mental model: MCP gives an agent hands to operate tools; A2A gives agents a shared language to talk to each other. A realistic multi-agent system uses both at once. A coordinator agent reaches up and out to peer agents via A2A, and each of those agents reaches down to its own tools via MCP. The two protocols stack rather than collide, and the strongest production designs treat them as complementary layers, not competing standards.
One consequence is worth flagging early because it becomes a security problem later: when A2A and MCP combine, the attack surface combines too. An attacker who uses A2A discovery to find an agent can then try to exploit weaknesses in that agent's MCP tool connections — for example, reaching an insecure MCP server through an agent it found via A2A. Composing protocols composes their risks. More on that below.
Where A2A breaks in production
The protocol is the easy part. Two agents exchanging a task over A2A is a quickstart. A fleet of agents from different teams and vendors, coordinating reliably under load, is an engineering program. The gaps show up in four places.
Security is the hard ceiling. Agent-to-agent interactions are dynamic and often unpredictable — agents discover and delegate at runtime, not according to a fixed integration diagram drawn in advance. Traditional perimeter security assumes you know who talks to whom; A2A breaks that assumption by design. You have to authenticate every agent, verify card signatures, scope what a delegated agent is allowed to ask for, and assume any agent you discover could be hostile or compromised. The combined A2A-plus-MCP attack vectors above make this the first thing to get right, not the last.
Trust and governance do not come for free. A card tells you what an agent claims it can do. It does not tell you whether to believe it, whether the agent behind it is the one you think, or what happens when it returns wrong or harmful output. Who is accountable when a delegated agent acts badly? Which agents is yours allowed to talk to at all? Those are governance decisions the protocol enables but does not make for you.
Observability gets harder with every hop. Debugging one agent is already work. Debugging a request that fans out across three delegated agents — each with its own model, prompts, and tools — means you need tracing that follows the task across boundaries, or a failure becomes impossible to locate. A2A's explicit task states help, but you still have to instrument the system. This is the multi-agent version of the problem we cover in AI agent observability.
Reliability compounds. Each delegation is a network call to a semi-autonomous system that can be slow, fail, or return something unexpected. Chain several together and individual failure rates multiply. Production A2A needs timeouts, retries, fallbacks, and durable handling of long-running tasks — the same durable execution discipline that keeps single agents alive, now stretched across agent boundaries.
None of this argues against A2A. It argues against treating "the agents can talk now" as the finish line. The protocol gets you to the starting line of a multi-agent system. The engineering around it decides whether that system survives contact with production.
When you actually need A2A
A2A earns its complexity when coordination genuinely crosses a boundary. Three patterns where it fits:
- Cross-vendor or cross-team agents. Your agent needs to work with an agent built by a different company, on a different stack, that you do not control. This is the case A2A was built for — no shared codebase to write glue against.
- Specialist division of labor. A complex job decomposes into distinct capabilities (research, analysis, drafting, review) that are cleaner to build, test, and own as separate agents than as one monolith. A2A lets a coordinator route between them through a stable interface.
- An open agent ecosystem. You want other people's agents to be able to call yours, or yours to discover and use theirs, the way services expose APIs today.
And the honest inverse: if everything lives inside one team, one framework, and one deployment, you may not need A2A at all. A single well-designed agent with good tools, or an in-process multi-agent setup, is often simpler and more reliable than a distributed protocol. We cover that trade-off in single-agent vs multi-agent systems. Reach for A2A when the boundary is real — different owners, different stacks, or an ecosystem you want to be open to — not because multi-agent sounds more advanced.
The market pressure to figure this out is real regardless. Gartner projects that 40% of enterprise applications will feature task-specific AI agents by the end of 2026, up from less than 5% in 2025, and surveys put 84% of enterprises planning to increase agent investment this year. As agents multiply inside and across organizations, the coordination layer between them stops being optional.
How Moai Team approaches multi-agent systems
We treat A2A as plumbing, not strategy. Adopting the protocol is a day of work; deciding whether your problem needs multiple agents at all is the decision that matters, and we make it before any protocol enters the picture. Most "we need a multi-agent system" requests are better served by one well-scoped agent with sharp tools — fewer moving parts, fewer failure modes, easier to evaluate.
When the boundary is genuine — agents across teams, vendors, or an ecosystem — we design the coordination layer the way we design any production system. Security first: every agent authenticated, every card verified, every delegation scoped to least privilege, and the combined A2A-plus-MCP surface threat-modeled rather than assumed safe. Then observability: distributed tracing that follows a task across every hop, so a multi-agent failure is locatable instead of a mystery. Then evaluation: we test the coordinated system end to end, not just each agent alone, because a multi-agent system fails in the seams between agents, and the seams are exactly what single-agent tests miss. The protocol standardizes the conversation. Getting that conversation to behave reliably under real traffic is the work — and it is the work we do.
Frequently Asked Questions
What is the A2A protocol?
A2A (Agent2Agent) is an open protocol that lets independent AI agents discover each other, delegate tasks, and exchange results without custom integration code. Introduced by Google in 2025 with 50+ partners and now governed by the Linux Foundation, it reached a 1.0 spec and 150+ supporting organizations within its first year. It standardizes agent-to-agent communication the way MCP standardized agent-to-tool communication.
What is the difference between A2A and MCP?
MCP is vertical — it connects a single agent down to its tools, data, and APIs. A2A is horizontal — it connects one agent across to another agent. MCP gives an agent hands to use tools; A2A gives agents a shared language to talk to each other. They are complementary, not competing: a realistic multi-agent system uses A2A between agents and MCP within each agent.
What is an agent card in A2A?
An agent card is a machine-readable descriptor that an A2A agent publishes at a well-known endpoint. It declares the agent's identity, capabilities, supported task types and modalities, and authentication requirements. Other agents fetch the card to discover what an agent can do and how to reach it, without needing to know how the agent is built internally.
Is A2A ready for production?
The protocol is stable and standardized, and there are production deployments across finance, supply chain, insurance, and IT operations. But A2A only standardizes how agents communicate. Running a reliable multi-agent system on top of it still requires solving security (including combined A2A-plus-MCP attack vectors), governance, distributed observability, and reliability — the engineering work the protocol does not do for you.
Building a multi-agent system and trying to decide whether A2A belongs in it — or how to make one behave in production? Talk to Moai Team.