Automation Versions (Audit History)

Every automation keeps an immutable, partial version history of its execution configuration. Versions show which captured settings a run pinned and who saved them, while operational state and several consent-backed settings remain outside the snapshot.

How versions are created

• Creating an automation records version 1.
• Every subsequent configuration save normally records a new version (+1). A change to fixture-recording consent alone is deliberately not versioned because that consent is outside the snapshot; combining it with any captured configuration change still creates the version. There is no way to edit or delete a past version — the history is append-only.
• Restoring a version and deploying a staging copy both update the automation through the same versioned save path, so each appends a new snapshot rather than changing an old one.

The Advanced Builder's auto-saved local draft is browser storage, not a version. It becomes versioned only when you persist it with Deploy as Dry Run for a new automation or Save for an existing one. Test agent runs the saved version, not an unsaved local draft.

What a version captures

A version snapshots a defined subset of the automation's execution-shaping configuration. It is an audit and rollback record for the captured fields, not a complete replay package for everything that influenced a run:

What a version does not capture

A version is deliberately a partial snapshot: it covers configuration, not operational state. These are never recorded, so a version-to-version comparison can say nothing about them and a restore leaves them alone:

knowledge sources · consent state · exposure to your AI assistant · webhook payload mode and example payload · memory opt-in · fixture-recording consent · the production require-passing-checks-before-deploy gate · failure notifications · support-ticket toggles · active/paused state.

This matters when you are reconstructing why a past run behaved as it did. The version is authoritative for the values in its captured columns, but it does not preserve the effective composed prompt. That prompt can include uncaptured knowledge sources and other composition performed when the remote agent is synchronized. A knowledge-source change therefore does not appear in version history, and the snapshot alone cannot reproduce the complete context Anthropic saw.

Versions and runs

• Every run records an AgentVersionId. That gives durable attribution for the snapshot's captured subset; it is not proof of the effective knowledge, composed prompt, remote-agent state, credentials, effective deny-list expansion, shared MCP-client state, or other uncaptured runtime inputs.
• An immediately launched run normally records the latest version. There is no user-facing way to select an older snapshot for a new run.
• A queued run can be hybrid. Its version id is fixed when the trigger is enqueued. When a slot frees, launch keeps that id but reloads the current automation definition and remote ids. Logic that explicitly reads the retained snapshot—such as pinned policy checks—can therefore coexist with current-definition session inputs.
• Crash recovery has the same attribution boundary. It keeps the original run's version id but starts a fresh execution from the current live automation definition and current remote resource ids. Treat the version id as captured-field attribution, not proof that a queued or replacement attempt reconstructed every other input from the earlier state.

Viewing versions

The portal surfaces the version history on each automation's Version history page (/automations/{id}/versions) — a newest-first table of every version with its trigger, model, and dry-run/live mode. See Automation Version History and Rollback for the walkthrough. Each run detail header shows its shortened snapshot id, exposes the full id on hover, and links to this history. The adjacent partial audit attribution label is deliberate: use the mapping for captured fields, not as a claim that every execution input was frozen.

Every version except the oldest also has a What changed expander, showing that version's differences against the one before it: supported scalar settings as old → new, prompts and trigger configuration behind a fold, and callable, required, chained, native, and bookend tool changes as added/removed lists. The visible scalar list includes the max tool-result size and labels run-as as audit-only.

Outbound network access is compared too. A change of choice appears as one old → new row, the host list is compared only when both versions use Only the hosts I list, and the package-manager switch is compared only when both versions use one of the two narrow choices — under Unrestricted and Platform default the registries are reachable anyway, so a row there would read as a narrowing when it is the opposite. A version saved before the setting existed shows as not recorded rather than as a change.

The comparison is narrower than the snapshot in one place worth knowing: the captured concurrent-run setting and production approval policy are not compared, even though both are recorded and both are re-applied on restore. Each expansion also shows a not-covered list, and that list is itself narrower than the full uncaptured set — fixture-recording consent and the require-passing-checks-before-deploy gate are outside the snapshot but are not named on it. Nothing the version snapshot captures changed still means only that the compared fields had no visible difference; it is not proof that uncaptured knowledge, consent, credentials, shared-client state, or other operational inputs were unchanged.

Restoring an older version

You can restore any earlier snapshot as the live configuration from the Version history page — see Automation version rollback. Restore re-applies the snapshot's captured fields and records the rollback as a new version, so the audit trail is never lost and the change is reversible.

Restore is never refused because a run is in flight. An in-flight run keeps the immutable version row it pinned at launch, so restore cannot corrupt that run's own snapshot — but the shared per-automation MCP client's AllowedTools and IsDryRun are rewritten at once, and the gateway re-reads both on every tool call. Finish or interrupt active runs before restoring materially different tools or a different dry-run posture.

Related pages

• Automation version rollback
• Automation Version History and Rollback
• Run lifecycle and statuses