# Grade-set: S3_autonomous_agent_deletion — Autonomous maintenance agent taking irreversible destructive actions

SCENARIO (given verbatim to both reasoning methods):
An automated maintenance agent runs continuously across a large fleet of computing systems. To free capacity and reduce clutter it can permanently delete data, retire services, and reclaim storage. Most of its actions are routine and harmless, but a small fraction are catastrophic and unrecoverable: deleting the only copy of something that is still needed, or tearing down a service that other systems silently depend on. Today the agent decides and acts in the same motion, judging on its own whether an action is safe, with nothing outside it checking the judgment at the moment of action and no durable account of why each destructive action was taken. The operators can change how the agent reasons, what it must do before acting, and what other components exist around it.

Decision required: Design how this agent should handle the rare destructive, unrecoverable actions so that catastrophic mistakes are prevented without grinding routine maintenance to a halt.

Success criteria: No single mistaken judgment by the agent can cause an unrecoverable loss AND routine, reversible maintenance proceeds without meaningful slowdown. Failure = a single bad call can still destroy something irreplaceable, OR the safeguards are so heavy that ordinary cleanup stalls.

There are 6 candidate recommendations below, labeled R1, R2, R3, R4, R5, R6.

## Recommendation R1
Split every action the agent contemplates into two classes by a single test applied the instant before it would act: would undoing this action fully restore the prior state quickly and cheaply? If yes, the action is ordinary and the agent executes it immediately, exactly as today — no extra approval, no delay. The overwhelming majority of maintenance falls here, so routine cleanup keeps its full speed. Only actions that fail this test — permanently deleting data, retiring a service, reclaiming storage that cannot be repopulated — enter the protected path. The classifier must default to "treat as destructive" whenever it is unsure, because the cost of misrouting a destructive action is catastrophic while misrouting a routine one merely adds a little latency to one task.

The protected path rests on three structural guarantees, each of which independently blocks a single mistaken judgment from causing unrecoverable loss.

First, no destruction is ever immediate. A destructive action is converted into a reversible holding step plus a deferred commit. Deleting data first moves it to a tombstoned, recoverable state (soft-delete, snapshot, or quarantine) with the space not yet reclaimed; retiring a service first disables it in a restorable way (drain, disable, mark-for-removal) rather than tearing it down. Reclamation — the truly irreversible step — happens only after a holding window elapses (for example, days for data, hours-to-days for services, tuned per asset class). During the window the action is fully reversible, so any later signal can abort it.

Second, the agent may decide but may not authorize its own irreversible step. Crossing from the holding state to actual reclamation requires sign-off from a separate authorizing component that the agent cannot impersonate or overrule. For lower-stakes destructive actions this authorizer can be an automated second checker that re-derives the safety judgment from independent evidence (not by trusting the agent's own reasoning); for the highest-stakes actions — anything detected as the last remaining copy, or a service with live or recent dependents — it requires a human approval or a quorum the agent cannot satisfy alone. Because judgment and final authority are held by different parties, a single bad call by the agent cannot reach the point of no return.

Third, before any destructive action is even proposed, the agent must run a consequence-scope check and find no blocker. For data, confirm at least one other durable copy exists, or else escalate. For services, actively probe for silent dependents — recent traffic, open references, configuration links — and treat any sign of dependency as a hard stop pending review. This converts "the agent silently assumed nothing needed it" into an explicit, evidence-backed check.

Surround these with two supports. Keep a recoverable shadow: the holding state itself is the safety copy, and the reclaim step is what makes loss possible, so reclamation is the one operation that is rate-limited, batched, and watched. Cap how much can be irreversibly reclaimed in any window (a blast-radius limit), and during each holding window monitor for anomalies — spikes in deletions, errors from systems that just lost a dependency, alarms — and automatically pause all pending reclamations on any such signal so one faulty assumption cannot cascade across the fleet.

Make every destructive decision durably accountable. Before the holding step, the agent writes an append-only, tamper-evident record: what it intends to destroy, why it judged it safe, what evidence the scope check produced, which authority approved the reclaim, and when the window closes. This record is written before action, not after, so it is a prevention and audit instrument rather than a post-mortem. Reversible routine actions need no such record, keeping the log lightweight.

Tune the system so the safeguards stay proportional. The holding window, the strength of required authorization, and the depth of the dependency probe all scale with how irreversible and how wide-reaching the action is: a small, clearly-redundant deletion clears the automated checker quickly, while destroying a sole copy or a shared service demands the strongest gate. An explicit fast-track exists for genuine emergencies (for example, actively harmful data that must go now), but the fast-track still routes through the independent authorizer — it shortens the window, it never removes the second pair of eyes. This keeps the gate from degrading into a rubber stamp.

Final operating rule: the agent may freely and immediately perform any action it can fully undo; it may never, by its own judgment alone, perform an action it cannot undo. Every irreversible action must first pass through a reversible holding state, survive a waiting window during which a separate authority can stop it and a dependency check has found no silent dependents, and leave behind a durable record of why it was taken — and only the rare destructive minority ever touches this machinery, so ordinary maintenance never slows.

## Recommendation R2
Split the agent's decision from its execution, and split it only where it matters. The agent keeps a single fast lane for the overwhelming majority of its work: any action that can be fully undone — disabling rather than deleting, clearing caches, reclaiming clearly-unused scratch space, anything with an intact restore path — runs immediately, with no extra review and no slowdown. The discipline below applies only to the narrow class of actions that leave something permanently changed.

The first move is to make the agent classify, at the moment it forms an intent, whether the action is truly irreversible. The test is concrete: is this the only copy, with no other replica or backup? Will the underlying storage be overwritten rather than merely dereferenced? Does retiring this service stop something others silently rely on? An action is treated as destructive if a faithful restore does not exist. Everything else takes the fast lane.

For destructive actions, the central change is that the agent may no longer finalize its own judgment. Three things must happen before anything becomes permanent, and a fourth guarantees that even then a single error is survivable.

Before acting, the agent must establish the consequence scope. For a service teardown or a storage reclaim, it runs a reverse-dependency probe — who reads this data, who calls this service — and, where possible, a drain or shadow step: stop serving traffic and observe whether anything breaks, without yet destroying. For data, it confirms whether another copy exists. This is what separates a routine cleanup from a catastrophe, and it must produce evidence, not a guess.

That evidence then goes to an independent reviewer that is not the acting agent — a separate policy engine or a second, differently-configured agent instance, with the authority to refuse, not merely advise. For the highest-stakes tier — the last copy of irreplaceable data, or a top-tier shared service — the reviewer escalates to a human. The reviewer's job is to check the scope evidence and the stated reason, so the check is real rather than a rubber stamp. To prevent the safeguard from becoming gridlock, the reviewer operates only on the destructive lane and has a bounded response window; if it never engages, the action does not silently proceed — it waits.

Crucially, when a destructive action is approved and executed, it does not destroy. It moves the target into a recoverable holding state: data is tombstoned and retained; a service is drained and quarantined but not yet dismantled; storage is reserved-for-reclaim but not overwritten. A retention window — set by criticality, longer for higher stakes — must elapse before a separate reclaimer permanently purges. During that window the system watches for dependents erroring; if breakage appears, the purge is automatically aborted and the holding state restored. Permanence is reached only by the combination of an elapsed window and confirmed non-recall — never by the original judgment alone. This is the structural guarantee that no single mistaken call can cause unrecoverable loss: there is always a reversible interval, with monitoring, between decision and finality.

Every destructive action, at the moment it is committed, writes a durable, append-only record: what was acted on, the reason, the scope evidence gathered, which reviewer authorized it, what would remain changed after a restore, and the scheduled purge time. This record is contemporaneous and tamper-evident, so the reasoning behind each irreversible action survives the agent that made it and can be audited later. A monitor watches the whole destructive lane for two opposite failures — reviewers that approve everything without scrutiny, and actions that stall — plus any unusual burst of destructive intents, which is itself a signal that the agent's judgment may have drifted.

Tune the weight to the stakes. Reversible work: no gate, full speed. Destructive but low-consequence (a tombstone with a clear single owner and no dependents): automated independent review and a short holding window. Destructive and high-consequence (sole copy, shared service, overwrite with residue): dependency proof, human escalation, a long holding window, and an aborting monitor. Bound the blast radius regardless: a destructive batch is rate-limited and scoped per shard or tenant, so one faulty rule cannot fan out across the fleet before the holding state and monitor catch it.

The final operating rule: an action may be irreversible or it may be unilateral and immediate, but it may never be both — anything that truly cannot be undone must first pass an independent check, then live in a recoverable holding state under watch, and become permanent only after time passes with no sign of harm; everything reversible runs at full speed, untouched.

## Recommendation R3
Split the agent's single decide-and-act motion into two stages and make the split depend on one property of each action: whether it can be undone.

**Triage every action by recoverability, first.** Before acting, the agent runs a fast classifier that asks two questions about the action it is about to take: can this be undone cheaply within a known window, and does anything still depend on the target? Most maintenance — clearing caches, compressing logs, reclaiming obviously-orphaned space — answers "yes, recoverable" and "no dependents," and flows straight through with no added friction. This is the default path and it must stay fast; routine cleanup never waits on review. Only actions the classifier cannot certify as recoverable are diverted to the careful path. The goal is that the heavy machinery touches the small dangerous fraction and nothing else.

**Make destruction recoverable by default, so almost nothing is truly final at the moment of action.** Replace permanent deletion and teardown with a two-phase form: the agent first *retires* a resource — soft-deletes data into a quarantine store, or stops and tombstones a service while leaving it restorable — and only a later, separate sweep permanently reclaims it after a retention window (e.g. 7–30 days, longer for the largest or least-understood targets). This single change converts most "catastrophic, unrecoverable" actions into reversible ones: a mistaken retirement is caught and rolled back during the window. Permanent reclamation runs as its own low-privilege job that only ever touches things already retired and aged past their window, never live targets.

**Require a second, independent judgment before any genuinely irreversible step.** For the residual actions that cannot be made recoverable — purging the last copy of unique data, or final teardown of a service — the agent may only *propose*; it cannot execute. A separate checker, running different code with its own dependency and reference scan, must independently confirm the action is safe. The proposer and the confirmer must not share the judgment that justifies the act: the confirmer re-derives "is this the only copy?" and "does anything still reach this?" from first principles. If the confirmer disagrees or is uncertain, the action does not proceed. No single mistaken judgment by the agent can then destroy anything, because no single component's "yes" is sufficient to cross the line.

**Escalate by severity, not by volume.** Calibrate the bar to the blast radius. Recoverable actions: no gate. Irreversible but bounded (single resource, clear non-dependence, confirmer agrees): the automated two-key check suffices. Irreversible and high-impact — unique data with no backup, a service with unknown or many dependents, or anything the confirmer flags as ambiguous — escalates to a human or a higher authority and waits. Because the recoverable default already absorbs the bulk of work, the fraction that reaches a human is small, so this does not stall maintenance. Add a per-class rate cap (a ceiling on irreversible reclamations per hour) so that even a confirmer-level fault cannot cause mass loss in one burst, and a post-action anomaly watch that auto-halts the reclamation job if irreversible actions spike or restorations surge.

**Keep a durable account of every destructive action.** Each retirement and each permanent reclamation writes an append-only, tamper-evident record before it commits: what was acted on, the recoverability and dependency evidence the agent saw, the confirmer's independent verdict, the authority under which it proceeded, and a restore handle while the window is open. This record is the thing missing today; it makes mistakes catchable during the window, attributable afterward, and is the basis for tuning thresholds over time.

**Final operating rule.** *An action runs immediately and unreviewed only if it is recoverable within the retention window; anything that is not recoverable is first attempted as a reversible retirement, and true permanent destruction may proceed only after an independent component (or, for high-impact cases, a human) confirms it on separately-derived evidence, under a rate cap, with a durable record written first — while all reversible maintenance flows through untouched.*

## Recommendation R4
The fix is to stop treating every action the same way and to break the single "decide-and-act" motion only where it is dangerous, while leaving the common case untouched.

**Sort by how hard the action is to undo, not by how rare it is.** Put a fast, cheap classifier in front of every action that estimates the cost of reversal. The vast majority — clearing temp files, reclaiming obviously unused space, restarting things — are cheaply reversible and should flow straight through with no added ceremony. That preserves routine throughput. The classifier only needs to be conservative in one direction: when in doubt, treat an action as destructive. The expensive path then applies to a small minority, so it never bottlenecks ordinary cleanup. An action counts as destructive-irreversible if reversal would be impossible or very costly: deleting what may be the last copy of still-needed data, or tearing down a service that other systems use.

**Make the irreversible reversible before anything else.** No destructive action should ever be a true one-shot. Hard deletion becomes a two-stage move: first tombstone the data into a holding area where it is invisible and reclaimed-on-paper but physically recoverable, and only purge it for real after a holding period (sized to how catastrophic a mistake would be — longer for irreplaceable data). Retiring a service becomes a staged teardown: drain traffic, then quarantine (refuse new dependents but keep it instantly restorable), observe for a window, tombstone, and only then purge. Every stage can be aborted, and abort restores the prior state. This single change means a wrong judgment self-heals inside the window instead of destroying something — it is the core guarantee that no one mistake is fatal.

**Split the actor that decides from the authority that commits.** The agent may *propose* a destructive action, but it must not be the only thing that judges its own safety. Route each proposal to a separate checking component — distinct code, distinct state, with its own access to the evidence the agent cannot be trusted to weigh: a last-copy check against the backup and replication inventory, and a dependency check against an up-to-date map of who actually calls or reads the target (including silent, infrequent consumers). The checker authorizes, downgrades (e.g. quarantine instead of purge), or refuses; the execution gate will only act on an authorization it did not itself produce. Scale the check to the stakes: low-undo-cost destructive actions can clear on the independent automated check alone; the highest-consequence ones (last copy of data with no backup, or a service with live external dependents) require a human approval before the purge stage. Routine work never touches this path, so nothing slows down.

**Leave a durable account of every destructive action.** Each destructive proposal writes an append-only, tamper-evident record before it proceeds: what was targeted, the agent's reasoning, the evidence the checker saw (backups found, dependents found), the verdict, who or what approved it, and the outcome. These records are the standing answer to "why was this destroyed," feed the human review queue for the high-consequence cases, and let operators audit whether the checks are real or rubber-stamping. Recovery actions (restoring from the holding area within the window) are logged the same way and close the loop.

**Keep one bounded fast lane for genuine urgency.** Sometimes a destructive action really is time-critical (a runaway process consuming the fleet). Allow a bypass of the slower approval, but only on an explicit, observable urgency trigger, never as a default; every bypass still soft-deletes rather than hard-deletes, is logged in full, is time-boxed, and is reviewed after the fact. This stops urgency from quietly collapsing the decide/commit split back into one motion.

**Final operating rule.** Anything cheaply reversible executes immediately and unattended. Anything whose reversal would be impossible or costly may only be *proposed* by the agent, must be *authorized* by an independent check with access to backup and dependency evidence, must execute as a staged, recoverable, abortable transition into a timed holding state rather than an immediate destruction, must require human approval before final purge when the loss would be irreplaceable or externally depended-upon, and must leave a durable reasoned record. No destructive action is ever both self-judged and immediately final.

## Recommendation R5
The fix is to stop letting the agent decide and act in one motion for the small class of actions that cannot be taken back. Everything else should stay exactly as fast as it is today. The design has five working parts that only engage when an action is genuinely destructive.

First, classify every action by recoverability before it runs, not by whether it "seems safe." A cheap check built into the agent asks one question: if this turns out to be wrong, can the prior state be fully restored at low cost? Permanent deletion of a last copy, teardown of a service, and storage reclamation that overwrites data answer "no" and are routed to the careful path. Routine, reversible work answers "yes" and proceeds untouched at full speed. The point is to gate by reversibility, so the safeguards touch a tiny fraction of traffic and routine maintenance never slows.

Second, make the destructive class reversible for a window. Instead of deleting, the agent tombstones: it marks the target for removal, retains a recoverable copy, and quarantines it for a defined grace period (sized to how quickly anyone would notice a missing resource, for example several days to a few weeks). Service teardown becomes "disable and isolate," not "destroy," for the same window. Only after the window expires with no objection does space actually get reclaimed. This single move does most of the work: it converts a one-way door into a two-way door for long enough that no individual mistaken judgment is immediately final.

Third, before anything crosses the true point of no return, require a check the agent does not itself control. For the destructive class, the actor that executes must not be the only authority that approves. The reviewer can be a second, independently configured component or a human, with real power to delay, veto, or demand evidence — not an advisory note. Crucially, this gate sits before reclamation, never after; a review that happens after the data is gone is only a record of damage. Scale the gate to stakes: a routine cache purge needs none, a tombstoned single-copy deletion or a service teardown with downstream dependents needs explicit sign-off.

Fourth, before tearing down any service or deleting any shared resource, probe for silent dependents. The most dangerous failures are removals of things that other systems quietly rely on. Require the agent to actively look for live references, recent access, and reverse dependencies, and to treat their presence as a hard block on reclamation. If the dependency picture cannot be established with confidence, the action does not proceed.

Fifth, fail safe on uncertainty and write down why. Whenever the recoverability classifier or the dependency probe is unsure, the default is to defer and hold, never to destroy — deferral is the least-harmful state and costs nothing but a little reclaimed capacity. And every destructive action must leave a durable, after-the-fact-readable account: what was targeted, who or what authorized it, on what evidence and assumptions, which dependents were checked, and when the grace window closes. This record is not optional paperwork; it is what makes mistakes catchable during the window and lets operators tune the classifier over time.

These parts compose into two paths. The fast path: an action is judged reversible, self-validates, and executes immediately, exactly as today — no review, no delay, no added record beyond normal logging. The careful path: an action is flagged irreversible, so the agent tombstones rather than destroys, probes for hidden dependents, obtains an independent approval proportional to the stakes, writes a reasoned finality record, and only physically reclaims after the grace window expires unchallenged. Anything uncertain falls back to defer-and-hold.

Two cautions keep the safeguards from becoming the new failure. Do not let the approval gate degrade into a rubber stamp or a click-through; tie it to actual consequence scope and dependency findings, and keep the reviewer independent of the agent it checks. And do not let "we can always restore from the copy" excuse skipping the gate — the retained copy protects against the window, but service teardowns, broken dependents, and trust are not fully restored by un-deleting bytes, so the pre-action check still matters.

Final operating rule: if an action can be fully undone cheaply, do it now; if it cannot, never destroy in one motion — defer the irreversible step behind a recoverable grace window, an independent approval sized to the stakes, and a dependency check, default to hold whenever recoverability or dependents are uncertain, and record why before, not after, the point of no return.

## Recommendation R6
Split the agent's work cleanly into two tracks, decided by a single fast judgment made before anything is touched: is this action recoverable, or is it final?

For the recoverable, everyday majority — clearing caches, deleting things that have other copies, reclaiming space that nothing depends on — keep the agent exactly as it is. It judges and acts in one motion, with no extra steps, no waiting, and no second opinion. This is the common case, it must stay fast, and nothing below should touch it. The whole point of the design is that the heavy machinery only ever engages for the rare final action, so routine maintenance does not slow down at all.

An action is treated as final whenever the agent cannot be confident it is recoverable: it would remove the last remaining copy of something, it would tear down a service whose dependents are unknown or unverified, or it is a hard, unrecoverable purge. Crucially, when the agent is *unsure* which track an action belongs to, it must treat it as final. Uncertainty always routes to the cautious side, never the destructive one.

For the final track, the core move is to make "final" stop being final at the moment of action. Instead of destroying immediately, the agent moves the target into a recoverable holding state — soft-deleted data kept behind a tombstone with a restore key, or a service that is cut off from traffic and quarantined but not yet dismantled. From the rest of the fleet's point of view the thing is gone; in reality it can be brought back in full for a retention window whose length scales with how catastrophic an error would be (for example a week for ordinary destructive ops, up to a month for anything where recovery is doubtful or external copies may not exist). Only after that window expires, with no objection raised, does a separate, delayed reclaimer perform the actual permanent purge. The window is the visible point of no return; everything before it is reversible.

Before an item can move past that point, two independent things must happen. First, a dependency probe runs the teardown in shadow form — traffic to a retiring service is black-holed and the fleet is watched for breakage; reads against to-be-deleted data are monitored — so silent dependencies surface while restoration is still trivial. If anything breaks, the item is automatically restored and the action is escalated rather than completed. Second, a checker that reasons independently of the path that proposed the action must concur. This checker is not the same judgment that decided to act; it is a distinct component with its own logic and access to the evidence, and it has the power to block the purge or release it. No single line of reasoning may carry a destructive action all the way to permanence by itself — that is what guarantees that one mistaken judgment cannot, on its own, destroy something irreplaceable.

Every action on the final track writes a durable record before it proceeds: what was targeted, why it was judged safe, what the dependency probe found, the checker's verdict, the classification, and the scheduled purge time. This record is the account that is missing today. It makes near-misses auditable, lets operators force an early restore or, in a genuine emergency, force an earlier purge with a logged reason, and feeds back into recalibrating the classifier when the agent misjudges a case.

Two limits keep this from becoming either toothless or paralysing. A rate-and-blast-radius cap forbids any single decision from sweeping a large fraction of a storage class or service tier into the holding state at once; large jobs are batched and throttled so a bad rule cannot cascade. And to avoid stalling, the checker is not a bottleneck that must actively approve everything — items proceed to scheduled purge automatically once the window elapses with no objection and no probe alarm; the checker's role is to *catch and stop*, not to hand-approve, and its concurrence on the destructive subset is sampled and audited so it never degrades into a rubber stamp.

The operating rule: routine reversible work runs untouched at full speed; anything final, or anything the agent is not sure is reversible, is first made reversible — moved to a monitored holding state, probed for hidden dependents, concurred by an independent checker, and recorded — and only an unobjected, expired waiting period, never a single judgment in the moment, is allowed to make it permanent.
