How do agent-to-agent protocols work?

Agent-to-agent protocols are agreed message formats that let one AI agent find another, hand it a task and get a result back. A typical exchange has four parts: a description of the receiving agent, a task request, status updates and a result. The protocol carries the messages. It does not decide whether anyone may act on them.

What happens in a typical exchange?

Most agent-to-agent protocols follow the same shape, whatever their names.

1. Discovery. The receiving agent publishes a description of itself: its name, the tasks it accepts, the inputs it needs and how to reach it. The calling agent reads this to decide where to send work.
2. Task request. The caller sends a task with an identifier, the inputs and any constraints, such as a deadline.
3. Status updates. The receiver reports progress: accepted, working, needs more input, completed or failed. Long tasks may stream partial results.
4. Result. The receiver returns its output, often with attachments such as a drafted document or a structured finding.
5. Authentication. Each message is tied to an identity, so the receiver knows who asked and the caller knows who answered.

This is the same pattern as any service call, adapted for parties that work in natural language and may take minutes or days to respond. Internally, the same pattern often runs over a work queue rather than direct calls.

What does a protocol not do?

A protocol tells the receiver that a request is well formed and who sent it. It does not tell the receiver whether the sender was allowed to ask, whether the facts in the request are reliable, or whether the receiver should act at its full authority on someone else's say-so.

Those questions belong to the governing layer. Three limits follow:

• A message is a claim. "Customer verified" from another agent is a statement by that agent, resting on facts the receiver cannot see. It should arrive with its source attached.
• Authority does not travel in the message. A request that says "approved by finance" approves nothing. Approval is a filed verdict, not text.
• Capability descriptions are not certificates. An agent saying it can reconcile accounts is advertising. Whether it may do so for this customer is a separate, evidenced question.

What does this look like in practice?

Take a procurement agent at a manufacturer that needs a supplier risk check before raising a purchase order. It reads the risk agent's published description, sees it accepts "supplier risk check" tasks with a company registration number, and sends one with a task id.

The risk agent replies "working", then returns a finding: no adverse media, one director change last quarter, register data attached. The governing layer stamps the finding with the risk agent's identity, its certificate and the sources it used. The procurement agent may now raise the purchase order, because that is within its own depth and limits. Had the finding flagged a sanctions concern, the procurement agent would not decide what to do; the platform would hold the order for a buyer.

The protocol made the exchange possible. The platform decided what happened next. For how an orchestrator should structure these handoffs, see how an orchestrator agent should delegate work.

What may agents do, and what stays with a person?

The last row reflects a broader rule: let reversible work run and make irreversible work wait. A protocol makes it easy to chain agents; it makes it no safer to chain irreversible steps.

What controls make agent-to-agent exchange safe?

• Every exchange passes through the governing layer, which checks the receiver's bounds before it acts on the request.
• Provenance travels with every fact in a result.
• A shared task id links every hop, so the whole exchange can be reconstructed.
• Limits on hops and retries stop agents passing work in circles.
• Agents authenticate with their own identities, never borrowed human credentials.

The wider design is set out in the governed agentic operating system guide.