Parallel agents

One sandbox, many conversations. Press New agent and you get a fresh isolated conversation: it runs in its own git worktree of every repo in your workspace, on its own branch. That is the default, and it is what makes running five agents at once a normal afternoon rather than a merge disaster.

What an isolated conversation gets#

On its first turn, the conversation is given one worktree per repo, laid out exactly like your workspace so that monorepo-relative paths, .claude/ config resolution and the agent's own habits all work unmodified. Each sits on a branch named agent/<conversation>.

/work                     the shared tree — what you see in the Workspace view
  api/                    a repo
  web/                    another repo

# and, for one isolated conversation, its own checkout of the same thing:
/history/worktrees/<conversation>/
  api/                    on branch agent/<conversation>
  web/                    on branch agent/<conversation>

The checkouts live outside /work, so they never show up in your file tree, your search, or the workspace history. Git object stores are shared — a worktree costs a checkout, not a clone. The composition is frozen when it is created: a repo you clone into the workspace later doesn't retroactively join a conversation that is already running.

The agent sees its worktree as /work#

Every absolute path an agent inherits — from a memory, a CLAUDE.md, a message you wrote quoting a file, its own earlier turn — says /work. So the turn runs in its own mount namespace where its worktree is the workspace root:

/work                     THIS conversation's worktree, mounted over the workspace root
/mnt/intentic-main        the shared tree, still reachable on purpose

The agent cannot take a wrong turn into the shared tree by accident, and nothing has to be remembered or refused. Writing to the main tree is still possible for an agent that genuinely means it — comparing against main, reading a sibling repo — it is just no longer what happens by mistake. Two things are deliberately shared rather than copied: your daemon state (chat transcripts, attachments) and the installed dependency trees, without which a worktree could not resolve an import.

It is rebased before every turn#

A conversation can sit for hours between turns while the main line moves under it. So before a turn starts, the daemon rebases the branch onto the current main line. If the rebase would conflict it is rolled back and the turn runs from where it was — a branch that cannot be moved cleanly simply isn't moved. This is why a resumed conversation reads today's code instead of writing a delta against a base that no longer exists.

The board#

Agents is a kanban of every conversation, attention leftmost because the board's whole job is to tell you where you are needed.

The lanes are projections of what each agent is actually doing, not a status you set — so dragging a card doesn't assign a lane, it runs the action that would cause one. Dropping onto Finished lands a card that is ready, stops one that is running, or opens conflict resolution on one that is stuck. A drop with no action behind it is refused and the card springs back, which is the honest answer: there is no way to make an agent "be running" without sending it a message. A separate discard zone appears while a card is in flight.

Reviewing the work#

Open an agent and you get its cumulative output: everything the conversation has done since its branch was cut, per repo, as one flat change set with each file marked landed or not. It is deliberately not a staged/unstaged view — a worktree you never checked out has no index you could stage into.

Landing#

Landing takes the agent's delta and applies it to your main tree as uncommitted changes. They appear in your normal Changes panel, and your own commit is the review boundary. That is the whole model, and three consequences follow from it:

• Your history is never rewritten. Main's HEAD does not move when work lands; nothing is merged into it behind you.
• Landing twice is safe. Each land applies only what is new since the last one, so an agent you keep talking to keeps delivering increments.
• Nothing is ever lost. Whatever the worktree still held is committed onto the agent's branch first, so the branch stays a complete record even if the land itself does nothing.

When it conflicts#

If the patch cannot apply — you edited the same lines, or an overlapping file is dirty — then nothing lands for that repo and the card says so. The worktree keeps everything, and landing again works the moment you have resolved your side. Work that already reached the main tree by another road is specifically not treated as a conflict: an agent that committed onto the main line itself, or a branch you merged by hand, resolves as "already there" rather than stranding the card on a refusal nobody could act on.

Landing automatically#

Sandbox → Agent has an auto-land switch that lands every clean turn at completion. It is off by default, because the two mistakes are not the same size: work held on its branch costs one press to release, while work that landed unread has to be noticed before it can be undone. Individual agents can override the sandbox-wide setting, and an agent that never expressed an opinion follows the sandbox wherever you point it next.

It is a sandbox setting rather than a browser preference for a specific reason: agents opened by an automation, a webhook or a chat message finish their turns with nobody in the room, and a preference held in a browser could not govern them.

Asking for a land#

Collaborators may drive agents but not merge into your tree. When one presses land, the ask rides the agent's card so every maintainer's board sees who is waiting; the land or discard that answers it clears the request.

Finishing with an agent#

Finished agents are archived automatically after three days by default (Sandbox → Agent). That sweep is on where almost everything else is off, because a finished card is not a row in a list — it holds a full checkout of every repo, so a lane that grows forever is disk that grows forever.

Conversations that aren't isolated#

Not every conversation wants a branch. A chat you restore from the History menu runs on the shared /work tree, in the tree you are looking at — its tab reads "New chat" rather than "New agent". These have no branch, so there is nothing to land and nothing to discard; their edits are simply your working tree, the way an agent in a terminal would work.

Reach for isolation when you want work you can review before it touches anything, or when you want more than one agent going at once. Reach for the shared tree when you are working with the agent on what is in front of you.

Next#

• Automations & workflows: agents that start themselves, and multi-step runs.
• HTTP API: start an isolated turn, watch it, and land it from a script.