Agent Manager - the fastest AI workflow

Go · tmux · Apache-2.0 · macOS, Linux, and WSL

The fastest workflow for every AI coding agent.

agent-manager. Everything is one keypress. Spawn one in a sentence, answer a blocked one without attaching, review its diff without leaving the list. Each session runs your own installed CLI as-is: your login, your config, your MCP servers, every feature it ships.

$ brew install yoanwai/tap/agent-manager

Animated demo: three running agents are answered from the quick prompt bar one after another, then five prompts send five fresh agents to work without the cursor leaving the tree, each row named by the prompt it was given, and the last one's diff opens in review. — Three agents answered, five more sent to work, one key each. All of it without leaving the list.

space

Every task gets its own agent, seconds apart.

A sentence is the whole ceremony. Hit space on a group row, type the task, press enter: that agent is already running, with your prompt embedded and the group's directory set. No form, no cd, no naming. The bar clears and stays open, so the next task goes to the next agent immediately, in a different project if you want. On a session row the same key answers an agent that is already working. When the work needs its own branch, alt+w in the same bar spawns the agent into a fresh git worktree.

space One sentence, one agent

Type what it should do, press enter, repeat. They go out as fast as you can describe them, each already working, across as many projects as you keep open, and you never left the list to start them.

tab A different tool per spawn

Cycle claude, opencode, codex, grok, gemini, pi, hermes or anything you configured without leaving the bar. The footer shows which one the next enter will start.

space Answer in place

On a session row the same key sends your reply into that agent's pane as a user message, so a blocked agent never costs you an attach.

auto They name themselves

A session starts as claude-a1b2 and renames itself once the agent knows what the work is, so a screen of them still reads as a list of features.

mcp Agents spawn agents

An agent can work the same list you do: spawn a session on its own task, read another one's screen, message it, and wait on one before taking its next step. Repo work takes a worktree each, and sessions sharing a checkout declare the files they are about to edit, so an overlap surfaces before either commits. The tools they call.

Six states, and for Claude Code they arrive from its own hook events rather than from guessing at the pane. How detection works.

workingMid-turn. Editing, running tests, thinking.

waitingBlocked on you. A permission prompt or a question.

finishedTurn complete, nothing pending.

erroredThe agent reported a failure.

idleAlive at a prompt with nothing to do.

deadSession ended. The row and its history stay.

Animated demo: space opens the prompt bar and three sessions in a row are answered straight into their panes, each turning from finished to working, then the cursor lands on a group and five more agents are spawned into it from the same bar. — The reply lands in the agent's pane as a user message, and on a group the same bar spawns. No attach, no tab switch.

The sessions view: twenty-odd agent sessions grouped under backend, its api subgroup, frontend and infra, each with a colour-coded live status, a real Claude Code transcript in the preview on the right, and machine gauges at the bottom left. — A folded group keeps its per-status counts, so a collapsed subtree still says whether anything under it needs you.

However many you run, it still reads as a list of projects.

Groups are paths, not folders. backend/api/auth nests as deep as the work does, sessions live at any node, and everything you arrange stays arranged across restarts. Fold what you are not looking at, archive what is finished, and the fleet stops looking like a wall of processes.

↵ Fold, and still know

A folded group keeps a count per status on its row, so a collapsed subtree still says whether anything under it is blocked on you. F folds or unfolds the whole tree at once.

g Nest as deep as you want

Make a subgroup inline while spawning, give it a default path, and every agent started there lands in the right directory.

K J Order that sticks

Reorder sessions among their siblings or whole groups among theirs. m moves a session elsewhere, and the arrangement survives a restart.

a Archive the finished ones

Park a session, or a group and its entire subtree, out of the view. Archive ends the process and keeps the last preview; u resumes it, and t shows what is parked. Groups in full.

The arrows walk the same tree sideways: → steps into the row under the cursor, focusing the session or opening the group, and ← steps back out, closing the group or leaving a focused agent from the head of its prompt. The pair is in beta, and Settings has a row that turns it off.

The shells you keep next to the agents live here too: T opens a terminal under the selected agent, or in the selected group, for builds, Git, and one-off commands. A nested shell is named after the session it hangs under.

Animated demo: a group folds down to one row keeping its per-status counts, the whole tree folds and unfolds at once, a session is reordered among its siblings, then archived and found again in the archived view. — A folded subtree still says whether anything under it is blocked on you.

ctrl+r

Review mode, one key from the list.

The manager becomes a reviewer. ctrl+r takes the whole screen for the selected session's repo: changed files with +/- counts on the left, the entire file on the right, syntax highlighted with the changed lines tinted, and its own keymap while you are in there. It refreshes as the agent keeps editing, and esc puts you back on the row you came from.

A session's directory is often an umbrella folder holding a dozen repos, so the agent settles it rather than you: through the MCP tools it declares the repo or worktree it moved into and the branch its work merges into, both validated against git, and review opens there. Nothing declared? Dirty working trees rank first, then the most recent commit. How it resolves.

Animated demo of the review screen: line comments written on two changed Go files, each file marked reviewed as it is finished, the drafts sent to the agent as review round one, then the layout switched to unified and a further comment sent as round two.

auto It targets itself

The agent's declared repo and merge base win over the ranking; worktrees are found wherever they live on disk.

r b B Or you take over

Pick the repo, the branch from its worktrees, or the target the diff compares against. Your pick wins for as long as the manager runs.

s Four scopes

Uncommitted, versus the merge target, the last commit, or staged, so the same screen works before and after a commit.

u Split or unified

Toggle the layout in place, cursor held on the same source line. n jumps to the next change.

Then the part the others on the comparison only do in a browser:

Comment a line, and the agent gets your notes. c writes a note on the line under the cursor and they stay on the review screen until you send them. C flattens every note into one review prompt and delivers it into that agent's pane, so it starts on your feedback while you watch the diff update. The review loop.

Kill it for the RAM. Revive the same conversation.

The process and the record are separate things, so ending one never costs you the other.

x Kill, keep the row

The tmux session ends and the RAM comes back. The row stays, marked dead, name and conversation id intact.

v Revive, same thread

Relaunches on that exact conversation through the tool's own resume command, not a fresh one.

↑ The row remembers

A killed session still shows the snapshot of its pane from when it had one, so the row says what the agent was doing when it stopped. More.

f Fork the thread

A named sibling continues the same conversation, so one copy explores an idea while the original keeps working. Each fork is a full session of its own, review included.

Animated demo: x on a group ends every session under it and the rows stay, marked dead with their snapshots intact, then v relaunches the whole subtree, each session back on the conversation it was holding. — The process and the record are separate things, so the RAM comes back and the thread does not.

tab

The agents it knows, and any CLI you add.

Every spawn is the tool you already installed, launched with the config, login, and subscription it already has. tab cycles the tool the next spawn will use. Live status ships for these:

Claude CodeOpenCodeCodex Grok BuildGemini CLIPiCommand CodeHermes Agent+ any CLI

Anything else runs as a session immediately, and earns the same status the moment you describe it. The whole block.

config.toml

[tools.mytool]
command = "mytool"
default_status = "idle"
rules = [
  { state = "working", pattern = "esc to interrupt" },
  { state = "errored", pattern = "(?im)^\\s*error:" },
]

The manager registers its own MCP server into every session it spawns, so the agent can drive the workspace: spawn a teammate, send it a message, wait until it is done, and open a terminal the user can watch. How registration works.

create_sessionStarts another agent on a named task, in its own worktree if the work needs one.
send_sessionQueues a message for another agent, delivered once it is at rest.
create_terminalOpens a shell under the caller for work the user should see.
reviewDeclares the repo, merge base and diff scope so review opens in the right place.

Questions

What is agent-manager?: agent-manager is a terminal UI written in Go that runs every AI coding agent as a live tmux session. Each row in its list is a real tmux session running a real coding CLI, coloured by what that CLI's pane is doing, so a fleet of agents is read, answered and reviewed from one screen.
Which coding CLIs does agent-manager support?: Claude Code, Codex, OpenCode, Grok, Gemini, Pi, Command Code and Hermes ship with working status detection. Any other coding CLI becomes a managed session by describing it in one TOML block, because status is a set of regexes over the text tmux returns.
What does agent-manager cost?: Nothing. It is free and open source under the Apache-2.0 licence, with no account, no licence key and no paid tier. The coding CLIs it runs are billed by their own vendors.
Which platforms does agent-manager run on?: macOS and Linux on both amd64 and arm64, and Windows through WSL2. It needs tmux 3.1 or newer and git.
How do I install agent-manager?: brew install yoanwai/tap/agent-manager on macOS or Linux. There is also an install script, an AUR package, mise, go install, and prebuilt binaries for every release.
Can an agent drive agent-manager?: Yes. The binary carries an MCP server that registers into every MCP-capable session it starts, so an agent can spawn other agents, message them, wait on them, claim shared tasks, reserve files and drive terminals on the developer's own machine.

Quit. They keep working.

Sessions live on a private tmux server named agentmgr, so they never mix with the tmux you run yourself and a kill-server on your own socket leaves them alone. Close the manager, close the laptop: they are still there when you come back.

Not here yet: cost tracking and mouse-driven list navigation. If one of those is what you came for, the comparison says which project does it.