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 default is what makes 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. Object stores are shared, so a worktree costs a checkout rather than a clone. The composition is frozen at creation: a repo you clone later does not join a conversation already running.

The agent sees its worktree as /work#

Every absolute path an agent inherits: from a memory, an AGENTS.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 wander into the shared tree by accident, and nothing has to be remembered or refused. Writing to the main tree is still possible when it needs to compare against main or read a sibling repo; it just no longer happens by mistake. Two things are shared rather than copied: daemon state (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 it. If the rebase would conflict it is rolled back and the turn runs from where it was. This is why a resumed conversation reads today's code instead of writing a delta against a base that no longer exists.

When an agent delegates#

Parallel agents do not have to be opened by a person. A turn may split its own work into children, and intentic follows two different mechanisms on one Subagents roster:

Runtime subagents#

A runtime-native child stays inside the provider's own agent loop. The daemon listens to that harness's task and lifecycle events, reads the child's transcript when the runtime exposes one, and nests its thinking and tool calls under the parent card. This is the lightest way to research or divide a task when every child should work in the same checkout.

Full child agents: the meta-harness#

The meta-harness sits above vendor runtimes. A Claude turn can start Cursor, a Codex turn can start Claude, and a shell-capable ACP agent can start either, because the child enters through the daemon's ordinary conversation engine rather than through the parent's SDK. It is watchable from another window, stoppable like any agent, independently reviewable, and allowed to outlive the turn that started it.

Claude Code receives spawn and wait as agent tools, Cursor receives equivalent custom tools, and every runtime with a shell receives the same service through the agents command:

agents providers                        # what is connected, and what allowance is left

agents spawn --provider cursor --model composer-2.5 --description "Port the parser" \
  'Port packages/parser, update its tests, and report the files you changed'

agents wait <child-id>                  # until it needs input or finishes
agents answer <child-id> 'Use TOML 1.0' # factual questions only
agents send <child-id> 'Also cover CRLF input'
agents list

A child sees none of the parent's chat, so its task must carry the paths, requirements and constraints it needs. Spawn returns as soon as the child is running. Wait sleeps until a child needs input or finishes instead of making the parent poll; Send steers a live child or starts a follow-up turn on a settled one, continuing that child's session.

A spawn names its provider and its model. Neither is optional and nothing is chosen for you: a child is a whole agent session against a real allowance, started by a model rather than by you, and one parent can start twenty of them in a turn. Providers answers what that spawn may name — every connected provider, its models, and how much allowance each still has, with the ones whose every account is at its cap left out, so what it lists is what can actually run.

Supervision stays above the tree#

Sandbox → Agent → Subagents sets three ceilings: children running at once, child turns per parent, and spawn depth. Native runtimes receive those limits through their harness. For full child agents the daemon enforces them at the spawn door rather than writing them into a prompt, so a child that can spawn another child cannot route around them. Persona and action rules decide which conversations receive the spawn doors at all.

A parent may answer a child's factual question. It may not approve the child's permission request or plan: those cards remain yours, because letting a model approve its own held action through another model would erase the approval boundary. The same guard that protects other agent actions can hold delegation after a turn has consumed untrusted outside content unless you explicitly allow it.

Full children can also run on remote runners. When no machine is named, the fleet scheduler spreads them across ready capacity and falls back to this sandbox when every runner is busy.

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: there is no way to make an agent "be running" without sending it a message. A 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 not a staged/unstaged view; a worktree you never checked out has no index to 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#

Before writing anything, landing checks every repository the conversation spans. If any patch cannot apply because you edited the same lines or an overlapping file is dirty, then nothing lands anywhere and the card names the repository and paths that stopped it. Every worktree keeps everything, and landing again works the moment you resolve your side. Work that reached the main tree by another road is not a conflict: an agent that committed onto the main line, or a branch you merged by hand, resolves as "already there" rather than stranding the card.

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 first. Individual agents can override the sandbox setting, and one that never expressed an opinion follows the sandbox.

It is a sandbox setting rather than a browser preference for a reason: agents opened by an automation, a webhook or a chat message finish their turns with nobody in the room, and a browser preference 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 sees who is waiting, and the land or discard clears it.

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, and 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 or discard; their edits are your working tree, as 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.

Related pages

• Automations & workflows: agents that start themselves, and multi-step runs.
• Remote runners: placing isolated conversations and child agents on another machine.
• Models & accounts: the provider and harness a full child may choose independently.
• One agent: start an isolated turn, watch it, and land it from a script.
• Guide: running agents in parallel: the same problem without assuming intentic, worktrees and containers weighed against each other.