3.6 What to build before the protocol arrives
The temptation, when the standards are this visibly unfinished, is to wait. The payments case argues against it: when a protocol does arrive it arrives with a fixed shape — a signed, scoped, expiring, revocable object with a returned outcome — and the systems that adopt it fastest are the ones already recording those fields under their own names. So the work now is not to guess the wire format. It is to make sure that for every action one of your systems takes on another’s instruction, your operating record can produce the tuple: principal, scope subset, budget, duration, revocation path, evidence returned, owner of the outcome. If it can, the protocol, when it comes, is a serialization. If it cannot, no protocol will fix it, because the protocol will carry whatever you give it. Two tests tell you whether you are there. The first is Chapter 16’s sequence — start with one outcome, join the records — run across a boundary: if joining both systems’ operating records for one consequential outcome needs a human to read two logs and guess, the tuple is not being recorded. The second is the refusal test: send a system a task under a handoff whose scope is wider than the principal’s own grant, and see whether it refuses. A system that accepts will do the same for an attacker.
What remains open is not technical, and I would rather leave it open than pretend otherwise. In payments, somebody certifies the handoff: the network registers the agent, the issuer stands behind the token, the FIDO Alliance owns the mandate format, and a dispute process exists for when the object was wrong. For general delegated work there is no equivalent institution. Nobody certifies that the development system’s handoff to the operations system was within the principal’s authority, and nobody adjudicates when it was not, except the company that deployed both — which, after Moffatt, is the party that pays, and whose named principal, if the Ninth Circuit’s reasoning travels, is the person the act is attributed to. Chapter 12 argued that the orchestrator’s profession needs a credential; the cross-system case argues that the handoff itself needs one, and it is not obvious whether the body that issues it will be a foundation, a standards body, a regulator, or an insurer. Until one of them does, the file above and the record behind it are the certificate, and the person who signs the owner_of_outcome line is the certifying authority. The question to carry out of this chapter is which of those four institutions your organization would rather answer to — and whether your records could show any of them what your systems did.
HQ 6 — Assembled. The human and AI each wrote portions of this chapter. I assembled, reviewed, and take responsibility for the whole; the voice and arguments are mine, and I know which parts are which.
- 3.1 Orchestration across systems
- 3.2 The agent-to-agent protocol
- 3.3 Identity crosses the boundary; authority does not
- 3.4 Cascade authority
- 3.5 What not to connect yet
- 3.6 What to build before the protocol arrives