Revert & Redo for AI Agent turns (rewind the workflow to before an agent edit)

[sshiv012]

Status: Draft : seeking feedback
Area: AI Agent (copilot) · agent-service · frontend workspace
Type: Feature proposal

Summary

The Texera AI agent edits the user's live workflow canvas, its tools add, modify, and delete operators (and the changes auto-persist). Today there is no agent-aware way to back out a turn that went wrong: you fix it by hand. This proposal adds a per-turn "Revert" control (rewind the workflow to the state before an agent turn) and a "Redo" control (undo the revert), implemented almost entirely on top of machinery the agent already has.

I have a working prototype (running locally) and would like feedback on the design, especially the UX granularity and the protocol additions, before opening a PR.

Motivation

• The agent mutates real state. A bad suggestion ("restructure this", a wrong delete) currently leaves the user to manually undo a multi-operator change.
• This raises the cost of letting the agent try things, which is exactly the behavior we want to encourage. A cheap, reliable "step back" makes the agent feel safe to experiment with.
• A frontend-only "visually undo" is not enough: the agent-service keeps its own notion of the current workflow (its HEAD), so the next message would silently clobber a cosmetic revert. We want a true rewind that keeps the agent's context consistent.

Background — what already exists

The agent-service already models a conversation as a version tree of ReAct steps:

• Each ReActStep has an id and a parentId (the tree), plus beforeWorkflowContent and afterWorkflowContent snapshots.
• A HEAD pointer marks the current step; the visible chat is the ancestor path from root to HEAD.
• The frontend is already HEAD-aware: it recomputes the visible steps from HEAD and applies any workflow snapshot to the canvas via WorkflowActionService.reloadWorkflow(...).

The only missing primitive was the ability to move HEAD backward. There was no client command for it. That is the gap this proposal fills.

Proposal

Revert (per turn)

A Revert control on each agent turn. Clicking it:

1. Asks the agent-service to move HEAD to that turn's parent step.
2. The agent-service restores its working workflow to the turn's beforeWorkflowContent and replies with the new HEAD + workflow content.
3. The frontend advances its HEAD pointer (which recomputes the visible chat) and reloads the canvas from the snapshot.

Redo

A single Redo control in the chat toolbar, shown only when a redo is available. The agent-service keeps a redo stack: a revert pushes the pre-revert HEAD; redo pops it and moves HEAD forward, restoring that step's afterWorkflowContent. Sending a new prompt clears the redo stack (a new branch invalidates redo). Redo is repeatable for multiple consecutive reverts.

How it works

Revert + Redo flow

sequenceDiagram
    actor U as User
    participant FE as Frontend (agent panel)
    participant AS as agent-service
    participant WA as WorkflowActionService (canvas)

    U->>FE: Click "Revert" on turn T
    FE->>AS: WsClientRevertCommand { messageId: T }
    Note over AS: HEAD ← parent(T)<br/>push old HEAD to redo stack<br/>restore workflow = T.beforeWorkflowContent
    AS-->>FE: WsServerHeadChangeEvent { headId, workflowContent, canRedo: true }
    FE->>FE: headId → recompute visible steps
    FE->>WA: reloadWorkflow(workflowContent)
    Note over FE: "Redo" button appears

    U->>FE: Click "Redo"
    FE->>AS: WsClientRedoCommand
    Note over AS: pop redo stack → HEAD ← oldHead<br/>restore workflow = step.afterWorkflowContent
    AS-->>FE: WsServerHeadChangeEvent { headId, workflowContent, canRedo: false }
    FE->>WA: reloadWorkflow(workflowContent)

Loading

HEAD movement over the step tree

graph LR
    I[INITIAL] --> U1[turn 1 user] --> A1[turn 1 agent]
    A1 --> U2[turn 2 user] --> A2[turn 2 agent]

    classDef head fill:#2da44e,color:#fff,stroke:#2da44e;
    %% Revert(turn 2): HEAD moves A2 -> A1 ; Redo: HEAD moves A1 -> A2

Loading

Revert(turn 2) moves HEAD from A2 to A1 (turn 2's parent). The turn-2 steps stay in the
tree, so Redo can move HEAD back to A2. A new prompt after a revert branches from A1 and
clears the redo stack.

New WebSocket frames

Client → server:

• WsClientRevertCommand { messageId } — rewind to before that turn.
• WsClientRedoCommand — undo the most recent revert.

Server → client:

• WsServerHeadChangeEvent { headId, workflowContent, canRedo } — HEAD moved without a new step.
• canRedo added to WsServerSnapshotEvent so a reconnecting client can render the Redo state.

Both commands are rejected with an error frame while the agent is GENERATING (a mid-run rewind would race the loop's own HEAD/workflow mutations).

Design decisions & alternatives considered

1. True rewind vs. frontend-only revert. A frontend-only revert (just reload a cached snapshot onto the canvas) is ~half the work but leaves the agent-service's HEAD out of sync, so the next message clobbers the revert. We chose the full rewind for correctness.
2. Granularity: per turn vs. per step. We chose per turn (one control per user message) it matches "undo this change" and keeps the UI quiet. Per-step revert is possible (the tree already supports it) but noisier; could be a follow-up.
3. Redo: stack vs. single-level. A stack supports multiple consecutive undos→redos for little extra code. New prompt clears it.
4. Not reusing the canvas undo/redo (yjs UndoManager). Agent turns produce many fine-grained operator edits; routing through undo/redo would create dozens of entries per turn and tangle with manual edits. reloadWorkflow already clears the undo stack, so snapshot-replay is a cleaner primitive here.

Open questions (feedback welcome)

1. Granularity — is per-turn the right default, or do people want per-step revert too?
2. Button placement — Revert lives on each turn's header; Redo is a single toolbar button. Reasonable, or should both be in the toolbar (operating on the latest turn)?
3. Branch UX — after a revert + new prompt, the old branch is dropped from view but still in the tree. Should we surface branch navigation, or keep it hidden (current proposal)?
4. Persistence — the step tree is in-memory in the agent-service. Should revert history survive an agent-service restart, or is "session-scoped" acceptable?
5. Confirm dialog — Revert currently asks for confirmation (it discards later turns). Keep it, or make it instant and rely on Redo?

Out of scope (for the initial PR)

• Per-individual-step revert.
• Forward/branch navigation UI beyond single-level Redo.
• Persisting revert history across restarts.

---

Happy to adjust the design based on feedback before opening the PR. Prototype branch and tests are ready.

[chenlica]

@sshiv012 Thank you.

@bobbai00 and @Ma77Ball Please chime in.

[aicam]

I believe @bobbai00 has already implemented this but not merged.

[chenlica]

@bobbai00 ?

[bobbai00]

@sshiv012 thanks for proposing this design.

Can you elaborate on "Redo" stack ? For "Revert" part, yes the current agent service already has the capability and you can easily implement an per-ReAct-step level revert.

[sshiv012]

Yeah the redo stack is basically revert in reverse, all in-memory in the agent-service, no persistence or schema changes.

Revert moves HEAD back to the turn's parent and replays beforeWorkflowContent, and stashes the old HEAD on a redo stack. The steps don't get deleted, they stay in the tree. Redo just pops that stack, moves HEAD forward and replays the step's afterWorkflowContent. It's a stack rather than single-level so you can revert a few turns and redo them back in order. Sending a new prompt wipes the redo stack though, new prompt branches from wherever HEAD is, so the forward history is dead at that point (same as normal undo/redo).

Wiring-wise the server sends a HeadChangeEvent { headId, workflowContent, canRedo } and the FE recomputes the visible chat + reloads the canvas from it. canRedo also rides on the snapshot event so a reconnect renders the button state right. Both commands get rejected mid-generation, otherwise they'd race the loop's own HEAD writes.

I already built this last week btw, prototype's up with tests passing. Let me get the PR up.

[ofekron]

Per-turn is the right default, but snapshot rewind needs an optimistic concurrency precondition before it replaces the live canvas.

Consider this sequence: the agent finishes turn T; the user manually edits the workflow; then the user clicks Revert on T. Reloading T.beforeWorkflowContent would silently erase the later human edit even though HEAD still points at T.

I would bind each step to beforeRevision/beforeDigest and afterRevision/afterDigest, then require revert to include the client’s currently observed workflow revision. The backend compares that with the authoritative current revision:

• exact match: move HEAD and apply the recorded snapshot;
• mismatch caused by later manual edits or another client: reject with a structured conflict and preserve both states;
• reconnect: fetch HEAD, current workflow revision, branch children, and redo availability from one backend snapshot.

For a later version, storing the agent turn as a reversible workflow patch would allow a three-way revert that removes only the agent’s changes while retaining compatible human edits. Until then, fail closed on revision mismatch is safer than snapshot replacement.

Redo state and the step tree should also survive agent-service restart if workflow snapshots themselves persist; otherwise the UI advertises a history model that disappears independently of the workflow it governs.

This backend-owned revision/projection split is how Better Agent keeps native Claude, Codex, and Gemini session state consistent across reconnects and concurrent clients. I maintain the project; it is source-available and free for non-commercial use, while commercial use requires separate permission: https://github.com/ofekron/better-agent

AI-assistance disclosure: this comment was drafted by Codex under the maintainer’s authorization and reviewed in Better Agent.

[sshiv012]

Thanks for pointing this out. This edge case was overlooked because the current implementation serializes agent-side history operations, but assumes the persisted workflow still matches the snapshot recorded after the agent turn. A manual edit or update from another client can violate that assumption without changing the agent’s HEAD, causing revert to overwrite newer changes.
I’ll look into adding a workflow revision or digest precondition so revert can detect the mismatch and preserve the current state instead of replacing it. A patch-based revert may be a useful longer-term improvement.