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

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.

Treat configuration as an immutable revision

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: [e-mail]
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:

• schema and default-value validation
• tool and credential references resolve
• allowed destinations are within policy
• model and tokenizer settings fit the context budget
• queue, timeout, and retry values are within operator limits
• the configuration can be loaded by the exact runtime version

Separate validation from promotion

A green validation result does not mean the revision is safe for every running job. Promote in stages:

1. Candidate: stored but unused.
2. Canary: assigned to a disposable worker or a narrow tenant/workspace.
3. Active: eligible for new work.
4. Draining: no new work, but existing work may finish.
5. Retired: unavailable for new leases but retained for audit and reconciliation.

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.

Fence side effects at dispatch time

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.

Rollback is a forward migration too

A rollback can be incompatible with state produced by the newer revision. Before promotion, record a compatibility contract:

• state schema versions the revision can read
• queued work formats it can safely resume
• credentials and tool scopes it expects
• browser profile or workspace migrations it requires
• whether in-flight plans must drain, cancel, or be replanned

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.

Test the failures, not just the happy path

Create a disposable test matrix and inject failures at each boundary:

• candidate validates but canary cannot load a referenced tool
• promotion races with a worker lease renewal
• a plan is created under revision A and dispatched after revision B becomes active
• the process exits after intent persistence but before the request
• the provider applies the mutation and the response is lost
• rollback starts while work is queued under the newer revision
• the old revision reads state written by the new revision
• the config store is available but the audit ledger is temporarily unavailable

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.

A small operator checklist

Before promoting a revision:

• Can I name the exact revision running each worker?
• Did the canary exercise every write-capable tool?
• Are dispatch-time policy and revision checks enabled?
• Is queued work labeled with its originating revision?
• Can the target revision read the current durable state?
• Do I know how to reconcile an ambiguous external request?
• Does the rollback plan specify drain, cancel, or replan behavior?
• Can I prove the result from the ledger if telemetry is delayed?

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.