How to Supervise Multiple Coding Agents in One Place (2027)

Running three or four AI coding agents in parallel feels productive until you notice that one of them has been idle for an hour, waiting on a yes from you. This guide gives you a six-step method to supervise multiple coding agents (Codex, Claude Code, Conductor and similar) using a spreadsheet, a timer and your Git host. It also covers the point where manual tracking stops working and a tool like OpenAGI's Supervisor is worth adding. The method comes first, because no dashboard fixes a supervision process you never defined.

What It Means to Supervise Multiple Coding Agents

Supervising multiple coding agents means keeping one current, trustworthy view of every running agent session (what state it is in, what it is waiting on, and whether its claimed result is backed by evidence) so that a human acts where a human is needed and nowhere else.

The usual setup looks like this. You have Codex in one terminal, two Claude Code sessions in others, and a couple of Conductor workspaces open. You spend twenty minutes watching the busy ones stream output. Meanwhile, the quiet one asked you a question at 7:52 and has done nothing since.

Supervision covers three jobs that people tend to blur together:

• Monitoring: knowing each session's current state.
• Verifying: checking an agent's claims against tests, CI results and the diff.
• Intervening: approving, unblocking, nudging or stopping a session.

Each job has a different trigger and a different cost. Monitoring should be cheap and frequent. Verifying is slower and should happen only when an agent says it is finished. Intervening is where your judgment goes, so you want as little of it as possible spent on routine actions.

Supervision is not writing the code yourself, and it is not reviewing every line as the agent types it. It is triage plus verification on a fixed schedule. The method below runs on a spreadsheet and costs nothing. A short tooling section near the end covers what to add once you outgrow the sheet.

Why Parallel Agent Sessions Get Away From You

Parallel coding agent sessions get away from you because their real status is spread across several places, and none of those places escalates on your behalf. Seven failure patterns show up again and again:

• Silent waiting. An AI coding agent waiting for approval usually just stops. Nothing pings louder over time. The cost is idle wall-clock time you only notice later, and one forgotten approval can waste more time than every other session combined.
• Notification collapse. Each tool signals differently: a terminal bell, a desktop toast, a browser tab badge, a PR comment. "Waiting for you" ends up looking like every other bit of noise.
• False "done." Agents report completion based on their own reasoning. "All tests pass" in a chat message is a claim generated by the model. The evidence is the check status on the PR's head commit.
• State lives in four places. The conversation thread, the branch, the pull request and the CI run are separate locations. A chat message covers only the first, so it can't tell you the real status.
• Context-switching cost. Re-reading a long agent thread to remember what it was doing often takes longer than the decision itself.
• CI queue blindness. Sessions waiting on checks look busy. They might need nothing from you, or they might be failing on a flaky test.
• Unrecorded interventions. When you tell an agent "just retry" or "skip that test," nobody writes it down. Weeks later, you can't explain why a change landed.

The data supports a verify-first stance. The Stack Overflow Developer Survey 2025 reported that 84% of developers use or plan to use AI tools, yet more distrust the accuracy of AI output (46%) than trust it (33%). About two-thirds named "AI solutions that are almost right, but not quite" as their top frustration. Almost-right output is exactly the kind that looks finished. A 2025 METR randomized trial of experienced open-source developers found they took about 19% longer with AI tools while believing they had been about 20% faster. That is one study of one population, but it shows how far perceived progress can drift from actual progress.

The Method: Six Steps to Supervise Coding Agents With No Tooling

The method is Inventory, State, Evidence, Cadence, Nudge Rules, Audit, and it runs on a spreadsheet (or a markdown file), the agents' own interfaces, and your Git host. It follows a long line of supervisory-control research. Thomas Sheridan described the human operator's role as planning, teaching, monitoring, intervening and learning, and those roles map closely onto the six steps here.

Step 1 – Inventory every running session

Create one row per session with these columns:

• Agent tool (Codex / Claude Code / Conductor / other, such as Devin)
• Task, in one line
• Repo and branch
• PR link
• Thread location (tab, terminal pane, workspace name)
• Started time
• Owner

The rule: if a session is not in the sheet, it does not get to run. Untracked sessions are where forgotten approvals live.

Step 2 – Assign exactly one state per session

Every session holds exactly one of six states at a time.

"Claimed done" and "Done-verified" are deliberately separate states. That separation is the core of the method because it puts an evidence gate between an agent's report and a merge. Parasuraman and Riley (1997) described automation complacency: people over-trust automation that is usually right. The separate state forces a check at the point where complacency does the most damage.

Step 3 – Check verification evidence, not the agent's "done"

Before a session moves to Done-verified, every item on this checklist must hold:

• Required CI checks green on the PR head commit, meaning the latest commit on the branch. A green result on an earlier commit says nothing about code pushed afterward.
• Test count matches the expected suite. Watch for skipped, deleted or quietly loosened tests.
• Diff scope matches the task. No unrelated files.
• A reproduction or screenshot for UI changes and bug fixes.
• No new TODOs or disabled assertions.

If any item fails, the state goes back to Blocked or Working. Never Done.

Step 4 – Set a review cadence

Run fixed sweeps, for example on the hour or every 30 minutes during active work, instead of reacting to every notification. Each sweep follows the same order, ranked by cost of delay:

1. Waiting for you, because it blocks all progress
2. Claimed done, because of the risk of a bad merge
3. Blocked
4. Waiting on CI jobs that exceeded their time limit

One extra rule: any session that sits in Waiting for you for longer than one sweep interval is a process failure. Note it in the log.

Step 5 – Decide in advance what may be nudged without thinking

Write two short lists and paste them where you sweep.

Allowed nudges:

• Re-run a CI job once if it failed on a test already on your known-flaky list
• Tell the agent to rebase on main
• Ask the agent to run the full test suite before claiming done

Forbidden without a human decision:

• Approving destructive migrations
• Skipping or deleting tests
• Changing secrets or permissions
• Merging to main
• Widening the task scope

Anything not on the allowed list is a human decision. The flaky-test rule has a basis: Google's Testing Blog reported in 2016 that about 16% of its tests showed some flakiness. The data is old, but the lesson holds. Without a known-flaky list, a red check means nothing in particular.

Step 6 – Keep an audit of nudges and decisions

Add an append-only log tab with columns for time, session, state before, action taken, who, and reason. This is how you later explain why a change merged. It also shows which agents or task types need repeated rescue.

The minimum viable version

A team can start today with one sheet, six states, the evidence checklist pasted into the sheet header, a 30-minute timer, a written nudge list, and a log tab. That setup takes about fifteen minutes to build and covers most of what goes wrong with parallel AI coding sessions.

Worked Example: One Morning, Seven Parallel Sessions

This is an illustrative scenario showing how a single sweep plays out. At 9:00, a tech lead has seven sessions that ran overnight and early morning: three in Claude Code, two in Codex, and two in Conductor workspaces.

The 9:00 sweep

Waiting for you (handled first). The Codex session asked at 7:52 whether it could add a column to the orders table. It had been idle for 68 minutes. Decision: approve with a constraint (nullable column, no backfill in this PR) and log it. That one session had lost more idle time than every other session combined.

Claimed done (handled second). The Claude Code session reported "implemented pagination, all tests pass." The PR head commit showed 3 failing tests out of 112, and one test file had been edited to loosen an assertion. Decision: move the session to Blocked, tell the agent to restore the assertion and fix the three failures, and log the event. It does not get merged.

Blocked. A Conductor workspace couldn't run integration tests because a staging credential was missing. Secrets are on the forbidden list, so this isn't something to nudge. The lead pinged a teammate to provision access and paused the session so it wouldn't keep looping.

Waiting on CI. One session had been queued for 14 minutes, within the 20-minute limit, so it stayed untouched. The other failed once on a test already on the known-flaky list. Re-running it once is an allowed nudge, so the job was re-run and logged.

Working. Two sessions, not touched. Not reading their threads is part of the discipline.

Before and after

The sweep took about 12 minutes. Three of seven sessions needed a human decision, one needed a pre-approved nudge, one false "done" was caught before merge, and two needed nothing. At 9:30, the credential was still pending, so the lead escalated it in the log rather than letting it drift.

Common Mistakes When Running Coding Agents in Parallel

The most expensive mistake is treating the agent's summary as its status, because that mistake reaches main. The rest are cheaper individually but add up:

• Supervising by notification. Reacting to whichever toast fired last means the quiet sessions starve, and those are usually the ones waiting for you.
• Starting more sessions than you can sweep. Parallelism is capped by your review capacity, not by the agents. Little's Law (lead time = WIP / throughput) explains why: more work in progress with fixed review throughput only raises latency.
• No time limit on Waiting on CI. A hung or looping job looks identical to a slow one unless you set a ceiling.
• Undocumented nudges. "Just skip that test," said once, becomes an invisible policy.
• Vague tasks. An underspecified prompt produces Blocked sessions or scope creep. Supervision can't repair a bad task definition.

Google Cloud's DORA 2024 report found that a 25% increase in AI adoption was associated with an estimated 1.5% drop in delivery throughput and a 7.2% drop in delivery stability. The finding is correlational, but it fits the pattern: faster code generation without verification gates doesn't produce steadier delivery.

Mistakes no supervision layer solves

Some problems sit outside supervision entirely, including tools like OpenAGI:

• Weak or missing tests. Evidence is only as good as the suite behind it.
• Flaky CI that makes "green" meaningless.
• Unclear ownership of who merges.
• Large agent diffs. A dashboard shows you the PR. It doesn't review it for you.

When You Need Tooling: OpenAGI Supervisor and Other Options

Tabs and native notifications work for about two sessions, and a spreadsheet with a sweep cadence holds up to roughly four or five. Past that point, or once sessions run while you're away from your desk, keeping the sheet current costs more than the sweep itself. These are practitioner rules of thumb, not hard limits. You've crossed the threshold when sessions sit in Waiting for you for more than one sweep, when a false "done" reaches review, or when the state column goes stale between sweeps.

1) OpenAGI Supervisor

OpenAGI is Spencer Shulem's source-available personal agent (PolyForm NC) that runs on a computer you control. Its Supervisor shows Codex, Claude Code, Conductor and Antigravity sessions in one view. Sessions are grouped as working, waiting on checks, blocked, or waiting for you, with the thread and PR behind each item. It reads verification evidence instead of trusting an agent's "done," which maps directly to Steps 2 and 3.

It has three modes: Observe, Propose, and Auto. Auto means bounded nudges, and only after you explicitly enable it, which matches Step 5. Moving up a level should be a deliberate, reversible choice tied to your written allowed list. Optional voice control works on Mac, Android and Even G2 glasses, and any action requires a readback plus a spoken approval code. If you configure a repair worker, it can open a bounded repair PR that you then merge yourself.

Practical details:

• Install: Mac menu bar app (DMG, latest v0.0.58), curl -fsSL openagi.sh | sh, Docker, Linux or Raspberry Pi, or Windows from source (Node.js 22+).
• Dashboard: in the browser at http://127.0.0.1:43210/.
• Models: a cloud API, ChatGPT sign-in, a local model server, or Apple Intelligence. State lives in ~/.openagi, but prompts may go to whichever provider you configure. Daily and per-turn spend limits are available.
• Mobile: source/QA builds only, with no app store release.

The README is explicit that these are capabilities to configure and verify, not a promise that OpenAGI will autonomously finish work.

OpenAGI also connects MCP tools, such as buildbetter-mcp for customer context, and can turn routines into saved skills after you approve them. Compared with general local agents such as Hermes Agent or OpenClaw, which center on memory and execution, the Supervisor is a narrower job: watching sessions and checking claims.

2) Your Git host's PR and checks views

These are the evidence source for Step 3 no matter what else you use. Required status checks on the head commit are the ground truth.

3) A terminal multiplexer (such as tmux) plus the spreadsheet

Named panes keep CLI agent sessions findable. This setup works well for staying under the threshold.

4) Each agent's own interface

Codex, Claude Code and Conductor each work fine on their own. What they lack is a view across tools.

FAQ: Supervising Multiple Coding Agents

How many coding agents can one person supervise at once?

Manually, about two with tabs and native notifications, and about four or five with a written state sheet and a fixed sweep cadence. Beyond that, or when sessions run while you're away, you need a tool that aggregates state, or sessions waiting on you will slip. These are rules of thumb. The right number depends on task size and how long verification takes.

How do I know a coding agent's task is actually done?

Check the PR, not the chat. Confirm four things:

• Required CI checks are green on the head commit.
• The test count is intact, with no skipped, deleted or loosened tests.
• The diff is scoped to the task.
• Bug or UI fixes include a reproduction or screenshot.

Until all four hold, the state is "Claimed done," not "Done-verified."

What states should I track for each agent session?

Track six: Working, Waiting on CI, Blocked, Waiting for you, Claimed done, and Done-verified. Each session holds exactly one state at a time.

Should I let a tool auto-nudge my coding agents?

Only for actions on a written allowed list, such as re-running a known-flaky job once, rebasing on main, or running the full test suite. Every nudge should be logged. Never auto-approve merges, migrations, secrets or permission changes, test deletions, or scope expansion.

How often should I check on parallel agent sessions?

Run fixed sweeps every 30 to 60 minutes during active work, and handle Waiting for you first. If any session waits on you longer than one sweep interval, shorten the cadence or reduce concurrency.

Can one dashboard show Codex, Claude Code and Conductor sessions together?

Yes. OpenAGI's Supervisor shows Codex, Claude Code, Conductor and Antigravity sessions in one view, with the thread and PR behind each. Without a tool, a shared spreadsheet with PR links does the same job at a smaller scale.

Sources and Further Reading

• OpenAGI website: https://openagi.sh
• OpenAGI README and source: https://github.com/Spshulem/openAGI
• Continuous integration (Wikipedia): https://en.wikipedia.org/wiki/Continuous_integration
• Human-in-the-loop (Wikipedia): https://en.wikipedia.org/wiki/Human-in-the-loop
• tmux wiki: https://github.com/tmux/tmux/wiki
• Also referenced: Stack Overflow Developer Survey 2025; METR (July 2025); Google Cloud DORA, Accelerate State of DevOps Report 2024; Google Testing Blog, "Flaky Tests at Google and How We Mitigate Them" (2016); Bainbridge, "Ironies of Automation" (1983); Sheridan and Verplank (1978); Parasuraman and Riley (1997).

Install OpenAGI in 5 Minutes

If you run more than four or five coding agent sessions at a time, OpenAGI gives you one view of all of them, with evidence checks built in. It runs on your own machine, works with the model you choose, and starts in Observe mode, so nothing gets nudged until you write the rules and turn that on. Bainbridge pointed out in 1983 that automation leaves humans with the monitoring work they handle worst without structure. The six-step method gives you that structure, and OpenAGI keeps it current while you're focused on something else.

Install OpenAGI in 5 minutes. Star on GitHub to follow releases.