The A2A Protocol, short for Agent2Agent Protocol, is an open standard for communication between independent AI agent systems.
That sentence sounds simple, but it implies something most AI agent demos skip entirely. Most demos still assume one assistant, one runtime, one tool loop, and one owner — the agent can search, call tools, write code, query APIs, maybe use MCP servers, and return an answer.
A2A is designed for a different world, one where agents may be built by different teams, frameworks, vendors, languages, or organizations. It assumes one agent may need to discover another agent, understand what it can do, send it work, exchange messages, receive files or structured outputs, and track a task until completion — making it not just another tool calling format, but a genuine attempt to make AI agents interoperable as peers.
The core concepts are:
- Agent Cards
- Agents and clients
- Tasks
- Messages
- Parts
- Artifacts
- Task states
- Streaming and asynchronous updates
This article explains those concepts in plain engineering terms, with enough detail to understand where A2A fits in real multi-agent systems.
The Short Definition
A2A is a protocol for agent-to-agent communication.
It lets one agent or client communicate with another agent through a common model. The receiving agent can describe its capabilities, accept work, manage the lifecycle of that work, ask for more input, stream progress, and return concrete outputs.
The point is not to standardize how an agent thinks internally — it is to standardize how agents talk at their boundaries.
An A2A agent might internally use:
- Python
- Go
- JavaScript
- LangGraph
- CrewAI
- Semantic Kernel
- custom code
- MCP servers
- private APIs
- vector databases
- workflow engines
The caller does not need to know any of that. What the caller does need to know is:
- What can this agent do?
- How do I talk to it?
- What input does it accept?
- What output can it produce?
- How do I track the work?
- How do I receive the result?
Those six questions define the protocol boundary A2A is trying to establish between independently operating agents.
Why A2A Exists
AI systems are moving from single assistants to networks of specialist agents.
A company might have:
- A support agent
- A billing agent
- A legal review agent
- A DevOps agent
- A data analysis agent
- A research agent
- A documentation agent
- A code review agent
Each agent may have its own tools, permissions, domain knowledge, prompts, memory, retrieval system, and audit rules.
Without a shared protocol, every integration becomes custom — the support agent needs bespoke wiring to the billing agent, the billing agent needs its own to the legal agent, and the research agent needs yet another to the documentation agent. That combinatorial overhead does not scale well as the agent network grows.
A2A gives these agents a common way to interact, reducing the N×M integration problem to a single shared contract. The promise is not magic autonomy; the promise is interoperability.
A2A Is Not MCP
A2A is often compared with MCP, but they solve different problems.
MCP, or Model Context Protocol, is mainly about connecting an AI app or agent to tools, resources, and prompts, while A2A is mainly about connecting agents to other agents.
A useful mental model is:
MCP: agent to tool
A2A: agent to agent
For example, an agent may use MCP to access:
- GitHub
- a filesystem
- a database
- Slack
- a documentation search system
- a cloud API
Practical guides for building those MCP servers are available for .
The same agent may use A2A to delegate work to:
- a security review agent
- a research agent
- a planning agent
- a compliance agent
- a coding agent
The two protocols can and often do work together. A clean architecture is often:
A2A outside the agent boundary.
MCP inside the agent boundary.
That means other agents communicate with your agent using A2A, while your agent internally uses MCP to access tools — a clean separation of concerns that keeps the external interface stable regardless of what changes inside. For a detailed comparison of how the two protocols divide architectural responsibility and when you actually need both, see .
Architecture Pattern: Orchestrator And Specialists
The most common A2A pattern is probably orchestrator plus specialists.
In this pattern, one primary agent receives the user request and delegates pieces of work to specialist agents.
Example:
Primary assistant
|
|-- A2A --> Legal agent
|-- A2A --> Finance agent
|-- A2A --> Research agent
|-- A2A --> Writing agent
This pattern is easy to understand: the orchestrator owns the overall workflow, and specialist agents own domain-specific work. The downside is that the orchestrator can become a bottleneck, and it needs a solid routing strategy to delegate effectively — the underlying model selection and orchestration trade-offs are covered in covers the instrumentation and tooling side of this problem in depth.
Common Mistakes
Mistake 1: Calling Every Tool An Agent
Not every tool is an agent.
A calculator is a tool. A file reader is a tool. A database query endpoint is a tool.
If it does not own a task, ask for input, produce artifacts, or behave as an independent peer, it probably does not need A2A.
Mistake 2: Making Agent Cards Too Vague
An Agent Card should not say:
This agent helps with business tasks.
That is useless to any agent trying to route work intelligently. A good card should say what the agent actually does, what it accepts, what it returns, and what constraints apply.
Mistake 3: Ignoring Task State
If you use A2A but treat every interaction as request and response, you are missing much of the value.
The task model is one of the primary reasons to use A2A over a plain API — skipping it means rebuilding the same lifecycle tracking logic in every integration.
Mistake 4: Returning Everything As Text
A2A supports structured and multimodal content. Use it.
If the output is a report, return a report artifact.
If the output is JSON, return structured data.
If the output is a file, return a file.
Do not flatten everything into plain text unless plain text is the right output.
Mistake 5: No Permission Model
Agent networks without permission boundaries are risky.
Every agent should not be allowed to call every other agent with every kind of data — use authentication, authorization, and audit trails to enforce the principle of least privilege across the agent network.
When Should You Use A2A?
Use A2A when you have real agent boundaries.
Good reasons include:
- agents are owned by different teams
- agents are deployed as separate services
- agents are built with different frameworks
- agents need to discover each other
- agents need to delegate tasks
- tasks may be long-running
- results may include artifacts
- clients should not know internal tools
- agent capability metadata matters
Weak reasons include:
- it sounds modern
- you want to call one function
- you have a single-agent app
- a normal API would work
- MCP already solves your tool integration problem
A2A is powerful when the system is actually multi-agent; it is unnecessary ceremony when the system is not, and the cost of that ceremony — added concepts, infrastructure, debugging surface, and security requirements — is real.
A Minimal Mental Model
If you remember only one thing, remember this:
Agent Card: what the agent can do.
Message: what agents say to each other.
Part: typed content inside a message or artifact.
Task: work the agent owns.
Artifact: output the task produced.
That is the core of A2A — the rest is mostly about making those five concepts reliable, observable, and secure enough to use in real production systems.
Final Thoughts
A2A is not just another AI acronym — it is part of a larger shift from isolated assistants to interoperable agent systems. That shift will not happen everywhere at once, and many applications will remain single-agent systems with good tool access where MCP and normal APIs are entirely sufficient.
But once agents become separately deployed peers, you need stronger boundaries: discovery, task ownership, messages that carry more than text, artifacts as first-class outputs, and security, state, and observability that span agent boundaries. That is the space A2A is trying to occupy, and it is a genuinely different problem from the tool-integration problem MCP solves.
My opinion: do not start with A2A for small projects. Start with a useful agent, good tools, and clear architecture — the
SOCIAL SHARE CARD GENERATOR