The Orchestrator

You can see a point at which we start attaching entire ecosystems to one another, and that is where the questions get interesting. When a decision flows from one orchestrated system to another, does system one have authority to tell system two what to do? What is system two responsible for? If system two acts on system one’s instruction, who owns the consequence? Attach enough ecosystems and you have cascade authority — decisions flowing across system boundaries with real effects, and no protocol that carries permission alongside the task. The Hermes refusal was the small version of this. Concepts of delegated authority are going to become immediate even though many people reading this have no experience of it yet. And it will not stop at agents having arguments with each other. Whole orchestration systems are going to start disagreeing about basic assumptions.

The disagreements will be about facts before they are about philosophy. When a development system’s agent opens a pull request and an operations system’s agent deploys it, and the deployment takes down checkout, which system’s operating record holds the decision? When an improvement system recommends a pricing change, the development system implements it, and the operations system rolls it out, who approved the price? Each system will answer with its own logs, its own authority model, and its own owner, and the answers will not join.

The law has already given part of the answer, and it is not the part engineers expect. In Moffatt v. Air Canada, discussed in Chapter 4, the airline argued that its chatbot was a separate legal entity responsible for its own actions, and the tribunal rejected the argument: the company owns what its agent said.¹⁴ Nothing in that decision depends on how many systems sat between the company and the customer. The framework behind it is the ordinary one of principal and agent, and it belongs here as analogy rather than legal advice: a principal who authorizes an agent is bound by acts within the authority granted, and often by acts a reasonable counterparty would have believed were authorized. Read across a cascade, system two acting on system one’s instruction is, to the customer, still the company acting. The company that deployed the chain owns the consequence whether or not it can reconstruct which link produced it, and the company that cannot reconstruct the link is in the worse position, because it owns the outcome and cannot explain it.

A second court has now answered the mirror-image question — not who owns what an agent said, but who is acting when an agent crosses into somebody else’s system — and it should be read alongside Moffatt, because together they bracket the cascade. Amazon sued Perplexity in November 2025 over Comet, a browser whose optional assistant shops on Amazon.com at a user’s direction, taking screenshots of the page, sending them to Perplexity’s servers, and receiving instructions back on how to navigate. Amazon had told Perplexity twice that its agents were not permitted in the store, and at the center of the dispute was Perplexity’s decision not to send a user-agent string that would have let Amazon recognize and block the assistant. A district judge granted a preliminary injunction under the Computer Fraud and Abuse Act. On August 4, 2026 the Ninth Circuit vacated it. “However advanced the Assistant currently is,” the panel wrote, “it is a tool, not a person for statutory purposes,” and on the record before it “it is the user who ‘accesses’ Amazon’s computers, with the help of the Assistant.” The court was careful about what it had not decided: it did not “establish a new legal regime governing agentic AI,” it left tort liability open, and it noted that Amazon remains free to police access through its terms of service.¹⁵ The case is unfinished — it went back to the district court — and one appellate ruling on one statute’s word access is not a doctrine.

What the two decisions share matters more than what separates them. In both, the court looked through the agent to a principal capable of being bound and attached the act there: Air Canada for what its chatbot said, the Comet user for what the assistant did on Amazon. In neither did the machine in the middle acquire responsibility of its own, and where the vendor’s liability was raised at all, the vendor was not the party held — the Ninth Circuit found that Perplexity was not the one accessing Amazon, at least not on that record and not under that statute. Now run the same logic down a cascade. An improvement system recommends, a development system implements, an operations system deploys, and each hop is “a tool, not a person.” The law’s instinct is to keep looking through tools until it finds a person entitled to be bound, which means the principal of a three-hop cascade is whoever a court can identify at the top of it. If the top of it is a release manager who approved a pull request and never saw the deployment, that is where the consequence lands. The company that deployed the chain owns the outcome, and the person who signed the first grant is the one whose authority every later hop will be said to have exercised. A cascade that cannot show which grant each hop was acting under does not protect that person. It exposes them, because the only record that exists will show their name at the top and nothing underneath it.

European law has started to write the cascade into statute, and its current state needs stating carefully, because it changed this summer. The AI Act separates the provider of a high-risk system, who builds it and carries the conformity obligations, from the deployer, who uses it under its own authority and must follow the instructions for use, assign competent human oversight, and keep the logs. Article 25 is where the cascade lives: a deployer becomes a provider, with a provider’s obligations, if it puts its name on a high-risk system, substantially modifies it, or changes its intended purpose so that it becomes high-risk.¹⁶ An organization that takes a vendor’s development system, wires it to its own operations system, and puts the assembly in front of customers should read that article twice. The Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force on July 27, 2026, six days before the high-risk obligations were due to apply, and deferred them: Annex III standalone systems to December 2, 2027, Annex I embedded systems to August 2, 2028, while the Act’s general application date of August 2, 2026 stands for the rest. The same regulation sharpened Article 25: when a deployer becomes the new provider, the original provider must cooperate, hand over technical documentation, and inform the new provider “about known limitations and failure modes.”¹⁷ The upstream system owes the downstream system its failure modes. That is a cascade-authority clause written by legislators, and it is the first one I know of.

None of that tells an orchestrator what to write down tomorrow. The law says who owns the consequence; it does not say what the handoff should contain so that ownership can be exercised. Chapter 7 gave the delegation contract inside one system. This is the fragment I attach to a handoff between systems, in the same style, when no protocol will carry it for me:

# handoff/ops-deploy-2026-09-04.yaml
from_system: dev-orchestrator
to_system: ops-orchestrator
principal: [email protected]
principal_grant: delegation/[email protected]
task_ref: dev/pr/4821
scope:
  may:
    - deploy order-service to staging
    - run smoke suite smoke/order-service
    - promote to production if smoke passes and error budget > 20%
  may_not:
    - change routing rules
    - deploy any other service
    - re-delegate this task to a third system
budget:
  max_model_spend_usd: 40
  max_wall_clock_minutes: 90
valid_until: 2026-09-04T18:00:00Z
revocation:
  channel: ops-orchestrator/api/handoffs/{id}/revoke
  on_revoke: halt, roll back to previous release, report state
evidence_required:
  - trace_id joined to dev/pr/4821
  - deploy SHA and time
  - smoke results with links
  - who or what approved production promotion
  - final state (staging | production | rolled_back)
owner_of_outcome: [email protected]

Everything in that file already exists somewhere in the two systems; its only job is to put it in one place both systems can read and both operating records can attach. It decides the principal, so a downstream refusal like the one in Chapter 16 has something to check against. It decides the scope as a subset of the principal’s own grant, so the handoff can only narrow. It decides budget and duration, so an abandoned task expires instead of lingering with live credentials. It names the revocation path, what must come back so the two records can be joined without archaeology, and the owner of the outcome, because the law will anyway. What it does not decide is how the receiving system does the work, whether the receiving system will honor the file — that is its policy engine’s job, per Chapter 7 — or what happens when the receiver delegates again to a third. The may_not: re-delegate line is the limit of what a file can do about cascades; the moment you allow re-delegation, you need the attenuation chain the IETF drafts describe and a verifier at every hop.

Set that file against what is actually shipping and the ledger is specific. My claim is that most of its lines exist in some specification and none of them exist in one. task_ref and the final state are A2A: a task with an identifier, a lifecycle, and a terminal state the caller can read, and in the 1.0 specification a chain of tasks can pause in AUTH_REQUIRED while a credential is fetched from the far end of the chain. principal, scope.may, budget, and valid_until are AP2’s mandate for a purchase — a signed record of what the user authorized, with a ceiling, a window, and conditions — and, in narrower form, a Shared Payment Token’s usage_limits. scope.may_not is an OAuth scope stated in the negative, and the rule that a downstream grant may only narrow is RFC 8693’s token exchange as Chapter 7 described it, made mandatory in the IETF attenuation draft. So far the ledger is encouraging. The complication is which lines have no home. revocation.channel exists inside one system’s API and nowhere across two: Stripe can revoke a token it issued, and an A2A client can ask for a task to be cancelled — the specification adds that “success is not guaranteed” — but no specification lets a principal reach across an organizational boundary and withdraw authority a second system is currently acting on, still less authority a third has inherited from the second. on_revoke: halt, roll back, report state — a stop condition that survives a hop — appears in no protocol at all; cancel says stop working, not what safe state to leave the world in. evidence_required is the field the payments industry answers with a dispute process and everyone else answers with archaeology: A2A returns artifacts, but nothing obliges the receiving system to return the specific evidence the principal named, joined to the principal’s identifiers. And owner_of_outcome is the line no protocol will ever carry, because the courts fill it in. The pattern in that ledger is the point for a practitioner: the fields a protocol can carry are the ones that help the sender complete the task, and the fields no protocol carries are the ones that protect the principal — and in a cascade you built, the principal is you.