The agent-to-agent (A2A) protocol is an open protocol for communication and collaboration between independent AI agents, allowing them to discover capabilities, exchange messages, delegate tasks and receive results without requiring access to one another’s internal state or tools.
Google announced A2A in April 2025 with more than fifty technology partners, and in June 2025 it became a Linux Foundation project. IBM’s Agent Communication Protocol has since joined it. The problem it addresses is simple to state: agents built by different teams, on different frameworks, often by different companies, need a common way to find each other and hand work across. A2A’s answer is to treat each agent as a service with a published description, and to let agents exchange tasks without exposing how they do them.
How A2A works
- Agent Card. Each A2A server publishes a JSON description of itself, by convention at
/.well-known/agent-card.json: its identity, endpoint, skills, capabilities and the authentication it requires. An authenticated client may be shown a more detailed version of the card. - Tasks. Work is exchanged as tasks with a defined lifecycle: submitted, working, completed, failed, canceled, rejected, and two states in which the remote agent pauses to ask for more, input required and authentication required.
- Messages and artifacts. Agents exchange messages made of parts, such as text, files or structured data, and the remote agent returns its results as artifacts.
- Transport. The specification defines bindings for JSON-RPC, gRPC and HTTP with JSON, with streaming and push notifications for long tasks.
- Security schemes. The Agent Card declares how callers authenticate: API keys, HTTP authentication, OAuth 2.0, OpenID Connect or mutual TLS. Servers must perform authorization checks on every request.
A2A and MCP
The two protocols are often compared, and the A2A project describes them as complementary: MCP is vertical, connecting an agent to its tools and data, and A2A is horizontal, connecting agents to each other. In MCP, the caller sees the tools it is calling and the arguments it sends. In A2A, the caller sees a peer that accepts a task and returns a result. An agent can use both at once: A2A to delegate a task to a specialist, which uses MCP to reach the tools it needs.
Opacity moves governance to the boundary
A2A’s defining choice is that agents collaborate without access to each other’s internal state, memory or tools. That is deliberate, and it is what makes collaboration between organizations possible: neither side has to expose its internals. It also means the delegating agent cannot see how its task is performed. Whatever governance the delegator applies has to happen at the two places it can see: what it sends, and what comes back.
Three consequences follow.
An Agent Card is a claim, not evidence. The card is the remote agent describing itself. The specification allows cards to be signed with JSON Web Signature, and recommends that clients verify a signature before trusting a card. A signature proves who made the claim and that it was not altered. It does not prove that the skills listed are accurate, and signing is optional. Capabilities in a card are assertions to be checked against results.
Delegating work is not delegating authority, but the two travel closer together than they appear. A2A delegates work: the remote agent performs the task under its own identity and its operator’s policies. Authority is delegated explicitly only when the delegator hands over credentials or tokens, for example in answer to an authentication-required request. Even without that, a task sent across the boundary carries context and data to a party whose policies the delegator cannot see, and the input-required and authentication-required states mean the remote agent can come back mid-task and ask for more. What the delegating side should send, to which agents, for which purpose, and whether it should ever pass on its own credentials, is a scope decision that has to be made before the message leaves.
The protocol records the exchange, not the execution. A task’s history holds the messages exchanged, and its artifacts hold the results. What the remote agent did to produce them, which tools it called and which other agents it delegated to stays with the remote agent’s operator. The specification asks each server to log its own security-relevant events; it does not define a shared trail across the boundary. Evidence of delegated work therefore has to be kept on each side.
An example
A procurement agent delegates “find three qualified suppliers for 10,000 units of part X” to a sourcing agent run by a partner, discovered through its Agent Card. To make the task useful, it includes the company’s target price and its current supplier’s contract terms. The sourcing agent returns three suppliers. The procurement team later learns that the sourcing agent shared the target price with candidate suppliers to speed up quotes. Nothing in the A2A exchange was malformed, and nothing in the procurement agent’s record of the exchange shows what happened on the other side. The decision that mattered was on the delegating side: whether the target price and contract terms should have left at all.
Where Sentience fits
Sentience Governor, the free, open-source runtime governance library, does not have an A2A integration, and nothing here implies one. The governance this entry describes still applies on the delegating side, which is where Governor works: a session declares what it is for and which systems it may reach, as its declared scope, and where an agent’s outbound calls pass through an integration Governor instruments, those calls are recorded and compared with that scope, building governance evidence of what was sent where. Governor records and flags; it does not stop a call.
Deciding which external agents an agent may reach at all is an environment question. Sentience Secure Runtime runs agents in isolated execution environments with controlled egress and policy enforcement, so the set of endpoints an agent can reach, and therefore the external agents it can delegate to, is decided by the environment rather than by the agent’s judgment in the moment. Egress control governs where traffic may go; what a task is allowed to carry is a separate policy decision on the delegating side.
Often confused with
The Model Context Protocol. MCP connects an agent to tools and data it can see and call. A2A connects an agent to another agent whose internals it cannot see.
An MCP server. An MCP server exposes tools for an agent to use. An A2A server is itself an agent that accepts tasks.
Agent orchestration. Orchestration decides who does what within a system. A2A is one transport for handing work to agents, often across system or organizational boundaries.
Where the concept stops
A2A standardizes how agents find each other, exchange tasks and return results across a boundary. It does not establish that a remote agent can do what its card says, what it did with the context it was given, or whether the task should have been delegated with that data in the first place. Those depend on decisions and evidence on each side of the boundary, which the protocol deliberately leaves to the agents’ operators.