Workflow Time Travel: Snapshots, Deployment Versions, and Rolling Back a Bad Agent at 03:00

Unless the engine kept it for you.

Two Tables, One Time Machine

AACFlow gives every workflow a real history through two database tables:

• workflowDeploymentVersion — immutable, append-only. Every time a workflow is deployed, the full serialized DAG (blocks, edges, sub-block values, variables, connector bindings) is gzipped and written as a new row. The row gets a monotonically increasing version integer, a createdAt, a deployedBy user, and a content-addressed hash. Versions are never updated, never overwritten, never garbage-collected.
• workflowExecutionSnapshots — one row per execution, capturing the state of every variable, every block input, every block output, every credential reference, and the exact deployment version that ran. Stored as gzipped JSONB for large states, indexed by (workflowId, executionId) for O(1) lookup.

Together they give you the two questions every on-call wants to answer at 03:00:

1. What was deployed? — SELECT serializedGraph FROM workflowDeploymentVersion WHERE workflowId = ? AND version = ?
2. What did it actually do on that run? — SELECT snapshot FROM workflowExecutionSnapshots WHERE executionId = ?

Neither of those queries depends on the current state of the workflow. The editor can be in any state. The history is intact.

Reproducing a Bad Run Exactly

When a customer says "the workflow misbehaved on yesterday's 14:32 invocation," the engineer does not have to guess.

The execution snapshot stores the inputs as they were observed at the entry trigger — the webhook payload, the form submission, the schedule context. It stores the deployment version that was active when the run started. It stores the resolved values of every workflow variable at the moment of execution.

Replaying is one click. The executor reads the deployment version from the snapshot, deserializes the DAG, rehydrates the variables, re-injects the inputs from the snapshot, and runs the workflow exactly as it ran the first time — same blocks, same model versions, same prompt templates, same connector bindings. The only thing that can differ is the third-party API response, and even those are captured in the per-block outputs of the previous snapshot for side-by-side comparison.

This is the difference between "I think I know what happened" and "here is exactly what happened, run it yourself."

Rolling Back a Bad Agent at 03:00

The rollback story is even simpler. A new deploy is just a new row in workflowDeploymentVersion. Rolling back means flipping a pointer: workflow.activeDeploymentVersion = N - 1.

In AACFlow the rollback is a single API call. The next execution that arrives — webhook, schedule, manual run, child workflow — picks up the previous version. No editor reload, no redeploy, no copy-paste of a backup. The bad version stays in the table (immutable rows live forever) so you can investigate, diff, and forensically analyze, but no new executions touch it.

The same machinery powers a "deploy with auto-rollback" flag: if more than X% of executions in the first Y minutes return errors, the platform flips the pointer back automatically. Trigger.dev v4 fires the watcher task; the rollback is a write to one row.

Copy-on-Write for Snapshot Storage

Naively storing the full variable state for every block on every execution would explode the snapshot table within a week. A workflow that runs 100k times a day with 20 blocks would write 2M snapshot fragments daily.

AACFlow stores snapshots copy-on-write: each snapshot row references the previous block's output by content hash and only stores the delta. If block 5 returns the same 80kb JSON as the last 50 runs, we keep one copy of that blob and 50 hash references. Large blobs (anything over 32kb) get gzipped and offloaded to S3-compatible blob storage with the hash as the object key. The snapshot table itself holds metadata and small deltas; the bulk lives in cold storage.

The result is that one year of execution history for a busy workflow takes gigabytes, not terabytes. The platform stays affordable to operate without losing the ability to audit any single run.

Diff Draft Against Prod

The other thing the immutable deploy history gives you is the diff view.

In the editor, the workflow has two states at all times: the draft (what the developer is editing) and the active deployment version (what production is running). AACFlow renders a side-by-side diff: blocks added, blocks removed, sub-block values changed, edges rerouted, variables renamed. Before you click Deploy, you see exactly what is about to change in production — block by block, field by field.

That diff comes from the same workflowDeploymentVersion table. The draft serializes to the same shape; the diff is a structural comparison of two JSON trees. There is no separate diff engine, no special UI code, no parallel data model. It is the natural consequence of treating deploys as immutable rows.

Time Travel Is the New Default

You cannot build agent infrastructure on a workflow engine that doesn't remember its own history. The cost of a bad deploy is too high, the surface area too large, the failure modes too quiet. Either the platform gives you the receipts — every version, every run, every diff — or it does not, and you find out at 03:00 that the receipts are gone.

AACFlow keeps the receipts.

Bring your most paranoid workflow to AACFlow and see what one year of execution history looks like when the engine was designed to remember.