Agent Tower: a Kanban dashboard for Claude Code, Codex and Gemini CLI tasks

The problem Agent Tower targets: too many agent terminals

The README's "Why I Built This" section is unusually candid about the origin. Running several Claude Code sessions at once produced visual chaos (which window is doing what), edit conflicts when two tasks touched the same files, no way to check progress away from the desk, and token bills that grew with every extra session. The author tried Git Worktree manually and found the split, rebase and merge commands tedious.

So the audience is narrow and specific: a developer who already runs more than one CLI coding agent and wants a single page showing projects, tasks, agents, output and diffs. It is not a general CI system, not a hosted service, and not a replacement for the agents themselves. It is a supervisor that spawns them, isolates their files, and shows you what they did.

How the server, PTY pipeline and MCP server fit together

The architecture diagram in the README splits the system into a React browser client and a Fastify server. The client holds a Kanban board, a terminal, a code editor and a Git changes view, with TanStack Query for server cache and Zustand for UI state. It talks to the server over HTTP REST and Socket.IO on the /events channel.

On the server side there are three exposed surfaces: a REST API described as 16 routes, the Socket.IO realtime channel, and an MCP server for agent integration. Below those sit services for session management, workspace handling, Git and worktree operations, and notifications and tunnels. The piece that actually runs an agent is the AgentPipeline, which the diagram labels as PTY plus Parser plus MsgStore: a pseudo-terminal runs the CLI, a parser turns its output into structured messages, and a store keeps them for the UI.

That PTY layer is the reason the supported list is a list of CLIs rather than a list of model APIs. Agent Tower drives whatever the agent's terminal interface emits, so adding a backend means supporting its output format, not just its HTTP API. It also means the tool inherits each CLI's own authentication, configuration and quirks, which is why the Docker compose file mounts ~/.codex, ~/.claude, ~/.gemini and ~/.cursor directories rather than passing only API keys.

Installing Agent Tower globally and starting the first task

The README recommends the global npm install as the simplest path. The prerequisite is Node.js 22.19.0 or newer, which matches the engines field in package.json.

npm install -g agent-tower
agent-tower

After the second command the server starts and the dashboard is available at http://localhost:12580, the port used throughout the README, the Dockerfile and docker-compose.yml. From there you create a task, pick an agent from the supported backends, and start it. The README states that output, progress and code changes appear in real time, and that a finished task moves to Review automatically so you decide whether to merge.

If you want Claude Code to read and claim tasks from the board itself, the README gives an MCP configuration:

{
  "mcpServers": {
    "agent-tower": {
      "command": "agent-tower-mcp",
      "args": [],
      "env": {
        "AGENT_TOWER_INTERNAL_TOKEN": "${env:AGENT_TOWER_INTERNAL_TOKEN}"
      }
    }
  }
}

The README is explicit that when an access password is enabled, MCP calls authenticate with AGENT_TOWER_INTERNAL_TOKEN instead of browser cookies, and that you should copy the generated config from Agent Tower's settings or pass the value through your MCP client's secret mechanism rather than hard-coding it in a shared file.

Building from source uses pnpm, not npm. The README lists two commands, and package.json shows the setup script installs dependencies and builds the shared package first:

git clone https://github.com/agent-tower/core.git
cd agent-tower
pnpm setup
pnpm dev

The repository pins pnpm 11.18.0 in package.json, while the Dockerfile defaults to PNPM_VERSION 10.24.0. If you build the image yourself, that mismatch is worth knowing about before you debug a lockfile error.

Team mode and the 48-hour claim

Team mode is the feature that distinguishes Agent Tower from a plain task runner. Agents join a shared group chat as independent members: a lead breaks down the task, an implementer makes changes, a reviewer inspects quality, a tester verifies. The README argues that keeping each agent a separate member stops one agent's long context from contaminating the others. When the work completes, the task moves to Review.

The README also says that in the author's own testing, teams have collaborated continuously for as long as 48 hours on complex tasks. That is a self-reported figure from the project author, not an independent benchmark, and the README does not describe the hardware, the task, or how success was measured. Treat it as a claim about what the design permits, not as a performance guarantee. What is verifiable from the repository is the mechanism: separate members in one chat, a lead role, and a Review gate at the end.

Where Agent Tower gets in the way

The worktree isolation that solves edit conflicts also changes your Git workflow. Every task gets its own branch and its own directory, and the README describes a one-click merge back to main after line-by-line review in the diff viewer. That is fine for a task that finishes cleanly. It is less fine when two tasks both need to touch the same migration file, or when a task's branch drifts while you review another. The tool removes the conflict between running agents; it does not remove the merge you still have to perform.

There is also a versioning problem. The newest release listed is v0.6.0-beta.4 from 2026-08-03, preceded by v0.5.4-beta.10 and v0.5.4-beta.9. Every tag in that list carries a beta suffix, and the package.json in the repository still declares version 0.1.0. Anyone who needs a stable, long-lived interface should assume the API and UI are still moving.

Finally, the tool depends on the CLIs it drives. If a backend changes its terminal output, the AgentPipeline parser is what breaks, and the README does not document a fallback for that case. The repository does not document rollback behaviour for a merge either. If your agent of choice is not on the supported list, Agent Tower is simply the wrong tool, not a partially working one.

Agent Tower compared with running agents in tmux or a CI runner

The closest alternative is what the README's author was doing before: several terminals, or tmux panes, plus manual git worktree commands. That approach has no server, no board, and no MCP surface, but it also has no dependency on Node 22.19.0, no port 12580, and no upgrade cycle. If you run exactly one agent at a time, tmux is strictly less machinery.

The other comparison is a CI runner such as GitHub Actions. A CI job is triggered by a commit and produces a log; it does not hold a live PTY, does not let you watch a task move from Running to Review, and does not give an agent an MCP endpoint to claim work from. Agent Tower is interactive and stateful; CI is not. If your work is "run the test suite on every push," Agent Tower is the wrong category. If your work is "keep three agents busy on three features and review what they produce," it is the right one.

The Docker path is a third option worth naming separately. docker-compose.yml builds an image that installs Codex, Claude Code and Gemini CLI at pinned versions (0.142.4, 2.1.196 and 0.23.0 by default) and exposes port 12580. That is the cleaner choice on a machine where you do not want three global npm installs, at the cost of mounting your CLI auth directories into the container.

Maintenance, licence and what the beta tags mean for upgrades

The repository is not archived, and the last push was on 2026-08-11, roughly a month before this writing. The release cadence in the listed tags is fast: two tags on 2026-07-17, one on 2026-08-03. That pace is good news for fixes and bad news for anyone who pins a version and expects it to stay put.

Agent Tower is licensed under Apache-2.0, stated in both the repository metadata and package.json. Apache-2.0 is a permissive licence that includes an explicit patent grant, which matters if you plan to ship it inside a company. It does not tell you anything about the licences of the agent CLIs the tool drives, and the Dockerfile installs those separately. If you redistribute a container image with Codex, Claude Code or Gemini CLI baked in, their terms are a separate question from Agent Tower's.

The practical upgrade cost is the worktree format and the data directory. docker-compose.yml sets AGENT_TOWER_DATA_DIR to /data and mounts a named volume there, so task history and settings survive a container rebuild. Whether a beta upgrade migrates that data cleanly is not documented in the README, so back up the volume before moving between beta tags.

Editorial conclusion

Adopt Agent Tower if you already run two or more CLI agents in parallel and want one board, per-task Git worktrees, and an MCP surface instead of a desktop full of terminals. Skip it if you work on a single repository with one agent, because the worktree and merge step adds work you do not need. Before installing, check that your Node version is at least 22.19.0, that the agents you use are among the supported backends, and read the release notes for the beta you pin, since v0.6.0-beta.4 is the newest tag listed and the repository has no stable release line yet.

Frequently asked questions

Official sources

1. agent-tower/core on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases