UX Proposal: Agent Speculative Execution & Universal Rollback

Speculative Execution & Universal Rollback

This section describes a long-term architectural concept, not a near-term roadmap item. It is intended as a direction-setting idea for PM and engineering consideration.

The Core Idea

Today, when an agent or flow acts on GitLab — posting a comment, creating an issue, editing a file — those actions are immediately applied and their side effects are immediate (notifications fire, webhooks trigger, audit events log). There is no native undo.

The speculative execution model inverts this. Write actions are buffered during flow execution and only committed when the user explicitly approves. The flow runs to full completion against real read data, but all mutations are staged. The user reviews a structured diff of everything the flow intends to change — across code, issues, comments, MRs, and any other affected resource — and approves or rejects the batch.

This is conceptually similar to how Git manages code changes, or how database migrations can be previewed before being applied — but extended to the full surface area of GitLab project data.

What the User Experience Would Look Like

1. User triggers a flow. No tool approval modal (as in #591223 (closed) ) — the flow runs immediately.
2. The flow completes. All reads were real; all writes were staged.
3. User receives a notification: "Triage & Draft flow completed — review 3 proposed changes."
4. User opens a Change Review (new concept) view showing a structured diff:

── Issue #412 ──────────────────────────────────
  Comment (new)
  + "Based on the code in auth/session.rb, the root cause appears to be..."

── Issue #398 (linked) ─────────────────────────
  New issue proposed
  + Title: "Spike: investigate session token expiry edge case"
  + Labels: backend, spike
  + Assignee: (none)

── Branch: duo/fix-session-412 ─────────────────
  File: auth/session.rb  (+14, -3)
  [view diff]

5. User can approve all, approve selectively, or reject entirely.
6. On approval, changes are committed atomically. Side effects (notifications, webhooks) fire at commit time, not during the flow run.

What Would Need to Change in GitLab

I assume this would require a number of non-trivial changes in the Gitlab platform.

AI seems to think it might involve:

• Write buffering infrastructure. Every GitLab API write action invoked by a flow would need to be interceptable and stageable. This likely means a flow-aware middleware layer in the API that routes writes to a temporary store rather than the database when called in a speculative context.
• Deferred side effects. Notifications, webhook triggers, audit events, and CI pipeline triggers that result from writes would need to be held until commit. This touches GitLab's event/notification system at a deep level.
• Structured diff rendering. GitLab would need a new UI surface capable of rendering diffs not just for code, but for structured data: issue fields, comment bodies, label changes, MR metadata. This is a meaningful frontend investment.
• Atomic commit mechanism. Approving a batch of staged changes needs to apply them as close to atomically as possible, with rollback if any individual write fails after commit begins.
• Conflict detection. Between the time a flow runs and the user approves, the underlying data may have changed (someone else commented on the issue, the branch was updated). The commit step needs to detect and surface conflicts, similar to a merge conflict.
• Partial approval. Users should be able to approve some staged changes and reject others. The system needs to understand dependencies between staged actions (e.g., if a later step depended on an issue created in an earlier step, rejecting the issue creation may invalidate downstream changes).

Why This Matters

The pre-execution approval model in #591223 (closed) asks users to make consent decisions in the abstract — before they know what the flow will actually produce. Speculative execution shifts consent to after the user can see exactly what the agent did, with full context. This is a fundamentally more meaningful form of human oversight.

It also provides GitLab with a clean answer to one of the hardest problems in enterprise AI adoption: "How do I trust an agent with my production data?" The answer becomes: you don't have to trust it blindly — you review its work before it ships.