← Blog · · 7 min read

Why Every AI Agent Needs Its Own Workspace

The multi-agent merge conflict problem and how Jujutsu's architecture solves it better than Git.

Colony Team
Colony Team

You’ve seen the demos. An AI agent writes code, commits it, pushes to GitHub. Impressive. But what happens when you have three agents working on the same codebase simultaneously?

Git falls apart.

Not because Git is bad. Git was designed for humans who communicate before merging work. AI agents don’t have that luxury. They work in parallel, make conflicting assumptions, and need their changes reconciled after the fact.

This is the multi-agent version control problem. And it’s why Colony uses Jujutsu instead of Git.

The Multi-Agent Merge Conflict

Walk through this with me. Three AI agents working on a web app:

  • Agent A: Refactoring auth to use new token format
  • Agent B: Adding rate limiting middleware
  • Agent C: Updating API endpoints for better errors

All three need to modify src/middleware/auth.ts. In Git:

  1. Each agent clones and creates a branch
  2. Agent A finishes first, pushes to feat/new-tokens
  3. Agent B finishes, pushes to feat/rate-limiting — no conflicts yet
  4. Agent C finishes, tries to push — merge conflict

Now you have to:

  • Review three different branches
  • Manually resolve conflicts in auth.ts
  • Test that all changes work together
  • Squash or merge in the right order

This workflow assumes human oversight at every step. But the whole point of multi-agent systems is to reduce manual intervention.

Git’s Lock Contention Problem

Even before conflicts arise, Git has issues with parallel work:

Branch explosion. Ten agents means ten branches to track. With 50 agents doing exploratory work, your branch graph becomes unreadable.

Rebase churn. Agent A’s branch merges first. Agents B and C need to rebase. If B rebases before C finishes, C’s rebase gets more complex. Coordination overhead grows quadratically.

Stale references. If an agent’s branch sits idle while main advances, its changes become increasingly difficult to merge.

Lost work. Agent crashes before committing? All work is gone. Git doesn’t auto-commit.

These problems are manageable for small human teams with code review. AI agents need a different model.

Enter Jujutsu: First-Class Conflicts

Jujutsu is version control built by a Google engineer who got tired of Git’s limitations. It’s Git-compatible (you can push/pull from GitHub), but it reimagines the core model.

What makes Jujutsu different:

Working copy is always a commit. In Git, your working directory is “uncommitted changes.” In Jujutsu, it’s automatically a commit. You never lose work.

Changes, not branches. Jujutsu’s primitive is the change (a commit with a unique ID). Branches (called “bookmarks”) are optional labels. You can have hundreds of changes without naming them.

First-class conflict representation. When two changes conflict, Jujutsu doesn’t block you. It creates a merge commit with embedded conflict markers and lets you continue working. You resolve conflicts when you’re ready, not when Git forces you to.

Operation log. Every Jujutsu operation (commit, rebase, merge) is logged and reversible. Agent makes a bad merge? jj undo and it’s gone.

Let’s see how this changes the three-agent scenario.

Multi-Agent Workflow in Jujutsu

Same scenario: three agents editing auth.ts. In Jujutsu:

  1. Each agent works in its own workspace
  2. Agent A makes changes → jj describe -m "feat: new token format" (auto-committed)
  3. Agent B makes changes → jj describe -m "feat: rate limiting"
  4. Agent C makes changes → jj describe -m "feat: error messages"

Now we merge their work:

# Start with Agent A's change
jj bookmark create feat/combined
jj bookmark set feat/combined -r <agent-a-change-id>

# Merge Agent B's work
jj rebase -s <agent-b-change-id> -d feat/combined

# Merge Agent C's work
jj rebase -s <agent-c-change-id> -d feat/combined

If there are conflicts in auth.ts, Jujutsu doesn’t stop. It creates a merge commit with conflict markers embedded in the history:

// src/middleware/auth.ts
export function authenticate(req: Request) {
<<<<<<< Conflict 1 of 2
  // Agent A's version
  const token = parseJWT(req.headers.authorization);
|||||||
  // Base version
  const token = req.headers.authorization;
=======
  // Agent B's version
  if (isRateLimited(req)) throw new Error("Rate limited");
  const token = req.headers.authorization;
>>>>>>> Conflict 1 of 2
}

You (or a fourth “resolver” agent) can see exactly what each agent changed and decide how to merge them. The conflict is versioned. You can commit a resolution, try it, and undo if it doesn’t work.

Parallel Workspaces Without Locks

Git has a hidden assumption: one working directory per repo. Want to work on two branches simultaneously? You need two clones (or Git worktrees, which are clunky).

Jujutsu has built-in workspace support:

# Create workspaces for three agents
jj workspace add ../agent-a
jj workspace add ../agent-b
jj workspace add ../agent-c

Each workspace is a separate working directory, but they share the same repository. Changes made in one workspace are immediately visible to others (via jj log), but they don’t interfere with each other’s working files.

This is massive for AI agents. Colony spawns 10 agent workspaces on the same repo, lets them work in parallel, and merges their changes afterward — all without lock contention or branch management overhead.

Auto-Commit Saves Agents From Themselves

AI agents crash. They get rate-limited, hit context limits, or produce code that segfaults. In Git, if an agent crashes before git add and git commit, all work is lost.

In Jujutsu, the working copy is always committed. Agent crashes mid-task? Its partial work is preserved. Colony can inspect the failed change, log the error, and either resume or roll back.

Here’s what this looks like:

# Agent crashes after editing 3 files
$ jj log
@  nqkxvlun agent-b@colony 2 minutes ago
│  work in progress: added rate limiting (CONFLICT)
│
◉  rtwkmrpo main@origin 1 hour ago
│  feat: initial auth system

The agent’s work is safe. We can:

  • jj diff -r nqkxvlun to see what it changed
  • jj restore to reset if changes are bad
  • jj undo to completely revert the operation

This is fault tolerance at the VCS level. Git doesn’t give you this.

The Operation Log: Undo Anything

Every Jujutsu operation is recorded:

$ jj op log
@  9c4c8f86 2 minutes ago, agent-b@colony
│  rebase 3 commits
◉  7a3d2e91 5 minutes ago, agent-a@colony
│  describe commit as "feat: new token format"
◉  5f1e9d42 10 minutes ago, orchestrator@colony
│  bookmark create feat/combined

Agent makes a bad rebase? Undo it:

jj undo --op 7a3d2e91  # Revert to before the bad rebase

This isn’t like git revert (which creates a new commit). Jujutsu’s undo rewinds the operation history. It’s time travel for your repository.

For multi-agent systems where mistakes are inevitable, this is critical.

Real Example: Three Agents, One File

Let’s make this concrete. Three agents editing package.json:

Agent A adds a dependency:

{
  "dependencies": {
    "express": "^4.18.0",
    "zod": "^3.22.0"
  }
}

Agent B adds a different dependency:

{
  "dependencies": {
    "express": "^4.18.0",
    "jsonwebtoken": "^9.0.0"
  }
}

Agent C updates Express:

{
  "dependencies": {
    "express": "^4.19.0"
  }
}

In Git, merging requires manual conflict resolution. In Jujutsu:

# Merge all three changes
jj rebase -s agent-a-change -d main
jj rebase -s agent-b-change -d agent-a-change
jj rebase -s agent-c-change -d agent-b-change

# Result:
{
  "dependencies": {
    "express": "^4.19.0",
    "zod": "^3.22.0",
    "jsonwebtoken": "^9.0.0"
  }
}

Jujutsu understands these are independent changes (different keys, plus a version update) and combines them automatically. If there were true conflicts (two agents changing the same key to different values), it would embed conflict markers.

Git Compatibility: Have Your Cake

Jujutsu isn’t a Git replacement that forces you to abandon GitHub. It’s Git-compatible:

# Push to GitHub from Jujutsu
jj bookmark create feat/multi-agent-work
jj git push --bookmark feat/multi-agent-work

# Pull from GitHub
jj git fetch
jj rebase -d main@origin

Colony’s agents work in Jujutsu locally (getting all the benefits), then push to Git remotes for code review and CI/CD. Best of both worlds.

When Jujutsu Isn’t Enough

Jujutsu solves the version control problem, not the semantic conflict problem. If Agent A renames a function and Agent B adds a call to that function (using the old name), Jujutsu will merge both changes without conflict — but the code won’t compile.

This is where Colony’s orchestration layer comes in. After agents merge their changes, Colony runs:

  1. Linters and type checkers
  2. Test suites
  3. An “architect” agent that reviews combined changes

If semantic conflicts are detected, Colony spawns a “resolver” agent to fix them. But Jujutsu gets us to this point — it handles the mechanical merging so we can focus on semantic validation.

The Future: Agent-Native VCS

Jujutsu wasn’t designed specifically for AI agents, but its architecture aligns perfectly with multi-agent workflows. As AI coding tools mature, we’ll need more VCS innovations:

  • Conflict resolution hints embedded in merge commits
  • Declarative merges (agents specify strategies like “take all dependency additions”)
  • Workspace snapshots for checkpointing agent work

For now, Jujutsu is the best tool for the job. It lets Colony’s agents work in parallel, fail gracefully, and merge changes without human intervention at every step.

Want to see Jujutsu powering multi-agent development workflows? Join the waitlist for Colony.

jujutsu vcs ai-agents git