The industry has agreed, at last, on one sentence about agentic AI: every agent needs a kill switch. Regulators want one. The governance templates specify one. Settled. And the agreement is worth exactly as much as the answer to a question nobody in the chorus will touch: at what number does yours fire?
The chorus assembled fast this month. On July 1, the Bank of England floated a kill switch for agentic AI in trading: the ability to halt an autonomous system before it does something markets can't undo. The marketing governance guides landing in my feed all summer carry the same section, nearly word for word: technical halt within sixty seconds, complete audit log, rollback plan, human override thresholds calibrated to financial materiality and brand risk. Nate Jones made the smartest version of the argument last week: stop waiting for AI you can trust; executable checks are what made untrustworthy agents useful for five hundred years, and they're what make them delegable now. And Google, as I wrote yesterday, spent July formalizing the other side of the arrangement: automation is now the default contractual state of your ad account.
Concede all of it. The Bank is right. The checklists are right. Nate is right. If a system can act on your budget at machine speed, you need a way to stop it that works in seconds and leaves a record, and nothing in this essay argues against the button.
But notice what every version of the chorus has in common. The switch is specified entirely in engineering terms: how fast it halts, what it logs, who's authorized to press it. Nowhere, not in the regulatory language and not in the templates, does anyone commit to the number at which it fires. A switch is hardware. A condition is a price. Your ad platform has shipped the hardware for twenty years; it's called pause. The thing almost no organization has, the thing none of July's documents supply, is the condition: the threshold, written down in advance, at which a human takes the decision class back.
I owe a debt here, so let me pay it publicly. I've now ended two essays with an ownership card whose final line reads kill condition, and both times I let the phrase do the work of a definition. Who Owns the Decision? said every owned decision class needs one. The Contract Nobody Signed showed what happens while the field stays blank: the platform's answer, an unfunded review duty, becomes your kill condition whether you meant it to or not. Time to fill in the field. A kill condition is the price at which delegation reverses. It is an economic object, not a mechanical one, and that distinction turns out to carry everything that follows.
A switch without a condition fires after the damage
Ask what actually triggers a pause in real accounts today. A screenshot from the CFO. A brand-safety incident that reached a VP's phone before it reached the dashboard. A quarter that came in wrong, noticed at close, litigated in the QBR. The switch exists, and it gets pressed, and every single press is an incident report. The damage is already on the P&L by the time a human reaches for the button, because the button was only ever wired to attention, and attention is the laggiest, most expensive telemetry an organization has.
Finance is instructive here, because finance is the one industry that already prices its breakers. The market-wide circuit breakers on the NYSE aren't a button somebody presses when trading feels bad. They're numbers, published in advance: a 7 percent decline halts trading for fifteen minutes, 13 percent halts it again, 20 percent ends the day. Risk desks run position limits denominated in basis points, checked on every order, enforced by systems that don't ask how anyone feels. So when a Bank of England deputy governor asks for an agentic kill switch, read the request carefully. Finance has buttons everywhere. What a regulator is really asking is whether anyone has written down the number. Marketing is being handed the switch without the price, and most marketing organizations are accepting the deal because the switch photographs well in a governance deck.
What a kill condition actually is
Four properties separate a kill condition from a pause button with paperwork. Each one earns its place.
First: it's set before delegation, or it isn't one. This is the same irreversibility that ran through the proof essay: you can't retrofit a denominator onto a quarter you measured without one, and you can't decide after the exit what should have triggered it. A threshold chosen mid-incident is not a control; it's a settlement, negotiated under duress, by people looking at a chart that's already red. The whole value of the number is that you chose it while you could still be calm about it.
Second: it carries the cost of firing it. Taking a decision class back is not free, and any practitioner who's done it knows the shape of the bill. Pull a Performance Max asset group back toward manual control and expect two to four weeks of degraded delivery while the system's learning resets. That's the real price of the take-back, and I went back and forth on whether it belongs inside the condition or beside it. Inside won, for a simple reason: a threshold that doesn't know its own firing cost isn't a threshold, it's a hope. Price the reset into the trigger and two failure modes become visible at once. A condition that ignores reset cost fires on noise and destroys more value than it protects; call that paranoia with a spreadsheet. And a condition that fires every month isn't vigilance, it's a mis-set threshold. The firing rate is itself telemetry. Note what this property quietly requires: the window matters as much as the number. How long a breach must be sustained before the condition fires is a latency decision. Too short and you're reacting to variance. Too long and you're back to being an incident report.
Third, and the vendors will not volunteer this one: the condition cannot be evaluated by the system it kills. An optimizer that holds its own kill condition is a service grading its own uptime. I made the long version of this argument in the evidence-layer essay: the system that spends and the system that verifies cannot share a brain, or verification becomes a genre of marketing. The kill condition is the sharpest instance of the principle. The predicate has to run in your evidence layer, computed from your first-party numbers, on infrastructure the optimizer doesn't operate. Otherwise you've asked the agent to decide when the agent gets fired, and you already know its answer.
Fourth: it needs a re-entry condition, or it's just quitting slowly. Taking a decision class back is supposed to be a state, not a destination. What must be true to delegate again? The denominator back under threshold for two consecutive weeks. Drift back inside tolerance. An owner willing to sign. The re-entry condition is the field everyone forgets, and it's the one that keeps the whole instrument honest: if you can't say what would convince you to hand the decision back, then your kill condition was never a threshold. It was a grudge.
One line of notation, once, for the readers who want it: a kill condition is a predicate — cost per decision above threshold, or latency above budget, or drift beyond tolerance, sustained for a defined window — evaluated outside the optimizer, with the reset cost priced in and a re-entry condition attached. Everything else in this essay is that sentence, slowed down.
The maximalist objection: "every yank resets the learning"
The strongest pushback comes from the automation side, and it deserves its full weight. It goes like this: kill conditions institutionalize distrust. Every time a human yanks a decision class, learning resets, performance craters, and the yank was probably triggered by variance a human misread as a trend. Google's own guidance says it plainly: let the system learn. The people who make this argument have watched real accounts get wrecked by twitchy hands, and they aren't wrong about the wreckage.
Concede the mechanism entirely; I priced it into the definition two sections ago. Then follow the logic one step further than the maximalist wants to. If firing the switch is expensive, that is the argument for a priced condition, not against one — expensive actions are exactly the ones you don't leave to vibes. A team that can't afford to fire its kill condition doesn't have one. And the maximalist position, stated honestly, isn't "no kill condition." It's a kill condition set to infinity, by whoever set the default. I spent yesterday's essay on what that arrangement costs and who collects. "Leave it alone" is a number too. Someone chose it. It wasn't you.
"Leave it alone" is also a kill condition — set to infinity, by whoever set the default.
The SRE objection: "we solved this in 2010"
The other pushback comes from anyone who's run production software: error budgets, circuit breakers, runbooks, automated rollback. Ops solved this two decades ago, and marketing has just discovered SLOs. Congratulations.
Conceded, gratefully. Steal all of it. Marketing is the last discipline running production systems without error budgets, and the fastest path to a working kill condition is to hire that discipline wholesale: the budget, the burn-rate alert, the blameless review after a firing. But port it with one difference marked in red. An SRE circuit breaker protects availability, denominated in nines, measured by an independent monitor that everyone trusts precisely because it doesn't belong to the service. A marketing kill condition protects a P&L, denominated in dollars per decision, inside a system that also writes its own performance reports. An SLO where the service grades its own uptime would be laughed out of any engineering organization on earth. It is the default state of every ad account in the world. That difference is why this needed an essay and not a link to the Google SRE book.
The card, completed
Here's the ownership card from the last two essays with its final field defined, as this month's Lab instrument. Pick one decision class your systems already run autonomously — a bidding policy, an audience-expansion rule, a creative-selection loop — and fill in every line. The example below is the one I'd start with in most accounts.
Filled in, the card does something quietly radical: it makes delegation reversible on paper before you ever need it to be reversible in fact. Most teams that try it will discover the denominator line is blank because nobody computes cost per decision, and the reset-cost line is blank because nobody has ever priced going back. That discovery is the exercise. You cannot set the threshold until you hold the number, which is why this essay is the third rung of a ladder and not the first.
What this looks like from the CEO chair
Strip the machinery and the question for a leadership team fits in one sentence: for each class of decisions our systems make on their own, what is the number at which a human takes it back, and what does taking it back cost? Silence on the first half means your delegation runs on trust, and trust at machine speed is just latency with better branding. Silence on the second half is worse: it means you've delegated something you can't afford to undelegate, and handing over what you can't retrieve isn't delegation. It's cession. The board will eventually ask which one you did. The kill-condition card is how you'd like to already know the answer.
The chorus is right that agents need kill switches, and the chorus will spend the rest of this year specifying halts and audit logs, and none of it will touch your P&L until someone in your building writes down a number. Reversibility is the price of delegation. Name it before you pay it, because the alternative has already been named for you: a review duty you can't staff, a threshold set to infinity, a default that keeps collecting. The switch was never the hard part. The number is. Write the number.