Tower mode

Tower mode turns one Jarvis Code session into a control tower for several agents working on the same repository at the same time. You state an objective; the main agent stops writing code and instead splits the work into missions, spawns a worker for each one in its own git worktree, spawns reviewers to audit their branches, and merges only what passes review.

Where goal mode drives a single agent toward an outcome across turns, Tower mode coordinates a fleet. Reach for it when a task naturally splits into parts that can proceed in parallel and would otherwise collide on the same files.

Experimental

Tower mode is an experimental feature and is off by default. It runs only on the default agent-core-v2 engine, it creates git branches and worktrees in your repository, and its protocol is still changing between releases. Do not use it on a repository you cannot afford to inspect afterwards.

Enable it

Tower mode is gated by the tower experimental flag. Turn it on in either of two ways:

JARVIS_CODE_EXPERIMENTAL_TOWER=1 jarvis

Or open /experiments in the TUI, enable Tower mode, and restart the CLI. A restart is required either way: the flag is read once when the engine assembles its features, so flipping it in /experiments mid-session does not create the tower tools until the next launch.

Once the flag is on, /tower appears in the slash command panel and a Tower mode row appears in /status.

Requirements

Tower mode drives real git operations, so the working directory must be a git repository with at least one commit. When it is not, the agent handles it as follows:

• Empty directory: it runs git init and creates an empty initial commit, then continues.
• Non-empty directory: it never stages everything blindly. It surveys the directory, shows you what it found, and asks once whether to initialize and commit. Under auto permission mode it cannot ask, so it stops and tells you the two commands to run yourself.

Missions fork from and merge back into a single base branch, recorded once when the workspace is created. By default that is the branch checked out in the main worktree. Only local branches are accepted; a remote-tracking ref such as origin/main cannot receive merges, so create a local branch first. While the main checkout sits on a different branch (or is detached), work proceeds but merges stay blocked until you switch back to the base.

Start a run

Write the objective after /tower:

/tower Split the renderer refactor across the build, shader, and test layers and land it on main

That single command turns the mode on and sends the objective as your next prompt. The agent then initializes the tower workspace, plans the missions, and launches the fleet without waiting for another turn from you.

To turn the mode on or off without sending an objective:

/tower on
/tower off

Tower mode can fail to turn on for three reasons, and the CLI tells you which: the experiment is off, the experiment was just turned on and needs a restart, or another session already owns this workspace's tower.

What happens during a run

The run has three roles.

You own the objective. You can speak, redirect, or add requirements at any time, and nothing in the run waits on you. Your messages are treated as plan changes, not as gates.

The tower is the main agent, and there is exactly one. It never writes product code. It plans missions, spawns workers and reviewers, routes messages, triages findings, merges branches, and reports back to you. Its orchestration tool calls still follow your session's permission mode.

Workers and reviewers are background subagents spawned by the tower on the tower-worker profile. Each worker owns one mission and works in its own git worktree under .tower/worktrees/; each reviewer audits one branch. They are pinned to the auto permission mode at spawn because they run unattended, and a session-wide permission switch never moves them off it. They cannot ask you questions — their profile has no AskUserQuestion — so they escalate to the tower instead.

The workflow the tower follows is fixed:

1. Init creates the .tower/ workspace and records the base branch.
2. Plan splits the objective into missions, typically two to four. Each mission gets an id (M1, M2, …), a branch named feat/<slug>, an isolated worktree, a set of scope globs, a task checklist, and optional dependencies on other missions.
3. Spawn launches one worker per dependency-unblocked mission, all at once rather than one at a time.
4. Supervise runs on every wake-up: the tower reads its inbox and the dashboard, spawns reviewers when work is ready, resumes authors whose reviews came back dirty, answers blockers, and triages findings.
5. Merge lands each branch through the merge gate, in dependency order.
6. Teardown removes the worktrees once every mission is merged or abandoned, and reports the final summary.

Scope isolation

Scopes are the mechanism that keeps parallel agents from colliding, and they are enforced by code rather than by instructions. Build missions must have pairwise disjoint scope globs — the planning tool rejects a plan whose scopes overlap — and the merge gate refuses any branch that changed a file outside its own mission scope. If a mission legitimately needs more room, only the tower can widen its scope, and the change is logged.

Read-only investigation missions are marked as surveys. A survey's scope is informational and reserves nothing, so surveys may overlap build missions; the worker must not change code, and the mission closes with a zero-diff merge and no reviewer.

The review gate

No branch merges without a clean review. The gate refuses a merge unless all of the following hold:

• The branch's latest review verdict is clean.
• That review was written against the branch's current tip. If the branch moved after the review, a fresh review is required.
• Every dependency mission has already merged.
• Every changed file falls inside the mission's declared scope.

When the gate refuses, the error names the next step: assign a reviewer, wait for fixes, re-review a moved tip, merge dependencies first, or widen the scope. After a successful merge, branches that now conflict must rebase onto the new base and be reviewed again.

Review loops are capped. At five rounds, or when two consecutive rounds report the same findings, the tower stops the loop, tells you, and redirects the work.

Monitor a run

Ask for the dashboard at any time:

/tower status

The dashboard lists every mission with its status and owner, the agent roster, the review-gate state of each unmerged branch (latest round, verdict, and whether the reviewed commit still matches the tip), your inbox count, and the tail of the activity log.

While the mode is active, the TUI footer shows a tower badge next to the other mode indicators, and /status carries a Tower mode row.

Every action by every participant is appended to .tower/comms/log/activity.log. When something looks wrong, that file is the first place to read.

Concurrency limits

Tower spawns are bounded by an adaptive budget rather than a fixed number. The budget starts unbounded and shrinks when the provider returns rate-limit errors, recovering one slot every three minutes up to a ceiling of 16 concurrent tower agents. After a rate-limit episode, new spawns pause for about 60 seconds; a successful request lifts the pause early. When a spawn is refused, the tool says whether it was the pause or the budget and what to do about it.

Worker model binding follows the subagent model pool: workers bind the configured secondary model when that experiment is on, and inherit the tower's model otherwise. Reviewers always bind the tower's primary model.

Finish a run

Ask the tower to tear down at any point:

/tower teardown

Teardown removes the mission worktrees and exits tower mode. Worktrees with uncommitted changes are kept and listed rather than destroyed, unless the tower is explicitly told to force it. Branches are kept. The .tower/comms/ directory — state, inbox, findings, reviews, missions, and the activity log — is always kept as the audit trail.

The tower is expected to tear down on its own as soon as every mission is merged and no inbox item is left unactioned, so /tower teardown is mainly for stopping early.

Workspace layout

Everything the protocol writes lives under .tower/ in the repository root:

.tower/
├── comms/
│   ├── state.json          # Tower workspace state
│   ├── MISSIONS.md         # Human-readable mission index
│   ├── missions/           # One file per mission
│   ├── inbox/              # Messages between participants
│   ├── findings/           # Structured findings filed by agents
│   ├── reviews/            # One file per review round
│   └── log/activity.log    # Append-only audit log
└── worktrees/              # One git worktree per active mission

Note

These files are written exclusively by the Tower* tools. Editing them by hand — directly or through a shell command — breaks the merge gate. Add .tower/ to .gitignore if you do not want the workspace tracked.

Resuming across sessions

Re-entering tower mode from a new CLI session adopts an existing workspace instead of resetting it. Missions, worktrees, and the activity log carry over; roster entries from the previous session are retired, because agent ids cannot be resumed across sessions.

Carried-over missions still reserve their scopes, so the tower settles them before planning anything new: it continues the ones that belong to the current objective with fresh workers, and abandons the rest. An abandoned mission stops reserving files, lets its dependents merge, drops out of conflict checks, and stays in MISSIONS.md as part of the audit trail.

Next steps

• Using goals — drive a single agent toward one verifiable outcome
• Built-in tools — the Tower* tool reference
• Slash commands — the full /tower command surface
• Agents and subagents — how subagent profiles and model binding work