How to manage multiple coding agents without watching every terminal.

(1)Partition

Split along stable boundaries.

Good parallel tasks have minimal overlap and independently testable outcomes. Routes, components, migrations, test suites, documentation, and investigation work often divide cleanly. A broad “improve the app” task does not.

• One outcome per session.
• Explicit file or subsystem ownership.
• A named check that proves completion.
• A stopping rule for uncertainty or scope expansion.

Task:      Add rate limiting to the /login routeOwns:      src/routes/login.ts, src/middleware/rate-limit.tsDone when: npm test -- login passesStop if:   the change needs a schema migration

(2)Isolate

Use separate workspaces for separate writers.

When agents edit concurrently, separate branches or worktrees reduce accidental overwrites and make each diff reviewable. Shared state is appropriate for read-only research; simultaneous edits to the same files are a coordination failure.

Several of the tools above create the worktree for you: agent-manager, canopy, agent-view and Agent of Empires all have a worktree option.

git worktree add ../finance-app-auth -b agent/auth
git worktree add ../finance-app-docs -b agent/docs
cd ../finance-app-auth && claude

(3)Observe

Route attention by state, not by window.

Every session is in one of a few states, and only some of them need you. Session managers name them slightly differently (agent-view uses Running, Waiting, Idle, Stopped and Error), but the split is the same.

• Running: working on its own. Leave it alone.
• Waiting for input: it asked a question. Needs you.
• Blocked on approval: a permission prompt. Needs you, often quickly.
• Failed: a test, build or API error stopped it. Needs you.
• Done: ready for review. Needs you when you next have review time, not right now.

(4)Integrate

Review one result at a time.

Inspect the diff, run the required checks, resolve conflicts deliberately, and record what was accepted. Only then close the session or assign follow-up work. This keeps finished work from piling up unreviewed.

(5)Dashboard or voice

A dashboard needs a glance; a voice reaches you away from the screen.

A session manager is the better tool when you are at the screen: you see every session at once, and several let you review diffs, create worktrees or approve from a phone. You still have to look at it, or catch its notification banner.

A voice layer is the better tool when your eyes are on something else: another editor, a document or the kitchen. It tells you which session changed state without you looking. Heard does this for Claude Code and Codex on a Mac. You can use both: the list for review, the voice for knowing when to look.

(6)With Heard

What Heard says when several sessions run.

With two or more sessions running, questions, failures and results come through as they happen, and routine activity is batched into short summaries that start with the project name. To choose the spoken name, add label: My Project to the repo’s .heard.yaml. The listening mode sets how much you hear.

• Co-pilot: short updates while you are at the screen.
• Companion: fuller narration when you step away.
• Focus: quiet until an agent needs a decision from you, such as a question, an approval or a failure. Switch to Focus as the number of sessions grows.

(7)Reply

Answer the right session without finding its window.

On Heard Power, hold right ⌘ and start with the agent’s name, for example “Claude, run the tests again”, and Heard delivers it to that session. If two sessions match, Heard asks which one. In Co-pilot and Focus your words are typed into the agent’s input for you to review and send; in Companion they are sent after a short pause. For the Codex desktop app, Heard also lists your threads, jumps you to the right one and can type your reply into its composer.