Reversibility

Every change an agent produces must be cheap to undo. Agents multiply the volume of change entering the system, and no verification loop catches everything, so the cost of being wrong is governed by the cost of recovery. A team that can revert any change in minutes can afford to delegate aggressively; a team whose changes are entangled, unflagged, or irreversible must inspect everything before it ships — which caps agentic throughput at human review speed.

Reversibility is what Observability is for: detection without recovery just produces well-documented incidents. Together they close the post-merge loop — observability tells you a change was wrong, reversibility makes being wrong survivable.

What It Looks Like in Practice

Changes are small and atomic, so a revert removes one behavior instead of unraveling a week of entangled work. Risky behavior ships behind feature flags that can be turned off without a deploy. Database migrations are written with their rollback, and deployments have a tested path back to the previous version. Irreversible actions — data deletion, external API calls, published messages — are isolated behind explicit boundaries so everything around them stays reversible.

Grounding Principles

This pillar operationalizes The Principle of Reversal Asymmetry — generation is cheap, but reversal cost grows with time and dependents — together with The Principle of Asymmetric Risk, The Principle of Atomic Debt Containment, and The Corollary of Side-Effect Predictability Gates.

Failure Mode

An agent-produced change passes tests and review, then misbehaves under real traffic three days later. By then, four other changes have been built on top of it, the migration it included cannot be rolled back, and there is no flag to disable the behavior. A five-minute mistake becomes a two-day incident — not because detection failed, but because recovery was never designed.