Policy quality decays when lifecycle is implicit.

That is true for any control system, but it is especially true for agent governance. If operators cannot answer "which version made this decision?" or "what would have happened under the new draft?", then policy is not really under control.

Lifecycle discipline is the difference between a policy system and a loose collection of rules.

The minimum viable lifecycle

For tool-using agents, policy should move through explicit states:

DRAFT: editable, not enforceable
SNAPSHOT: immutable version prepared for validation
ACTIVE: selected by routing for real traffic
DEPRECATED: retained for replay and audits, excluded from new routing

Those states exist to answer operational questions, not to satisfy process.

A concrete failure mode

Imagine a team governing a bank_transfer tool.

They start with a simple rule: block transfers over $50,000. A week later they add approval for cross-border transfers. Later they tighten production behavior but loosen staging behavior. Then someone "just edits the YAML" to fix a false positive.

If the system has no draft/snapshot/activation discipline, several bad things happen fast:

production may pick up an unreviewed change
operators cannot replay old traces against the new logic
audits cannot reliably tie an incident to a policy version
a rollback becomes "restore something close enough" instead of "re-attach v1.2"

That is governance drift.

What each lifecycle state is for

Draft

Draft is where policy authors iterate. It should be easy to edit and cheap to test, but it should not affect production traffic.

Use draft for:

writing or refining rule logic
tightening scope to reduce blast radius
testing edge cases and expected verdicts

Snapshot

Snapshot is the handoff from authoring to operations. It must be immutable.

Immutability matters because simulation, approval, and incident review depend on stable input. If the meaning of "version 12" can change after validation, the version number is useless.

Active

Active means the routing layer can actually select this version for traffic. Activation should be explicit and recorded.

This is the point where the system needs strong guarantees:

Same input plus same active version should yield the same decision.
Action precedence must hold: BLOCK > REQUIRE_APPROVAL > MODIFY > ALLOW.
Promotion should be reversible without guesswork.

Deprecated

Deprecation is not deletion. Old versions still matter for:

replaying historical traces
understanding prior incidents
proving what the system would have done at a given time

If you delete old versions too aggressively, you lose one of the main reasons to use versioned policy at all.

Design constraints that should not be negotiable

Deterministic routing

The system should not silently auto-load "whatever is latest." Production traffic needs an explicit attachment to a known version.

Side-effect-free replay

Replay should tell you what would have happened, not trigger the original action again. This seems obvious, but it is exactly the kind of detail that turns a useful safety feature into an incident.

Stable precedence

When multiple rules match, the more severe action must win. If precedence changes by path or service, policy behavior becomes impossible to reason about.

Anti-patterns to avoid

silent auto-loading of latest policy in production
missing activation history and audit trail
editable "versions" that are not really immutable
deprecating versions without preserving them for replay
using shadow and active as informal labels instead of explicit routing state

A practical operating loop

The safest lifecycle is boring:

Author in draft.
Snapshot the candidate version.
Validate with simulation and replay.
Attach it in shadow mode.
Promote to active only after reviewing false positives and misses.
Deprecate the previous version, but keep it available for audit.

Teams that skip these steps usually say they are moving faster. In practice they are just moving without memory.

Policy Lifecycle for Tool-Using AI Agents