A2A vs MCP is not a fight. MCP connects an agent to its own tools and data; A2A lets one agent hand a job to another company's agent. Both protocols were built because a tool call and a delegation to another agent are different kinds of work.
A tool call has fixed inputs and a fixed output and comes back in about a second. A colleague agent takes a goal in words, can take minutes, and can ask a question back. The A2A protocol answers that second case once, for everyone, instead of every pair of companies writing custom code. Google developed the protocol and then handed it to the Linux Foundation, and version 1.0 of the specification was released in March 2026.
What problem does A2A solve that a tool cannot?
A2A is needed when one agent must ask another organization's agent to do something, without handing over its tools.
Take a cinema agent that books seats but needs a restaurant table. Giving it a tool called book table is wrong work in practice. The restaurant does not want to hand its booking tools to every AI on the internet. It wants its own agent to take the job under its own rules on deposits, opening hours and special offers.
Without a shared protocol, every pair of companies answers four questions differently: where the other agent is and what it can do, what format to send, how to hear back on a long job, and where an answer goes when the other side asks a question. With five agents that all talk to each other that is ten pairs, and up to twenty pieces of custom code, one half written by each side. That is the same mess MCP solved for tools.
What are the four steps of every A2A job?
Every A2A job moves through the same four steps: find the other agent, send the goal, answer any question back, receive the result.
- Discovery. The cinema agent sends an ordinary HTTP GET request to a standard address on the restaurant's server whose path ends in
agent-card.json. Most A2A servers publish their card at the same well-known path,/.well-known/agent-card.json. Like a business card at the door. - Hand over the job. The cinema agent sends a message with an ordinary HTTP POST to the address from the card, ending in
message/send, with a token in theAuthorizationheader like any API. Inside sits a message ID, a role, and the parts. Roleusermeans the one who is asking: here that is the cinema agent, not Sara. A part can be text, a file, or structured data, and here it is one sentence: a table for two at six in the evening, before a film nearby. - The question back. The restaurant agent turns the job into a task with an ID and a state. On screen it is task 81, and a context ID groups all tasks from one conversation. The state is
input required, and the agent asks: terrace or inside? Any allergies? The caller's model reads the question, asks Sara, and she says inside, no allergies. The answer goes back as a new message carrying the same task ID, so both sides know it belongs to the same job. - The result. Task 81 moves to
completed, and the result is called an artifact. Here it is structured data: reservation R 2214, at six in the evening, two guests, a table inside. An artifact can also be text or a file, such as a PDF ticket. The cinema agent merges the artifact with the seats it booked through its own tools and answers Sara in one message.
Which parts of A2A carry discovery, messages and results?
The Agent Card, the message and the task are the three units the protocol is built from.
The Agent Card says who an agent is, what it can do, and where to reach it. It lists a name, a description, where to send messages, what the agent supports (for example streaming), how to log in, and its skills. Notice what is not there: no database, no internal tools, no prompts. A skill is written as a name, a description and examples, in words. Compare that with an MCP tool, which carries an input schema such as a showtime ID as text and a number of seats, and every field must be filled in exactly. The specification calls an agent that hides its internals an opaque agent.
The LLM reads skills the same way it reads tool descriptions. The cinema agent's model decides a request is a job for the restaurant agent, but the model does not send the request itself. The cinema agent's code gives it one tool, something like send to agent. The model picks the agent and writes the job in words, then the code sends the A2A message. To the model, another agent looks just like a tool.
A2A defines the same message in three formats: plain JSON over HTTP, plus JSON-RPC and gRPC for systems that already use them. The card says which ones an agent supports. For following a long job there are three options: streaming, where updates arrive while the agent works; push notifications, where the agent calls you back when the state changes; or simply asking for the state of task 81 now. A task is submitted, then the agent is working on it, then it can pause for input or for a login. It ends in one of four ways: completed, failed, canceled, or rejected, when the agent declines the job outright. Rejected looks like this: fully booked tonight. The caller's code then decides whether to tell Sara or ask another restaurant agent.
A2A vs MCP: how do the two protocols differ?
The two protocols differ in what they connect, what you send, how you discover what is possible, and how long the work takes.
| Question | MCP | A2A |
|---|---|---|
| What it connects | An agent to its tools and data | An agent to another agent |
| What you send | Exact inputs to a function | A goal, in a message |
| How you discover what is possible | Ask for the list of tools | Read the Agent Card |
| Can the other side ask back? | A server can ask the user, through the app | The other agent asks back inside the task itself |
| How long it takes | Usually seconds; long jobs need an extra part called tasks | Every job is a task, and it can take hours |
| What the other side shows you | Its tools | Only its skills, with the inside kept private |
The full picture is layered. Sara talks to the cinema agent. Inside, that agent uses MCP to reach its own tools, such as book seats in the cinema's system. A2A is the line between the two agents. The restaurant agent may use MCP again to reach its own booking system, and the cinema never sees those tools. It only sees the card, the task and the result.
What changes when a new partner joins?
A new partner joins by publishing its Agent Card, not by writing new client code on your side.
A taxi company wants in. Without a standard, that means meetings to agree a format, new code in the cinema agent, new code for status updates, then testing and maintenance for every new partner. With A2A, the taxi company publishes its card, the cinema adds its address to the list of agents it trusts, and the messages and tasks are the same as for the restaurant. The cinema agent's model reads the new skill, book a ride, so Sara can say: and a taxi home after the film. Nobody wrote taxi code inside the cinema agent. The same send to agent tool works for the taxi.
Version 1.0 is guided by a committee with people from AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP and ServiceNow, and official libraries mean you do not write the messages by hand. In Python the package is a2a-sdk, installed with pip.
What are the limits of A2A?
The gains come with three real costs: trust, spend, and the temptation to use it where a tool would do.
- Trust. Which agents are you allowed to call, and what data may you send them? Sara's name and phone number go to another company. Decide that carefully before the first message is sent.
- Cost and speed. Two language models now work on one request. That costs more and it is slower than a plain tool call.
- Simplicity. If a plain tool can do the job, use the tool. Use A2A when the other side really needs to think, ask back, or keep its inside private.
FAQ
- Where does an agent find another agent's skills? In its Agent Card, normally served at the well-known path /.well-known/agent-card.json. The card lists the agent's name, description, endpoint, login method and skills in words, not its internal tools or data.
- When a task waits for a question to be answered, what state is it in? The state is input required, and the job is paused rather than failed. The caller sends a new message with the same task ID, and the task resumes.
- Does the calling agent see the other agent's tools? No. The calling agent sees skills on the Agent Card, then task states and an artifact. Tools, prompts and data stay inside the other organization, which the specification calls an opaque agent.
- Is A2A a replacement for MCP? No. MCP connects an agent to its own tools and data, while A2A connects an agent to another agent. A typical multi-company flow uses MCP inside each agent and A2A between them.
- When should you keep a plain tool call instead of delegating to another agent? When the job has fixed inputs, returns quickly, and needs no follow-up question. Delegation earns its cost when the other side must reason, ask back, or keep its implementation private.
From one video to a written explanation
Explaining a protocol well means keeping the four-step job, the diagram and the trust caveat in the right order. If you have already recorded that explanation, the work of writing it again is mostly mechanical, and the argument is already settled in your head.
Skalablog takes a YouTube URL, transcribes the video, and generates a structured article draft you can review and edit before publishing. Gustavo dev doido builds long technical walkthroughs in the same spirit, and the useful part of any such video is the reasoning between the steps. Turning that reasoning into prose is what a transcript-to-article pass is for.
Put the words you already said into writing
The protocol only works because the cinema agent describes a goal in words and lets the other agent work out the rest. Your own explanations work the same way: the value sits in how you phrase the handover. If that reasoning already exists in a recorded walkthrough, it does not need to be spoken twice.
Start with the Skala Blog, paste a YouTube URL, and Skalablog will transcribe the video and generate an article you can edit into your own voice.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits