What Is the A2A Protocol? How AI Agents Talk to Each Other

What is the A2A protocol and what does it do?

The A2A (Agent2Agent) protocol is an open communication standard that lets AI agents from different developers and providers discover each other and share tasks. One agent learns what another can do, hands it a job, and gets the result back in a common format. As a result, agents do not need to share the same framework.

In this guide we answer what is the A2A protocol at the concept level. First we look at the core building blocks. Then we cover the difference from MCP, security, and when a business really needs it. We do not push any specific product or version. For current details, check the official A2A documentation.

How can you understand A2A with an everyday analogy?

Picture several specialists from different companies working on one project. Each one is excellent in their own field, but everyone speaks a different language. Without an interpreter, nothing moves, so the project stalls. A2A gives agents that shared language.

Let us make the analogy more concrete. Imagine each specialist carries a business card. The card says who they are, what they do, and how to reach them. Then, when you hand over a job, you get a tracking number and follow the result with it. A2A applies exactly this logic to agents.

There is one more important point. Specifically, you never see inside the specialist's head. You state what you want and receive the outcome. The official documentation calls this opaque execution: agents collaborate without exposing their internal logic, memory, or tools.

Why do agents need a shared language?

Many companies now build their own agents. One answers customer questions, one checks stock, and one prepares invoices. However, each agent may use a different framework, a different provider, and a different message format.

Without a common protocol, you must connect every pair of agents by hand. Three agents mean three links. Ten agents mean forty-five links. Maintenance grows fast. For this reason, every new agent turns into an integration project.

A2A tackles this with a standard interface. If an agent learns to speak A2A once, it can work with every other agent that speaks it. Therefore integration cost does not explode as the number of agents grows.

What is the A2A protocol's Agent Card and how do agents discover each other?

An Agent Card is a JSON metadata document that describes an agent's identity, capabilities, endpoint, skills, and authentication requirements. The official documentation compares it to a digital ID card. Before an agent works with another agent, it reads this card first.

The card also lists the skills the agent offers. For example, a stock agent might list a skill for checking product availability. The client agent reads this and picks the right partner. In addition, the card tells you which authentication method to use.

The exact address and field names of the card can change between versions. So we recommend checking the precise path and fields in the official documentation. Here we explain the concept: in short, discovery starts with a readable card.

In practice, the card works like a shop window. Whatever you write there is what other agents will expect from you. Keep the description honest and specific, because a vague or inflated skill list leads to wrong routing. Moreover, you stay responsible for keeping the card current as the agent changes.

What do task, message, part, and artifact mean in A2A?

Four concepts appear again and again in the official documentation. If you separate them clearly, then the rest of the protocol gets easier. The list below summarizes each concept under its documented name.

• Task: A stateful unit of work that an agent starts. It has a unique ID and a lifecycle, so you can follow long jobs.
• Message: A single turn of communication between a client and an agent. It carries a role, either user or agent.
• Part: The basic content container inside messages and artifacts. It holds text, file data, a file link, or structured JSON.
• Artifact: A tangible output that an agent produces during a task, such as a document, an image, or structured data.

There is also a context identifier, called contextId. The server generates it, so it can group related tasks into one conversation. As a result, state survives across a multi-step job.

For example, a customer might ask about stock and then about delivery time in the same conversation. If both tasks share one context, the agent remembers the first answer when it handles the second question.

How can you summarize the core A2A terms at a glance?

The table below collects the documented concepts in plain language. For example, you can use it in a meeting or a design document. For precise definitions, always go back to the official documentation.

What does opaque execution mean and why does it matter?

The official documentation names opaque execution as a core design principle. It means a remote agent collaborates without sharing its internal memory, tools, or private logic. The client states what it wants. Then it receives the output.

This has two practical benefits. First, you protect your intellectual property. For example, a partner's agent can prepare a quote without ever seeing your pricing rules. Second, the security surface shrinks, because the other side only touches fields defined in the contract.

However, opacity does not mean blind trust. Because you cannot see what the other agent does, checking its output matters even more. Therefore you should plan monitoring and verification from day one.

How does an A2A request move from start to finish?

Let us walk through a simple flow, because a flow makes the concepts concrete. Think of a client agent and a specialized remote agent. The client agent is the application that acts on the user's behalf. Meanwhile, the remote agent is the one that exposes an A2A endpoint.

1. The client agent reads the remote agent's card and learns its skills, address, and authentication requirement.
2. It completes authentication with the standard method that the card declares.
3. It sends a message. While the server processes it, the server creates a task.
4. As the task moves on, status updates arrive. Short jobs return a reply at once, while long jobs use streaming or notifications.
5. When the agent finishes, it sends the artifact. The client agent passes it to the user or feeds it into its own workflow.

The protocol does not invent new technology. It builds on established web technologies such as HTTP, JSON-RPC, and Server-Sent Events. That choice makes it easier to fit your current infrastructure, and your security team works with a familiar surface.

How do streaming and push notifications handle long jobs?

However, not every job ends in seconds. A supplier agent may need minutes to prepare a quote. Also, a task may wait for a human approval, or an agent may compile a large report. A2A handles these cases in two ways.

The first way is streaming. The server sends partial results and status updates over Server-Sent Events while the connection stays open. Push notifications are the second way. The server calls a webhook address that the client defined and delivers important updates on its own.

In other words, the client does not have to poll all the time. Even if the connection drops, the work continues, and you hear back when the result is ready. This helps especially in processes that include human approval.

What is the difference between A2A and MCP?

People mix them up often, because both get called agent protocols. In fact, they work at different layers. As we explain in our MCP guide, MCP connects an agent to tools and data sources. A2A connects an agent to another agent.

The official documentation sums up the relationship this way: MCP gives each agent depth, and A2A gives your system reach. In short, one is vertical and the other is horizontal. Most real systems use both together.

We covered function calling in a separate article, so we will not repeat it here. Put simply, that mechanism lets a model call a function. A2A, on the other hand, lets agents hand work to each other.

What is the A2A protocol next to its neighboring terms?

A2A is not a complete agent system on its own. It gains meaning together with other building blocks. Because every agent builds its own context, managing that well is a separate craft. Our context engineering guide covers that layer.

Also, not every agent needs a huge model behind it. For a narrow task, a small language model can be enough. Which model the remote agent uses does not matter to A2A, because the agent stays opaque and only honors the contract.

For example, MCP handles tool access, RAG handles company knowledge, and guardrails handle safety. A2A replaces none of them. It only standardizes the conversation between agents.

How does a sales agent ask a stock agent in a multi-agent setup?

The example in this section is a fictional scenario, not a real customer result. Imagine an online store with a sales agent that talks to customers. A customer asks whether a certain product can arrive within three days.

The sales agent has no stock data. However, the company runs a separate stock agent that connects to the warehouse system. The sales agent reads the stock agent's card and finds a stock lookup skill. Then it sends a message asking whether the product is available.

The stock agent connects to the warehouse system through MCP and prepares the answer. Then it returns the result as an artifact. Finally, the sales agent tells the customer that the product is in stock and can ship in time.

Three points matter here. First, two different teams may have built the two agents with different frameworks. Second, the stock agent never opens its internal logic. Third, two connection types work together: A2A from agent to agent, and MCP from agent to system.

Who started A2A and how is it governed?

According to the official A2A site, Google originally developed the protocol and then donated it to the Linux Foundation. Today it is an open source project under an Apache license, and a technical steering committee with representatives from several technology companies maintains it.

Governance structures can change over time, so we do not want to list the committee or its foundations as final. Check the current status on the official A2A site. What matters is this: the protocol is an open standard with shared governance, not a closed product of one company.

Also, this has a practical meaning for businesses. An open standard lowers the risk of depending on one vendor. If you replace one of your agents tomorrow, another agent that speaks the same protocol can take its place.

What is the A2A protocol's security model and how does it work?

When agents hand work to each other, security becomes a wider topic than inside a single application. A2A does not invent a new security model. Instead, it relies on standard web security. According to the official documentation, communication runs over HTTPS, and authentication requirements appear in the Agent Card.

Credentials such as OAuth tokens or API keys travel in HTTP headers, separate from the protocol messages. The documentation gives established methods such as OpenID Connect as examples. So the client reads the scheme in the card, gets an access token from the authorization server, and then sends its request.

First, authentication answers the question of who you are. Authorization answers the question of what you may do. You need to design both separately. An authenticated agent is not automatically allowed to do everything.

How do you reduce the risk of an untrusted agent?

Trusting every remote agent is a wrong assumption. That is because the other agent may malfunction, may be compromised, or may return harmful content. Therefore you should treat every output like data from outside.

The principles below give a defense-focused start. They do not guarantee security. They are basic steps that reduce risk.

• Work only with agents you know and have registered, and verify the card information each time.
• Give each agent only the narrowest permission its job needs.
• Treat text from a remote agent as data, never as instructions.
• Add human approval for critical actions such as payments, deletions, or customer data.
• Log which agent sent which request and when.

We covered the risk of outside text acting like instructions in our prompt injection guide. For protective layers, read our guardrails guide. This content is not a legal or security audit, so ask a specialist for critical systems.

You should also test regularly. To build a systematic process that looks for weak spots, see our red teaming article. Run such tests in your own controlled environment with authorized teams.

What design decisions should you make before building a multi-agent system?

Building several agents is an organizational job as much as a technical one. First, each agent needs a single responsibility. Otherwise, finding which agent caused which error gets hard. So first split the work into small, clear parts.

Next, write the contract between agents: which input each one takes, which output it returns, and how fast it should answer. Moreover, this contract must match the skill definitions in the card. If the card and the real behavior drift apart, client agents make wrong decisions.

Finally, think about failure. What happens if the remote agent does not respond? Who notices a wrong output? The answers decide how resilient the system is. In short, drawing the happy path is easy, while designing the failure paths is the real work.

When does your business need A2A?

If you see the signs below, A2A deserves an evaluation. First, several teams or companies build their own agents independently. The agents must hand work to each other. Also, you need to talk securely to a supplier's or partner's agent.

• You have agents written with different frameworks, and wiring them one by one is expensive.
• A partner's agent and your own agent must exchange data.
• Jobs run for a long time and need asynchronous tracking.
• You want to keep the internal logic of your agents hidden from each other.
• You know you will add more agents later and want a shared interface.

In that case, A2A reduces integration chaos. In our guide to AI agents for marketing, we explain how agents fit into a workflow. Multi-agent designs build on that foundation.

How do you set up a small pilot?

Before jumping to a big architecture, run a small and controlled test. Pick two simple agents: one that asks and one that answers. So use a test environment with sample data only, and never touch real customer data.

1. Pick a single job first, for example a product stock lookup.
2. Prepare an Agent Card for the remote agent and describe its skill clearly.
3. Connect the client agent to the card and test it with a simple message.
4. Try wrong answers, timeouts, and unauthorized access on purpose.
5. Record the results and note what worked and what did not.

This test shows whether the protocol fits your needs. It also gives your team a common vocabulary. If the pilot succeeds, you can widen the scope step by step.

When is A2A unnecessary?

Not every project needs A2A. If you have a single agent that only connects to tools, MCP or a simple function call is often enough. An unneeded protocol layer enlarges the error surface and adds maintenance. In other words, the answer to what is the A2A protocol matters as much as knowing when not to use it.

Also, if your agents live in the same codebase, in the same team, and in the same process, an internal function call can be simpler. A protocol creates value for communication that crosses a boundary. Without a boundary, the return stays low.

Here is a practical rule: first, start with one agent and see whether it solves the job. Only when you truly need a second specialist agent should you think about agent-to-agent communication. Do not complicate the architecture before the need appears.

Team structure is another signal. If one team owns all agents, shared code and shared monitoring often suffice. But if each agent has its own owner, its own release schedule, and its own security policy, a standard contract saves you.

What are the advantages and limits of A2A?

Let us start with the advantages, then look at the limits. First, a shared language lowers integration cost. An open standard reduces dependence on one vendor. Opaque execution protects intellectual property. Asynchronous support makes long jobs possible.

As for the limits, the protocol alone does not guarantee trust. You must verify that the other agent works correctly. The standard also keeps evolving, so implementation details can change. In addition, multi-agent systems make debugging harder.

If one link in an agent chain makes a mistake, the error can travel to the next links. For that reason, monitoring, logging, and human approval points should be part of the design from the start. Adding them later costs more.

How do cost, monitoring, and debugging change as agents multiply?

Managing a single agent is easy, so teams often underestimate the later effort. As the number of agents grows, however, tracking each one's version, permissions, and behavior becomes a burden. If different teams update their agents independently, the risk of mismatch grows.

So we recommend keeping an agent inventory. List who owns each agent, which skills it offers, and which agents it talks to. This way, when a problem appears, you know where to look first. Also watch cost: every agent call means using a model and infrastructure behind it. Check current pricing on the providers' official pages.

• Give every task an ID and carry that ID through all logs.
• Record requests, replies, and errors with timestamps.
• Avoid storing personal data in logs without need, and mask it when required.
• Set alert thresholds for unexpected replies.
• Review sample tasks by hand at regular intervals.

In short, good logging is the base of good debugging. If you build this habit during the pilot, you save a lot of time in production.

Which checklist should you use before starting with A2A?

The list below contains questions to discuss with your team before a pilot. If you cannot answer all of them, run a small experiment first.

1. Which job truly needs more than one agent, and why is one agent not enough?
2. Is the responsibility and boundary of each agent written down?
3. Which skills and which authentication method will you declare in the Agent Cards?
4. Do you grant the narrowest permissions, and is there human approval for critical actions?
5. Is there a check step that verifies output from a remote agent?
6. Have you set up a log system that follows requests and tasks?
7. Did you confirm the current protocol version and details in the official documentation?

You can take this list to a decision meeting. For example, the third and fourth items are usually the first questions a security team asks. If you prepare them early, the process speeds up.

What mistakes do teams make most often with the A2A protocol?

• Treating A2A as a replacement for MCP. In fact they work at different layers and work together.
• Continuing to write a custom integration for every agent pair.
• Mixing up authentication and authorization.
• Trusting the output of a remote agent without conditions.
• Building a multi-agent architecture for a job that one agent could solve.
• Assuming details that can change, such as field names or version differences, without checking.

Most of these mistakes come from seeing the protocol as magic. In other words, teams expect it to fix design problems. A2A is a communication standard. You still design the business logic, the security, and the quality yourself.

Where do Talha Aslan and team start with agent projects?

Our team usually starts agent projects from the business problem, not from the protocol, because the problem decides the design. First we discuss which process to automate, which data to use, and what a mistake would cost. Then we set up a small pilot, measure it, and expand.

We collect our AI agent development and integration work on our AI agent development page. For the wider frame, you can also look at our AI automation services. This article is for information. For a design that fits your own system, we need to evaluate your needs together.

One last reminder: protocols, models, and tools change fast. What lasts is a well-defined business problem, a measurable goal, and a safe design. A2A is only one part of that design, but in the right place it is a strong part.