What is the A2A protocol?

The A2A protocol, short for Agent2Agent, is an open protocol for communication between AI agents. Its purpose is easy to state and hard to design well: let one agent discover what another can do, hand it work, follow that work as it progresses, and collect the result, all without every vendor or framework inventing a private integration contract.

That matters because agent systems are moving out of isolated chat boxes and into distributed work environments. One agent may live inside a CRM. Another manages procurement, while a third sits inside a document automation platform. If each can reach only its own tools and memory, the system degrades into a set of disconnected assistants. Give them a shared protocol and teams can begin composing specialized agents the way they already compose services.

The official A2A documentation describes a protocol for agent interoperability, and the A2A project repository publishes the specification and implementation material. A2A does not make agents intelligent on its own. What it standardizes is the way already-built agents expose capabilities and exchange work.

The short version

A2A is a communication protocol for agent-to-agent collaboration. In practice, it gives one agent a way to answer three questions about another:

• What can you do?
• How do I ask you to do it?
• How do I track and receive the result?

The first question is about discovery: an agent needs a machine-readable description of another agent's skills, supported interaction modes, and endpoint. The second is about task exchange, since the caller has to send structured work rather than a vague chat message. The third is about state. Real work may take seconds, minutes, or much longer, so the protocol has to represent progress and failure states, plus any artifacts the work produces.

This differs from a single-agent tool call, which usually means one agent invoking a function, an API, a database query, a browser action, or a business operation. A2A covers something larger. One agent delegates to or coordinates with another agent, one that runs its own reasoning loop and carries a defined policy and responsibility boundary.

Why A2A matters now

The first generation of agent work was mostly local. A team would build one assistant, give it a few tools and some retrieval, then push it to complete a narrow workflow. That works for simple tasks. It breaks down the moment work crosses an organizational or technical boundary.

Imagine an insurance operations assistant that needs underwriting context from one system, legal clause review from another, and billing exceptions from a third. Everything could be crammed into one giant agent, but then permissions, prompts, observability, and failure modes all become hard to reason about, and a single change to one prompt can degrade behavior in a corner of the workflow that nobody was looking at when the change shipped. That is the trap a clean boundary avoids. A cleaner architecture is often a set of specialized agents with clear ownership:

• A claims agent that understands intake, status, and missing documents.
• A policy agent for coverage terms and endorsements.
• Billing holds and account status go to a finance agent.
• Above them, a supervisor agent coordinates the overall customer request.

A2A gives those agents a common coordination surface. The builder still owns security design, task modeling, and the evaluation work that proves any of it functions; what the protocol takes off the table is the custom plumbing each agent would otherwise need just to find and call the others. That plumbing is the expensive part.

Underneath, the core idea is that agents expose their capabilities in a predictable way. A consuming agent should not have to wait for a developer to read a README and hand-wire every instruction. It inspects a structured description of the remote agent, learns what kinds of work it accepts, and then communicates through a standard task lifecycle. In production architecture, that usually maps to four concerns:

1. Capability discovery. The remote agent publishes information about its identity, purpose, skills, and endpoints.
2. Task submission. The calling agent sends a task with the context the remote agent needs.
3. State tracking. The task can move through states such as submitted, working, completed, failed, or requiring input.
4. Artifact exchange. The result may include text, structured data, files, decisions, or references to work products.

This lifecycle matters because agent work rarely behaves like a normal request-response API call. A deterministic API returns one response or one error, whereas agent work can span multiple steps, requests for clarification, partial results, tool use, and asynchronous progress that arrives long after the original call. The shapes do not match.

A2A compared with tools and MCP

A common mistake is to treat A2A, tool calling, and MCP as interchangeable. They solve adjacent problems, not the same one.

MCP is usually about connecting a model client to tools, prompts, and resources. A2A is about communication between agents that may each carry their own tools and context. Both often show up in the same system. An agent can expose itself through A2A while using MCP servers behind the scenes to reach databases, document stores, and business tools.

Where teams use it

A2A earns its place once a team has more than one meaningful agent boundary. If the whole system is a single assistant with three simple tools, the protocol is probably overkill. But when different agents are owned by different teams, deployed in different environments, or responsible for different domains, a standard agent-to-agent protocol starts to pay off. Good candidates include:

• Multi-department workflows where legal, finance, operations, and support each own part of a process.
• Partner ecosystems where an external agent needs to request work from an internal agent without direct access to internal tools.
• Agent marketplaces or registries where clients discover agents by capability.
• Enterprise systems that need audit trails around which agent accepted which task and returned which artifact.
• Long-running workflows where a coordinator agent delegates tasks and collects status over time.

The appeal here is reduced integration fragility, not novelty. Without a protocol, every pair of agents needs a custom contract, and ten agents can balloon into dozens of pairwise integrations, each carrying quirks, failure modes, and a maintenance burden that compounds over time. A shared protocol collapses that. Agents converge on a smaller, more consistent communication pattern.

A few misunderstandings come up often. The first treats A2A as a replacement for application APIs. A stable deterministic API can still be called directly or through a tool layer; A2A only earns its keep when the thing being called is itself an agent with judgment, state, and a task lifecycle.

The second assumes that interoperability implies trust. A protocol can define message shapes and states, yet it cannot decide on its own whether one agent should be allowed to ask another for sensitive work. Production systems still need authentication, authorization, audit logs, data minimization, and policy enforcement.

The third confuses an agent description with a service guarantee. A capability card may claim that an agent handles contract review, but builders still need evals, test cases, escalation paths, and monitoring before they trust that the capability is reliable enough to ship.

Practical adoption guidance

Start with boundaries rather than protocol enthusiasm. Ask which agents should exist independently. A good boundary tends to have a clear domain, clear permissions, clear failure ownership, and clear artifacts. If the boundary itself is vague, A2A will not fix it.

Next come the task contracts. Decide what the calling agent sends and which context is mandatory, what output shape the caller expects, and how the remote agent should behave when it needs clarification. Spell out which artifacts get stored and which events get logged. These decisions matter far more than the transport details.

For early deployments, keep the set of exposed skills small. A remote agent advertising ten broad capabilities is much harder to evaluate than one that exposes two specific task types. Treat agent-to-agent calls like the production integration points they are: version them, observe them, and test them under failure.

At XY Space, the pattern that holds up is a coordinator agent plus specialized operational agents. The coordinator understands the user journey, while the specialists own bounded work such as intake classification, policy lookup, draft generation, or compliance review, each with distinct permissions and a clear definition of done. What makes A2A interesting is that it gives that architecture a standard collaboration layer instead of a pile of custom webhooks.

Sources

• A2A protocol documentation
• A2A project repository