Agent Withdrawal Criteria

Problem

Nobody plans the exit. Withdrawal reads as defeat, so teams escalate commitment instead: one more prompt fix, one more guardrail, while the agent costs more than the humans it replaced and correction rates climb. Because degradation is gradual, each week's numbers are individually defensible, and criteria negotiated in the middle of a failure are political — the people who would decide have already sunk their credibility into the deployment. The result is a fleet of half-working agents nobody dares to kill and no record of when the case for them stopped holding.

Solution

Define the exit before the entry. Agree measurable bounds on three axes: economics (cost per case above a multiple of the human-equivalent baseline, such as 1.5x), quality (human-correction rate above a bound, such as half of outputs needing rework), and risk (incident classes that halt the agent immediately). Give every deployment an expiry date — a review point at which continued operation must be re-justified rather than assumed. Instrument the measurements from day one so the thresholds are evaluated by pipeline, not by advocacy; when a bound is crossed, record the fact and present it as the basis for a withdrawal proposal. The decision itself stays human and has three designed outcomes: keep with a re-baselined threshold, narrow the agent to the scope where it performs, or withdraw — executed as a staged descent of autonomy and scope, with salvage of what the deployment learned, rather than an overnight unplug.

When to use

• An agent replaces or augments measurable human work, so a cost and quality baseline exists to compare against.
• The deployment is long-lived enough for drift, scope creep, and provider changes to erode its original case.
• The organisation has a governance forum that can own a keep, narrow, or withdraw decision when a breach is recorded.