What is Agent2Agent (A2A)? The Open Protocol for AI Agent Communication

Most AI systems today are single agents: one model, one prompt loop, one toolset. That works until a workflow needs another specialized agent, possibly owned by another team, to complete a step. Without a shared protocol, agents cannot reliably discover each other, exchange work, stream progress, or return results. Agent2Agent (A2A) is designed to standardize that agent-to-agent layer.

Try Apidog today

This guide explains what A2A is, what problem it solves, how the protocol works, and how it differs from MCP. If you want to test an A2A agent after reading, the Apidog A2A Debugger guide continues with a hands-on debug flow.

What is Agent2Agent (A2A)?

Agent2Agent (A2A) is an open protocol for communication between AI agents. It defines how an agent:

• Publishes its capabilities
• Lets another agent connect
• Exchanges messages and files
• Tracks task state
• Returns structured results

The important part is between agents. A2A is not about giving one agent more tools. It is about letting independent agents, often built with different frameworks by different teams, collaborate without exposing their internal implementation.

Think of it like HTTP for agent traffic. HTTP lets a browser talk to any web server without caring what language the server uses. A2A lets a LangGraph agent talk to a CrewAI agent without caring how that agent was built. Both sides agree on the protocol envelope.

Google introduced A2A in 2025 and later moved it to the Linux Foundation as a vendor-neutral project. The spec is available in the A2A GitHub repository, with reference implementations published on the A2A project site.

The problem A2A solves

Before A2A, connecting two agents usually meant writing custom integration code.

For example, if your agent needed to call another team’s research agent, you had to define:

• A custom request payload
• A custom response shape
• A task status convention
• Authentication headers
• Retry and timeout behavior
• Streaming or polling logic

Then you had to repeat the same work for the next agent.

That breaks down quickly because there is no shared contract:

• No discovery: An agent cannot ask, “What can you do?” in a standard way.
• No shared task model: One agent returns text, another returns JSON, another streams tokens.
• No common auth shape: Each integration invents its own credential handling.
• No interoperability: Replacing one agent with another requires custom changes.

A2A solves this by giving agents a common contract, similar to how OpenAPI standardized REST API descriptions.

How A2A works

A2A has four core concepts:

1. Agent Cards
2. Tasks
3. Messages and artifacts
4. Streaming updates

1. Agent Card

An Agent Card is a JSON document that describes an agent.

It includes metadata such as:

• Agent name
• Description
• Capabilities
• Skills
• Supported input and output types
• Authentication requirements
• Protocol version

By convention, the card is published at a well-known URL, for example:

https://your-agent.example.com/.well-known/agent.json

A caller fetches this first, reads the available skills, and decides what it can request.

A simplified Agent Card might look like this:

{
  "name": "Research Agent",
  "description": "Finds sources and summarizes research topics.",
  "version": "1.0.0",
  "protocolVersion": "0.2.0",
  "skills": [
    {
      "id": "web_research",
      "name": "Web Research",
      "description": "Researches a topic and returns a summary with sources."
    }
  ],
  "capabilities": {
    "streaming": true
  }
}

The exact required fields depend on the A2A specification version, so use the official spec as your source of truth.

2. Tasks

A task is the unit of work in A2A.

When Agent A asks Agent B to do something, that request becomes a task. The task has an ID and a lifecycle. Common task states include:

submitted
working
input-required
completed

This gives the caller a consistent way to track progress, regardless of which agent performs the work.

A typical flow:

Agent A creates task
Agent B marks task as working
Agent B requests more input if needed
Agent B completes task
Agent A reads final artifacts

Because every compliant agent follows the same task model, callers do not need custom status handling for each integration.

3. Messages and artifacts

A message carries content between agents.

Messages are made of parts, such as:

• Text
• Files
• Structured data
• Mixed content

For example, a caller might send a text instruction plus a file attachment.

When the receiving agent finishes, it returns artifacts. Artifacts are the outputs of the task, such as:

• A generated report
• A summary
• A table
• A file reference
• Structured JSON

This keeps input and output consistent: both messages and artifacts are built from parts.

4. Streaming and updates

A2A supports server-sent events (SSE), so long-running tasks do not need to block.

Instead of waiting silently, an agent can stream status updates and partial results.

Example progress updates:

Task submitted
Searching sources
Found 3 relevant sources
Drafting summary
Task completed

This is useful for research, code generation, document processing, or any workflow where the caller should show progress instead of a spinner.

A typical A2A request flow

A production A2A interaction usually looks like this:

1. Agent A fetches Agent B’s Agent Card.
2. Agent A checks Agent B’s skills and supported input types.
3. Agent A creates a task with a message.
4. Agent B processes the task.
5. Agent B streams progress updates if supported.
6. Agent B returns artifacts.
7. Agent A consumes the artifacts and continues the workflow.

The transport is JSON over HTTP. The protocol standardizes the agent contract, not the internal implementation.

A2A vs MCP

A2A and the Model Context Protocol (MCP) are often confused because both are open protocols used in AI agent systems. They solve different problems.

	A2A	MCP
Connects	Agent to agent	Agent to tools and data
Question it answers	“Can another agent do this step for me?”	“What tools and resources can this one agent reach?”
Typical use	Multi-agent workflows across teams	A single agent calling a database, file system, or API
Unit of exchange	Tasks, messages, artifacts	Tool calls, resources, prompts

Use MCP when one agent needs access to external systems such as a database, file system, or API.

Use A2A when one agent needs to delegate work to another agent.

A real system can use both:

User request
  ↓
Agent A
  ├─ uses MCP to query a database
  └─ uses A2A to delegate research to Agent B

For a deeper comparison, see the MCP server vs A2A breakdown. To inspect the MCP side in practice, see Apidog’s MCP client debugger.

Multi-agent collaboration in practice

A2A is one way to make agents collaborate, but it is not the only pattern.

Some systems use direct orchestration, where one agent explicitly controls the workflow and delegates to another known agent.

A good open-source example is Codex-Claude-Collab, which coordinates a real-time workflow between OpenAI Codex and Claude Code. Codex plans the task, delegates implementation to Claude Code, reviews the diff, verifies the result, and then answers the user.

That is hard-wired orchestration. One side knows exactly which other agent it is calling.

A2A generalizes the same idea. Instead of hard-coding a specific agent, a caller reads an Agent Card and works with any compliant agent that exposes the required capability.

Use orchestration when:

• You control both agents
• The workflow is fixed
• Tight coordination is required

Use A2A when:

• Agents are owned by different teams
• Agents need to be swappable
• You need discovery
• You want a shared task and message model

Most mature systems will likely use both: orchestration inside a team, A2A across team or product boundaries.

How to test an A2A agent

After you build or consume an A2A agent, test the protocol layer before debugging the agent logic.

Start with these checks:

1. Can the caller fetch the Agent Card?
2. Does the card declare the expected skills?
3. Does authentication work?
4. Can you create a task?
5. Do task status updates arrive correctly?
6. Are final artifacts returned in the expected format?
7. Does streaming work for long-running tasks?

Console logs are usually not enough because A2A payloads are structured. You need to inspect the actual request and response.

Apidog includes an A2A Debugger in its standard client. You can paste an Agent Card URL, connect to the agent, inspect its name, capabilities, and skills, send test messages, attach files, add metadata, and read the response in multiple views:

• Readable preview
• Raw content
• Full JSON-RPC payload

It also supports Bearer Token, Basic Auth, and API-key headers without needing to hand-write curl commands.

The goal is isolation. When an A2A integration fails, first determine whether the problem is transport, authentication, payload shape, task state, or agent logic.

The Apidog A2A Debugger guide walks through a full connect-send-read loop. The same confirm-the-wire-first approach also applies when testing AI agents that call your APIs.

Getting started with A2A

If you want to build or connect an A2A agent, use this path:

1. Read the A2A specification.
2. Review the required Agent Card fields and task lifecycle.
3. Run one of the reference sample agents locally.
4. Open the sample Agent Card URL.
5. Send a simple text message and confirm the round trip.
6. Add authentication.
7. Add file attachments if your use case needs them.
8. Add streaming once the basic task flow works.
9. Wire the agent into your larger workflow only after the protocol layer is verified.

A minimal implementation checklist:

[ ] Publish Agent Card
[ ] Declare skills
[ ] Support task creation
[ ] Return task status
[ ] Accept message parts
[ ] Return artifacts
[ ] Handle auth
[ ] Support streaming if needed
[ ] Test with real payloads

A2A is still young, but it is backed by a vendor-neutral foundation and a growing list of framework integrations. Treating agent traffic as a protocol now can help avoid custom glue code later.

For more context, see AI agents are the new API consumers and designing APIs for AI agents.

Common questions

Is A2A made by Google?

Google introduced A2A in 2025, then donated it to the Linux Foundation as a vendor-neutral open project. The spec is developed in the open, and any vendor can implement it.

Do I need A2A if I only have one agent?

No. A2A solves agent-to-agent communication. If you have one agent that needs tools or data sources, MCP is usually the relevant protocol. Use A2A when a second agent enters the workflow.

What frameworks support A2A?

A2A is framework-agnostic. Any agent that publishes a valid Agent Card and speaks the protocol can participate. The caller does not need to know whether the agent was built with LangGraph, CrewAI, AutoGen, or a custom stack.

Is A2A the same as MCP?

No. MCP connects one agent to tools and data sources. A2A connects agents to each other. They are complementary and can run in the same system.

How do I debug an A2A integration?

Use a visual A2A debugger such as the Apidog A2A Debugger. Paste the Agent Card URL, send test messages, and inspect the raw request and response to separate transport bugs from agent logic bugs.

Does A2A support long-running tasks?

Yes. A2A has explicit task states and supports server-sent events for streaming progress updates and partial results. This lets long-running jobs report progress instead of blocking silently.