Your AI Agent Changed Its Config. Can You Roll It Back Safely?

A developer outlines a rollout control plane that makes AI agent configuration changes reversible, addressing the risk that a config revision can alter tool permissions, model routing, or approval rules while work is in flight. The approach uses immutable revisions, staged promotion with canary probes, dispatch fences, and compatibility checks to ensure rollbacks are safe and side effects are bounded.

A configuration change can be more dangerous than a code deploy when an AI agent can send messages, edit repositories, spend money, or operate a browser. The usual rollback advice is simple: keep the old file and copy it back. That is not enough for an agent. A configuration revision can change tool permissions, model routing, retry behavior, queue limits, browser profiles, or approval rules while work is already in flight. Restoring the old file does not undo a side effect, and it may make a previously recorded intent impossible to reconcile. This post describes a small rollout control plane that makes agent configuration changes reversible without pretending rollback is magic. Never mutate the active configuration in place. Store each revision with its content digest, schema version, creator, reason, and validation result. revision: cfg-2026-08-10-0042 sha256: ... schema: 3 parent: cfg-2026-08-09-0039 created by: operator@example.com status: validated The running agent should hold a revision ID, not just a parsed object. Every run, tool call, approval, and side-effect intent should record that ID. When an incident starts, you want to answer “which policy authorized this?” without reconstructing it from logs. A revision is eligible for promotion only after deterministic checks pass: A green validation result does not mean the revision is safe for every running job. Promote in stages: The canary should run a fixed probe, not a vague “try it out” task. Use a fixture repository, fake credentials, a mock browser, and a fake external API that records requests without applying them. Assert the tool name, normalized arguments, policy decision, revision ID, and expected side-effect class. For a browser or OpenClaw deployment, the probe should also verify that the worker has the intended profile, workspace, network policy, and durable state path. A config that parses successfully but points at yesterday’s browser profile is not a successful rollout. The most important check happens after planning and immediately before dispatch. Re-read the active revision and authorization policy. Do not let a long-running agent execute a plan created under a revision that has been revoked. A useful dispatch record looks like this: intent id=it 8f2 run id=run 42 config revision=cfg-2026-08-10-0042 policy revision=policy-91 request key=repo:acme/app:issue:184:close side effect=WRITE state=AUTHORIZED At dispatch, compare the recorded revision and request key with the current policy. If they differ, mark the intent STALE, do not send it, and require replanning. This is the configuration equivalent of a compare-and-swap guard. For mutations, persist the intent before sending. After a crash, reconcile the request key with the provider before retrying. Use explicit outcomes such as NOT SENT, SUCCEEDED, FAILED, and UNKNOWN; do not turn UNKNOWN into an automatic retry just because the configuration was rolled back. A rollback can be incompatible with state produced by the newer revision. Before promotion, record a compatibility contract: If revision 8 writes state that revision 7 cannot read, “activate revision 7” is not a safe rollback. Use a compatibility bridge, drain the affected work, or restore the state snapshot that revision 7 expects. The control plane should reject an unsafe rollback rather than handing it to the agent and hoping for recovery. Create a disposable test matrix and inject failures at each boundary: The expected result is not always “the task succeeds.” It may be BLOCKED, STALE, UNKNOWN, or REPLAN REQUIRED. Those are useful outcomes because they stop an operator from confusing a configuration rollback with reversal of an external side effect. Before promoting a revision: The goal is not zero configuration mistakes. The goal is to make a mistake bounded, visible, and recoverable. Immutable revisions, staged promotion, dispatch fences, and compatibility checks give an agent runtime a safer answer than “copy the old YAML back and see what happens.” If you build agent systems, follow for practical control-plane patterns that make automation safer after the demo.