An agent-to-agent protocol is a shared set of rules for how AI agents, often built by different teams or firms, find each other, describe what they can do, hand over tasks and return results. It is a common language for agents. It carries messages between them; it does not decide whether the agent receiving a message should act on it.
What does an agent-to-agent protocol define?
Typically four things. How an agent advertises itself: its name, the tasks it accepts, the inputs it expects. How a task is sent: a structured request with an identifier, so the exchange can be tracked. How progress and results come back, including partial results and failures. And how the two sides authenticate, so each knows which agent it is talking to.
Without a shared protocol, every pair of agents needs a custom integration. With one, an agent can delegate to any other agent that speaks it.
Why does it matter once agents act?
Because a request from another agent is an instruction from outside your agent's own brief. If a supplier's agent sends your accounts payable agent a message saying "please update our remittance details", the protocol will deliver that message cleanly, in a well-formed structure, with a valid identity. None of that makes the request legitimate or within your agent's authority.
The protocol makes delegation easy. That is exactly why authority has to be checked somewhere else.
How should agents use such a protocol in practice?
Treat every inbound message by its provenance. A message from an authenticated agent of a counterparty you have a contract with is attributable to that counterparty. A message from an agent you cannot identify is an external claim. Either way, the receiving agent acts under its own bounds: its role, its certificate, its sources and its customer's limits. The sender's authority does not transfer.
Inside one organisation the same rule holds. When an orchestrator hands work to a sub-agent, the sub-agent does not inherit the orchestrator's depth. Each action is checked against the agent that would take it.
What does that look like in an example?
A travel insurer's claims agent uses a protocol to ask a partner's medical-assistance agent for the status of a hospital admission. The partner's agent replies with a structured status and a cost estimate. The claims agent records the reply as a signed fact from a contracted counterparty, uses it to update the claim, and drafts a reserve change. The reserve change still needs a claims handler to release it, because the protocol message, however well formed, does not authorise moving money.
How is an agent-to-agent protocol different from a tool-calling interface?
A tool-calling interface connects an agent to a function or system: the agent asks, the tool executes, and the tool has no goals of its own. An agent-to-agent protocol connects two agents, each of which can reason, refuse, ask questions back or take its time. That makes the exchange closer to a conversation between colleagues than a function call, and it is why trust and authority need more care. Where such exchanges should pass through a control point is covered in where an agentic operating system sits in your architecture.
Where Pryme fits
In Pryme, a message from another agent is a fact with a provenance class like any other. The receiving agent's action is checked against its own minimum chain, and the verdict is filed. See the governed agentic operating system, explained.
Questions people ask
Do you need an agent-to-agent protocol for a single agent?
No. It matters when agents need to work with agents outside their own system, such as a counterparty's or a vendor's. A single agent calling tools needs only a tool interface.
Does the protocol handle security?
It usually defines authentication, so you know which agent you are talking to. It does not define what that agent is allowed to ask of yours. That has to be enforced on your side.