What is A2A (Agent to Agent) Protocol
Learn what the A2A Agent to Agent protocol is, how it compares to MCP and ACP, and how to build narrow agents with explicit message contracts, streaming, and metrics
The A2A protocol is a standards-based way for AI agents to discover each other, describe what they can do, exchange tasks and messages, and report results in a predictable lifecycle. It gives teams a shared contract for agent interoperability so you can plug a capable agent into different clients and ecosystems without rebuilding custom adapters for every integration.
In practice, you define an agent card that advertises capabilities and contact details, you agree on message shapes and status transitions, and you use common transports like HTTP with streaming for long-running work.
When I took training at work on agent-to-agent communication protocols, my lightbulb moment was realizing our service did not need a Model Context Protocol server that only exposes tools. We needed an autonomous agent that can accept a task, maintain state, and collaborate with other agents through a standard contract. That pushed me toward learning more about A2A because it treats the remote side as a peer agent, not just a bucket of tools.
This article is written for productive engineers who stay up to date and automate a lot of the work of their teams, and earn the credibility and career capital from their managers and peers.
In this post, you’ll learn
A mental model for client and remote agents
The requests, responses, and errors of the A2A protocol
A decision table to choose between A2A, MCP, and ACP
A2A cards and the mental model
Think of an A2A card as an agent’s ID card. A human ID card tells a guard who you are, who vouches for you, what you are allowed to do, and how to contact your next of kin. An A2A card does the same for software agents. It tells a client agent who owns this agent, what capabilities it exposes, how to talk to it, and what rules apply. The mental model is simple. Clients should never guess. They should read the card, verify it, and then call the capability they need with inputs that match the published schema.
When I took a training on agent communication, the ID card analogy made this protocol very simple to understand. Your client only needs this document to make discovery and negotiation explicit.
More on the ID card analogy
A client agent should follow a three-step process. Read the card, validate that the needed capability exists and the schema fits the payload, and only then create a task.
Example card
{
“name”: “q&a-agent”,
“version”: “1.2.0”,
“owner”: “team-knowledge”,
“description”: “Answers product FAQs with citations”,
“endpoints”: {
“task”: “<https://api.example.com/qa/task>”,
“stream”: “<https://api.example.com/qa/stream>”
},
“auth”: {
“methods”: [”bearer”],
“scopes”: [”qa.ask”, “qa.read”]
},
“capabilities”: [
{
“name”: “answer_question”,
“input_schema”: {
“type”: “object”,
“required”: [”question”],
“properties”: {”question”: {”type”: “string”}, “max_tokens”: {”type”: “integer”}}
},
“output_schema”: {
“type”: “object”,
“required”: [”answer”, “citations”],
“properties”: {
“answer”: {”type”: “string”},
“citations”: {”type”: “array”, “items”: {”type”: “string”, “format”: “uri”}}
}
}
}
],
“changelog”: [
{”version”: “1.2.0”, “notes”: “Added max_tokens optional input”},
{”version”: “1.1.0”, “notes”: “Streaming endpoint introduced”}
],
“contact”: {”email”: “qa-agent@company.com”}
}Roles, capabilities, and the contract for messages
A2A works best when contracts are boring and explicit. That means you define roles, list capabilities with names and schemas, and write message shapes that never hide complexity. If you are strict here, your agents will be easy to replace and easy to observe.
Capabilities:
Each capability is a named function like
answer_questionYou publish input and output schemas in the agent card
Capabilities are versioned and backward compatible where possible
Message contract:
Every message has a type, an id, a correlation_id, a created_at timestamp, and a schema_version
Tasks move through states (e.g. accepted, in_progress, streaming_update, completed, failed, cancelled)
Artifacts are the durable outputs. Parts are chunked or streamed slices of an artifact
Authentication and audit basics:
Auth should be explicit with method and scopes (OAuth 2.0)
Include requester identity in a caller field and always log correlation_id
Add a privacy field for data handling intent and retention hints
A2A vs MCP vs ACP. When to pick each
Use the table and the simple flow that follows.
When I was thinking about our flows at work, MCP would only expose tools and context. Our real win was an agent that accepts a task and negotiates outputs with other agents. That pushed me toward A2A to create an agent that interacts with the agents from other teams. If your goal is to wire a chatbot to a codebase or a calendar, MCP can be a faster first step. But agentic capabilities need these specialized AI agents collaborating between themselves
Some rules of thumb:
Prefer A2A when independent teams will own agents, and each team is best suited to interpret their own data.
Prefer MCP when your assistant is the center and external systems are just tools surfacing information, but you’ll interpret the data yourself.
Prefer ACP when your constraints are enterprise routing, governance, and standardization
How A2A works end-to-end
Transports
HTTP for control messages like create task and get status.
Streaming for partial results and progress.
JSON for message bodies with a schema_version field to manage evolution
A typical flow:
Client agent resolves the remote agent card.
Client authenticates and creates a task.
Remote agent accepts and returns a task id.
Client subscribes to a stream and receives parts for early rendering
Remote agent completes and sends artifact references with metrics
Client persists artifacts and records KPIs
Security basics
Deploying a public agent needs all the standards you’d follow in any other deployed service.
Scope tokens by capability and call path (Least Privilege principle)
Enforce rate limits per caller and per capability
Include audit fields like caller, purpose, and retention hints
Practical use cases for A2A agents
A2A shines when multiple agents must coordinate around a shared task with clear boundaries. Good fits include research and curation, compliance checks with structured outputs, and data pipeline steps where each agent contributes a typed artifact.
Why a standard beats ad hoc agent modes that browse websites (e.g. ChatGPT Agent Mode, the previous “operator”)
Reliability. A2A gives a stable contract with backward-compatible schema evolution. Agents that navigate will break when UI changes.
Observability. You get correlation IDs, progress updates, and metrics. Scraping offers screenshots and hope
Security and compliance. You can scope tokens and log audit fields. A headless browser with cookies is hard to reason about, and you may need to deal with different authentication mechanisms.
Latency and cost. Offloading work to a peer agent reduces round-trips. Streaming lets you render early without burning tokens
Replaceability. Another team or vendor can offer a faster or cheaper agent. Swapping the remote agent is a card change, not a rewrite.
Define narrow responsibilities and success metrics for each agent
Narrow responsibilities reduce coupling and make failures obvious. Give each agent a single purpose with a single primary metric and a small set of guardrail metrics.
Agent responsibility statement:
Purpose. Summarize three authoritative sources on a topic into a one page brief
Inputs. A curation artifact with three URLs and short rationales
Outputs. A summary artifact with 300 to 500 words and three citations
Out of scope. Web navigation or source discovery
Dependencies. MyOtherAgent v1.0
Anti-patterns to avoid:
Kitchen sink agents that do everything. For example, discover news articles, read, summarize, and decide which to show. Agents act like your conversation with ChatGPT. It’s better to start a new one than continue carrying over unrelated context.
Hidden coupling through shared globals or undocumented side effects. Communicate through the agent card’s inputs and outputs
Some rapid-fire questions about the A2A, ACP, and MCP protocols
How is A2A different from MCP in real projects
A2A treats the remote side as a peer agent that accepts tasks, streams progress, and returns artifacts. MCP focuses on giving a single assistant access to tools and resources inside the model session. If you want multi agent collaboration across teams and vendors, A2A usually fits better.
What does an agent card include and where do I host it
An agent card lists name, version, endpoints, capabilities with input and output schemas, authentication methods, and contact details. Host it at a stable URL behind your domain and cache it with an etag so clients can revalidate quickly.
When should I use ACP from IBM instead of A2A
Use ACP when you operate in an enterprise environment that standardizes communication patterns, routing, and governance across services. If your core need is peer agent interoperability across vendors, A2A is the more natural fit.
Why not just use a chatbot agent mode that browses my website
Browsing is brittle and hard to observe. A2A gives you stable schemas, progress updates, and scoped tokens. You can measure and audit the work and you can swap agents without breaking the client.
How do I keep message contracts boring and explicit over time
Version your capability schemas, keep error codes stable, add a schema_version field to every message, and publish a changelog in the agent card. Avoid magic inference in your contracts. If the client must guess, the contract is not explicit enough.
This is an article inside our system’s transition from phase 2 to phase 3. I’m building this system for paid subscribers. You can upgrade to paid to get all the benefits.
🗞️ Other articles people like
P.S. This may interest you:
Are you in doubt whether the paid version of the newsletter is for you? Discover the benefits here
Could you take one minute to answer a quick, anonymous survey to make me improve this newsletter? Take the survey here
Are you a brand looking to advertise to engaged engineers and leaders? Book your slot now
Give a like ❤️ to this post if you found it useful, and share it with a friend to get referral rewards