Agents work concurrently, rewrite earlier steps, rebase stacks, and hit conflicts mid-flight. Git turns those moments into branch choreography and interrupted commands. Jujutsu makes the working copy a Change, keeps its identity through rewrites, rebases descendants automatically, and records conflicts as inspectable state.
A Change is the piece of work itself. It can evolve, move, split, stack, and conflict without losing its identity. That is a better primitive for agents that iterate continuously and work in parallel.
Git workflow
Create and name a branch, make sure it points at the right base, then keep the branch and worktree paired for the life of the task.
Jujutsu / Vex workflow
Create a workspace. Its working copy is already a mutable Change in the shared graph; no task branch is required.
Why agents care
Agents get isolated directories without a parallel branch-naming system.
Git workflow
Create a fixup commit, remember its target, run an interactive autosquash rebase, and repair every descendant if the rewrite changes them.
Jujutsu / Vex workflow
Move the edit into the Change it belongs to. Jujutsu automatically rebases every descendant onto the rewritten result.
Why agents care
The graph absorbs iteration without turning cleanup into another task.
Git workflow
Rebase the branch chain in the right order. A conflict pauses the command and leaves the repository inside a special rebase state.
Jujutsu / Vex workflow
Rebase the mutable stack as one graph operation. Descendants follow their parents automatically, even when a Change becomes conflicted.
Why agents care
One explicit operation updates the stack; there is no rebase choreography per branch.
Git workflow
The merge or rebase stops. Resolve everything now, continue or abort correctly, then reconstruct what the command was trying to do.
Jujutsu / Vex workflow
The operation succeeds and records a logical conflict in the affected Change. That Change can still be inspected, moved, rebased, or backed out.
Why agents care
A conflict becomes visible work to schedule, not a mode that traps the workspace.
Git workflow
Search reflogs, identify every ref that moved, and choose the right reset or recovery sequence without losing newer work.
Jujutsu / Vex workflow
Inspect the repository-wide operation log and undo the operation, or restore the complete repository view from an earlier point.
Why agents care
Recovery is based on the action that happened, not on reverse-engineering ref movement.
Git workflow
Move hunks through the index, partial commits, resets, and temporary fixups while keeping the intended branch history in your head.
Jujutsu / Vex workflow
The working copy is already a Change. Split it into sequential Changes or squash selected files and hunks into the Change that owns them.
Why agents care
Review structure is modeled with Changes instead of staging-area state.
Git workflow
Every amend creates a new commit SHA. Humans and tools need a branch or pull request to infer that the new commit is the same piece of work.
Jujutsu / Vex workflow
The commit ID changes, but the Change ID normally stays stable. Vex carries that identity into patchsets and hosted review.
Why agents care
Agents can iterate aggressively without losing the durable identity reviewers follow.
Git workflow
Repository locks serialize sensitive mutations, and concurrent automation often needs retry logic around shared mutable state.
Jujutsu / Vex workflow
The operation log records divergent operations and reconciles concurrent repository views instead of corrupting the repository.
Why agents care
The source model expects concurrent actors—the normal condition for agent-led work.
Jujutsu supports multiple working copies backed by one repository. Vex wraps that primitive with workspace policy and setup hooks, so each agent gets an isolated directory and its own working-copy Change in the same graph.
Git worktrees can also isolate directories. The difference is what happens next: Jujutsu tracks each workspace's working copy as a Change instead of requiring a branch to carry the task's identity.
Git worktree setup
$ git worktree add ../fix-auth -b agent/fix-auth
$ git worktree add ../billing -b agent/billing
$ git branch --list 'agent/*'Vex / Jujutsu workspace setup
$ vex ws create fix-auth
$ vex ws create billing
$ vex ws listfix-auth@
Agent 1
Mutable Change
billing@
Agent 2
Mutable Change
review@
Human
Independent view
Imagine 3 agents building one dependent feature. The schema supports the API; the API supports the UI. Main advances before review.
In Git, the team must preserve that branch chain while replaying it. In Jujutsu, the dependencies already live in the commit graph. Move the mutable stack and descendants follow their rewritten parents automatically.
Refresh main + replay the current stack
$ vex pull --rebase --dest mainOne dependent stack
main movedAgent 1
Agent 2
Agent 3
When a rebase cannot combine 2 edits, Jujutsu records the logical conflict in the resulting Change and finishes the operation. The conflict is now a native, inspectable state in the graph.
There is no half-finished rebase session to continue or abort. The affected Change is marked conflicted; unaffected work remains usable.
A conflicted Change can be rebased again, merged, checked out, or backed out. Jujutsu stores the logical sides, not nested marker text.
Another agent or a human can inspect the conflicted Change, resolve all or part of it, and review the resolution as an ordinary diff.
Find conflicted Changes
$ vex log -r 'conflicts()'Step back one repository operation
$ vex undoGit reflogs record ref movement. Jujutsu's operation log records the complete repository view after every operation: Changes, bookmarks, heads, and each workspace's working-copy Change. Undo targets the action, not one ref at a time.
$ vex op logInspect repository operations in order, including concurrent or divergent operations.
$ vex undoStep back without first calculating which branches, commits, and working copies moved.
$ vex op restore <id>Return the complete repository to an earlier operation when a larger experiment went wrong.
Jujutsu provides the local graph. Vex gives that Change a durable hosted number, patchset history, checks, review state, and dependency-aware landing.
Local source graph
The local Jujutsu graph and hosted review surface refer to the same durable Change #625.
This capture proves identity continuity; it is not a performance comparison with upstream Jujutsu or Git.
Ghostty · vex log + vex change show '#625'
Vex organization · 11 Aug 2026
Hosted review
That same Change carries checks and its position in the dependency chain once hosted.
/vex/change/625
Vex organization · 11 Aug 2026
Jujutsu does not eliminate difficult merges or make every concurrent edit compatible. It makes the conflict explicit, movable, inspectable, and undoable so the workflow can keep operating around it.
Start with proof