Every exception is either evidence for a better rule or a leak in the control plane. Treat it like operating debt.
An exception ledger is the operating record of actions that broke the normal rule and the reason they were allowed.
Autonomous workers do not know which exceptions were deliberate strategy, emergency patches, customer politics, or bad habits.
Teams can move fast on edge cases without letting edge cases quietly rewrite the system.
The first override is usually understandable. A top account needs a slightly different onboarding sequence. A partner lead deserves manual routing. A renewal risk needs a softer message than the lifecycle agent would send. A founder asks for a temporary bypass because the launch window is tight.
The second and third overrides are where the system starts learning the wrong thing.
If the reason, owner, and expiry never get written down, the exception becomes invisible training data. Humans remember that it was special. The machine-worker system sees only that the rule was broken and work continued.
Why did the normal rule fail: customer value, missing data, policy gap, brand risk, legal concern, timing pressure, or human relationship context?
Who is accountable for the override and who decides whether it becomes policy, gets retired, or stays manual?
When does this exception die unless someone renews it with evidence?
Which accounts, segments, channels, workers, messages, permissions, or revenue motions can be affected if this precedent spreads?
In a human-only team, unwritten exceptions are annoying. In an agent-run team, they are dangerous.
Agents are good at repeating patterns. That is the point. But if the pattern includes emergency overrides, politically motivated customer handling, or temporary launch hacks, repetition turns local judgment into global behavior.
A growth team thinks it approved one special customer path. Three weeks later, the lifecycle worker is routing similar accounts around the normal qualification gate because the exception looked like success.
Operators rely on Slack threads, CRM notes, and tribal memory to explain why the machine did something outside policy.
Every exception is reviewed as a candidate rule, audit sample, blocker, or deletion. Nothing gets to live forever just because nobody cleaned it up.
Name the exact deviation: skipped qualification, changed sequence, manual owner assignment, pricing language, account suppression, escalation, or enrichment override.
Attach the customer fact, business reason, source conflict, compliance note, or revenue risk that justified the deviation.
Define whether the agent may repeat this case, must ask next time, or is forbidden from generalizing it.
Set the review date. If nobody renews the exception, the default rule wins again.
After review, mark it codified, sampled, rejected, escalated, or deleted.
Do not measure only how many exceptions exist. Measure how long they remain unresolved.
A healthy autonomous org has exceptions, but they move. Some become product rules. Some become prompt constraints. Some become approval thresholds. Some become customer-specific notes with expiry. Most should die.
Exception half-life tells a Head of Growth whether the control plane is learning or merely accumulating operational junk.
A worker repeats a past override without showing why the original situation was different.
Review meetings spend more time reconstructing why something happened than deciding what should happen next.
Temporary exceptions survive across campaigns, owners, segments, and customer states because nobody owns cleanup.
Start where overrides already happen: lead routing, lifecycle messaging, enrichment, discount handling, onboarding, renewal risk, or escalation paths.
Capture the rule that was broken, the reason, owner, evidence, expiry, and whether the agent may repeat it.
Promote repeated exceptions into policy, reject bad precedent, and retire temporary workarounds before agents normalize them.
Track unresolved exceptions by age, owner, workflow, and business impact until the queue trends down.
Before expanding autonomy in one GTM workflow, add an exception ledger beside it.
The blunt rule: autonomous companies do not scale by ignoring edge cases. They scale by turning edge cases into governed learning.