The Orchestrator

An orchestrator’s job is to create a system that can autonomously develop, operate, and improve — the three-part cycle this book keeps returning to — and nothing requires the same system to do all three.

In practice you will often end up tying together several systems, each orchestrating within its own focus area. The development part might be handled by Gas Town: you install it as a product, configure it for your repositories and your review process, and it runs the development cycle with agents that inspect code, propose changes, run tests, open pull requests, and merge work.

The operating part — monitoring live infrastructure, responding to incidents, managing deployments, keeping production healthy — might be an entirely separate set of systems, whether a custom operations platform, an enterprise operations suite, or a consolidation of monitoring tools, alerting systems, and automated response workflows. What makes it work is that it knows how to consume Gas Town’s outputs and feed it inputs: where the code lives, how it was built, what was approved, and how to deploy it. The two remain separate systems talking through shared interfaces, shared state, and shared conventions.

The improvement part — studying outcomes, identifying opportunities, running experiments, bringing recommendations back to people — might be a third project entirely, perhaps a custom system built with a design firm that hooks into customer research, product analytics, and market data. It consumes what development and operations produce, works out what is and is not working, and feeds recommendations back into the development cycle.

So you can easily picture an organization saying: we use Gas Town for development; we use an enterprise operations suite for operations, with hooks into Gas Town’s build artifacts and deployment records; and for improvement we work with a custom system built by a design firm that connects to our customer research platform. Those three things know how to talk to each other, and no single product does all three. Designing the connections, the handoffs, the shared state, and the boundaries between them is the orchestrator’s job.

As the toolkit chapter said, there is no system today that fully lives up to the expectations of a real orchestrator, and the stack sketched above is a design exercise rather than a case study. What is not hypothetical is the work of connecting such systems. Development, operation, and improvement have always been distinct disciplines with distinct toolchains, and what is new is that all three can now involve delegated intelligence, which makes how they connect somebody’s explicit responsibility. The trajectory is clear: these are real systems, and some of what this book describes is happening as of the time of writing. Agent communication has been studied for years, and agent-to-agent messaging protocols exist. What does not exist yet is the standard contract those protocols would need to carry across orchestrators: task-bound authority, budget, evidence, revocation, and accountability that survive a handoff between systems.

That last sentence needs one qualification, and the qualification is instructive. For one kind of work — paying for something — a portable, scoped authority object that crosses a system boundary shipped in 2025, and the reason it shipped there first says what the rest of the field is waiting on.

The clearest case is the Agentic Commerce Protocol, which Stripe and OpenAI published as an open specification in September 2025, with ChatGPT as the first agent platform to implement it. Under ACP the agent platform is not the merchant of record: the business keeps its own payment processor, catalog, and fulfillment, and the agent hands it a scoped token rather than the card. In OpenAI’s delegated-payment specification the token is bound to an allowance — a maximum amount, a currency, a merchant identifier, a checkout session, and an expiry — and cannot be used outside those limits; settlement, refunds, chargebacks, and compliance stay with the merchant.¹ Stripe’s Shared Payment Token is the first conforming implementation: the agent sets usage_limits of currency, max_amount, and expires_at; the seller can charge the token within those bounds until it is consumed, expires, or is revoked; the agent can revoke it before use; and when the token is deactivated for any of those reasons, both seller and agent receive an event saying so, with the reason recorded on the token.² Read that list against the one at the end of the previous paragraph. Principal, scope subset, budget, duration, revocation, and a returned outcome: for a card payment, every field is there.

Google’s Agent Payments Protocol, announced the same month with more than sixty companies attached, takes the same problem from the user’s side. It extends A2A and MCP, and its core object is the mandate, a cryptographically signed record of what the user authorized: an Intent Mandate capturing the constraints a user gave before any specific purchase existed, and a Cart Mandate signed when a specific cart and price are in front of them; when the human is not present, a detailed Intent Mandate pre-authorizes the agent to generate the Cart Mandate once the conditions are met. The protocol’s own documentation states the question it exists to answer: if a fraudulent or incorrect transaction occurs, who is accountable — the user, the agent’s developer, the merchant, the issuer, the payment processor, or the orchestration layer?³ In April 2026 Google donated the protocol to the FIDO Alliance, alongside a Mastercard-co-developed companion, Verifiable Intent, a tamper-evident log of what the user authorized the agent to do.⁴ The card networks moved in parallel: Mastercard’s Agent Pay issues agentic tokens to registered, verified agents under limits the cardholder sets, and Visa’s Trusted Agent Protocol has an approved agent sign every request to a merchant with an HTTP message signature carrying its intent.⁵

Each of these moves authority across a boundary between systems that do not trust each other — agent platform, merchant, processor, network — with an object that is signed, scoped, time-limited, revocable, and logged, so that afterward every party can show what it was permitted to do. That is the delegation object this book has been describing since Chapter 7, and it exists. Three complications keep this from being the happy ending it sounds like. The first is that it exists because money forced it: card networks already had tokenization, dispute rules, chargeback liability, and a long history of law about who pays when an agent buys something the principal did not want, so the bounded object came quickly because the boundaries were already legal facts. The second is that none of it generalizes on its own. A Shared Payment Token says how much may be spent; it says nothing about which repository a development agent may push to, which incident an operations agent may declare, or which recommendation an improvement agent may act on. The replay and confused-deputy problems these protocols solve for a cart are the ones an orchestrator faces for a pull request, and for the pull request there is no network, no issuer, and no dispute process waiting to absorb the loss.

The third complication arrived while this chapter was being written, and it cuts the other way: the object shipped, and the product built on it did not hold. Instant Checkout, the ChatGPT feature that introduced most people to ACP, went live in the autumn of 2025 with US Etsy sellers and a promise of more than a million Shopify merchants to follow. By March 2026 OpenAI had withdrawn it. Its own statement said the initial version “did not offer the level of flexibility that we aspire to provide,” and that merchants would use their own checkout while ChatGPT concentrated on product discovery. The reporting around the withdrawal filled in what the statement left out: a Forrester analyst told CNBC that roughly thirty Shopify merchants had ever gone live; Walmart confirmed it had listed about two hundred thousand products and said purchases completed inside the chat converted at a third of the rate of purchases handed back to its own site; and Walmart’s head of AI acceleration, at an investor conference in early March, called it “a very temporary moment in time.”⁶ ACP itself survived, repurposed as the feed by which Target, Sephora, Nordstrom, Best Buy, and The Home Depot supply catalog data to ChatGPT, and the checkout moved back behind the merchant’s own door — a redirect to the store, or a retailer-built app inside ChatGPT that runs the merchant’s own payments.

Read carefully, the retreat confirms the argument rather than undermining it. The scoped token was never the part that failed. What failed was everything around it that a token cannot carry: product data scraped from web pages and therefore stale on stock and shipping, according to the same analyst; a merchant that, in Etsy’s account, saw the customer only after the sale; and a conversion rate that said shoppers preferred to research in the chat and buy in the store. The merchants took the checkout back because the party that owns the refund, the dispute, and the customer wanted to own the moment of decision too — and an orchestrator should expect that instinct from every receiving system, because an authority object is necessary for a handoff and nowhere near sufficient for one. What I cannot tell you is whether any customer was harmed by an Instant Checkout purchase. I found no reported dispute, and the absence of a report is not evidence of the absence of a problem. Shared Payment Tokens remain a public preview; AP2 is a 0.2 release. The first productized cross-system authority object exists, and as of this writing the flagship product that used it has been folded back into the merchants’ own systems.

So the claim stands, narrowed: authority that survives a handoff exists for payments, because an industry with existing liability had to build it; for general delegated work the protocols carry the task and leave the authority behind.