Capability

Agent protocols & orchestration

The plumbing that decides whether multi-agent work is reliable or merely impressive.

The problem

A demo needs one agent to succeed once. Production needs many agents to fail safely, repeatedly, in a system where something else is already depending on the result. Almost everything hard about that is protocol: how an agent is addressed, what a call carries with it, what happens when a step half-completes, and whether the control path can be told apart from the data path at all. Teams reach for orchestration frameworks and inherit whatever assumptions those frameworks made — usually that every caller is trusted and every step is idempotent, neither of which survives an enterprise.

Where it breaks

01

Identity in the call

Most agent-to-agent calls carry a task and not an actor. The receiving side then has no way to decide whether this caller may ask for this thing — so it does it, and the authority question becomes unanswerable after the fact.

02

Control and data on one path

When instructions and content travel the same channel, retrieved content can be read as instruction. Every prompt-injection result follows from this one design decision, and no amount of filtering repairs it.

03

Partial completion

An agent that books, charges and confirms has three chances to stop halfway. Frameworks retry; systems of record do not deduplicate. The second charge is not a model failure.

04

Fan-out without budget

One agent calling three that each call three is a load pattern nobody sized for, and the failure arrives as a timeout in an unrelated system.

05

Version drift across agents

Two agents built six weeks apart against the same tool disagree about its contract. Neither is wrong; nothing tests the pair.

06

No provenance on the hop

By the third hop nothing carries where the request originated. Reconstruction stops at the boundary of whichever component logged best.

What this actually consists of

01

Protocol design for agent-to-agent and agent-to-tool calls, carrying actor and authority rather than task alone

02

Separation of the control path from the data path so retrieved content cannot become instruction

03

Failure semantics — idempotency keys, compensation, and what a half-completed action means in your systems of record

04

Orchestration topology: which work is a graph, which is a queue, and which should never have been an agent

05

Propagating provenance across hops so a reconstruction does not end at a component boundary

The test

The test is not whether the happy path runs. It is whether you can take one completed multi-agent action, name every hop, say which actor authorized each, and show what would have happened had step three failed.

Standards and regimes named on this page are checked against their primary sources on an ongoing basis. Instruments move — several cited here changed inside the last year — so verify against the source before you rely on one. If you find something stale, tell me and I will correct it.

Next step

Where does this sit in your estate?

The useful version of this conversation is specific — one workflow, one deadline, one thing you are not sure you could evidence. That is usually twenty minutes.