The fastest way to lose control of autonomous work is to let exceptions quietly become policy.
An exception budget defines how often, how long, and under whose approval autonomous workers may operate outside the normal rule.
Machine workers optimize toward completed work. Without a budget, successful shortcuts become invisible training data for future behavior.
Teams keep speed during weird customer moments without letting edge cases rewrite the control plane.
Every growth team needs escape hatches. A strategic account needs a custom sequence. A renewal needs an unusual discount path. A support crisis needs a nonstandard escalation. A launch needs a temporary suppression rule. The problem is not that machine workers encounter edge cases.
The problem is that autonomous workers are extremely good at repeating whatever worked. If the exception shipped the campaign, cleared the queue, saved the account, or avoided a blocker, the worker has a reason to use it again.
Human teams remember that an exception was political, temporary, and risky. Machines remember that the task completed.
State why normal policy was insufficient: customer commitment, legal constraint, revenue risk, data gap, SLA breach, executive approval, or system outage.
Define allowed count, time window, affected segment, maximum value, customer scope, and which worker may spend the exception.
Name the human accountable for approval, review, renewal, rollback, and deciding whether the exception becomes a real policy change.
Make the exception die automatically unless it is reviewed. No silent extension. No permanent temporary state.
A lifecycle worker gets approval to contact a small customer segment despite a missing field because the launch window is closing. A sales-assist worker is allowed to bypass enrichment for one enterprise account because the AE has context. A routing worker is permitted to escalate low-confidence leads during an outage. A renewal worker uses a temporary discount rule to protect a logo.
Each decision can be correct in isolation. Together, they create a new shadow policy: missing fields are acceptable, low confidence can route, temporary discounts are reusable, and approvals can be inferred from precedent.
That is not autonomy. That is institutional drift with an API.
Success becomes precedent. The system treats completion as approval and turns temporary authority into reusable behavior.
Each abnormal action consumes budget, carries evidence, expires by default, and must be renewed or converted into policy by an owner.
Name the rule being bent: consent, enrichment, discounting, routing, escalation, suppression, data freshness, human review, or customer-contact policy.
Set count, duration, customer scope, ARR exposure, worker identity, and maximum downstream actions before review is mandatory.
Attach approval source, business reason, risk note, affected records, customer sensitivity, and the normal policy that would have blocked the action.
Escalate when the budget is exhausted, repeated across customers, used by a new worker, tied to complaints, or converted into recurring revenue movement.
Expire, renew, roll back, or promote into documented policy. The worst answer is letting the exception stay alive because nobody owns cleanup.
Governance fails when it talks only in permission and denial. Operators need a third state: allowed, but metered.
That is how real companies run. Finance has approval thresholds. Sales has discount bands. Support has escalation tiers. Security has risk acceptance windows. Machine workers need the same operating language because they now perform work that touches customers, revenue, and trust.
The budget gives the Head of Growth a way to say yes without surrendering the control plane.
The same workaround shows up across campaigns, accounts, or queues, but nobody can point to a signed policy change.
Workers cite prior completed actions as permission instead of a current owner, source approval, and active scope.
The launch ended, outage cleared, or customer issue closed, but the machine path still behaves as if the exception remains valid.
Pick one workaround already visible in GTM operations: missing data bypass, special discount, consent ambiguity, manual routing, or review skip.
Define who may approve it, which worker may use it, how many times, for which records, and when it expires.
Log every use with reason, evidence, owner, customer or revenue surface, and whether the action later caused rework or complaints.
At the review point, either promote the exception into documented policy or shut it down. Do not leave it as folklore.
Create an exception budget for one machine-worker workaround that already happens more than once.
The blunt rule: no budget, no repeated exception.