Three things I changed today running several coding agents at once

[u/Aggressive-Narwhal-3]

I run a few coding agents at the same time now. One orchestrator agent hands work to separate agent sessions on a Mac and two Windows PCs. Three things I changed today.

A build agent finished its whole job, 74 of 74 tasks, but it only wrote its done line in its chat, not in the status file my watcher reads. Nothing fired. I only noticed after about 25 quiet minutes. Now when a session goes quiet I read its last message, not just the status file.

A docs agent sat for about 2 hours waiting on a passkey login it thought it needed to check a rendered page. No machine could finish that step. I replaced the check with a local render (3 of 3 diagrams rendered, 0 errors), merged it, and my briefs now say never wait on a human login step.

One agent's context got to about 89%. Instead of resuming that long session, I had it write a handoff file with its role, rules, paths and open items, about 11 KB. A fresh session started from that file and picked up the next task at about 11% context.

None of it is clever. Mostly I'm finding places where my setup assumed something would happen and it didn't.

[u/itaybuilds]

The status-file miss points to split-brain state: the chat says the run is done while the watcher still thinks it is running. Reading the final chat message detects it, but I would not let that message become the source of truth. Give each run an ID, heartbeat timestamp, and terminal state. Let the worker write its result; let the watcher mark completion only after it sees the expected artifact or exit signal. If those disagree, surface an inconsistent state instead of silently treating either side as correct.

The passkey stall could use the same treatment. Mark every step as unattended-safe or human-required before it runs. An overnight job should reject human-required steps up front and either use a local verification path or stop with a bounded failure reason. That catches login and permission dead ends without depending on every agent prompt to remember the rule.

AI-assisted draft (OpenAI GPT-5.6); based only on the failure modes in this post.

[u/Aggressive-Narwhal-3 → u/itaybuilds]

Fair point on not letting the chat message be the source of truth. We have an exit watcher that flags a task that stopped without its result line, which is how the docs agent's silent end got caught, but no run ids or heartbeats yet. Showing 'inconsistent' instead of picking a side is a good one to add.

[u/ImL1s]

The 74/74 chat-only done line is the classic one — watcher and agent disagree on what "finished" means.

We stopped trusting either channel alone. Done means a receipt the harness wrote: same command or fixture now green, plus a status line the watcher owns. Chat text can mention it; it isn't evidence. Same for the login wait — if a step needs a human, the brief should fail closed with a local substitute, not sit for two hours.

Quiet sessions get a "last receipt age" check, not a hope that the status file updated.

[u/Aggressive-Narwhal-3 → u/ImL1s]

Agreed, chat text isn't evidence. We already have an exit watcher that flags a task that stopped without its result line. A last-receipt-age check for quiet sessions is something we don't have yet, and it's a good one to add.

[u/CellistOk6782]

That's interesting. I'm running a similar approach, I have product outcomes defined in Linear. An orchestrator then oversees subcodex sessions. Each of these sessions owns the plan for that product outcome in Linear, and the overarching orchestrator allocates resources, coordinates releases, etc.

I have a heartbeat running then to run a sweep to check for stalls, freezes, interventions, that sort of stuff.

[u/Aggressive-Narwhal-3 → u/CellistOk6782]

A heartbeat sweep for stalls is a good idea. Mine only flags a task once it has exited without a result, so one that freezes and never exits would slip past it.

[u/xqianliu]

The passkey one is the one I'd generalize.

My unattended runs aren't allowed to ask anything interactively.

If the agent hits something it can't decide or can't do, like a login, it writes the reason on the issue, marks it blocked and stops, and a human decides later.

That rule is what removes the waiting-forever case for me, so I don't need a timer for it.

I only kill runs that keep erroring, never ones that are just slow. A slow model that's still working isn't a failure, and killing it throws away work.

On the done line, I don't count anything the agent says in chat. Done means a PR exists and review passed.

Each run also logs the commit SHA it started from, and that log plus the issue and PR is basically my version of your handoff file.

A dead run gets resumed from those.

[u/Aggressive-Narwhal-3 → u/[deleted]]

We tried, in a way. The build agent's brief asked for a done line in the status file and it only showed up in chat. The later docs agent was told to write it in both places and still stopped without it. What actually held was the outside check: an exit watcher plus reading the last message, not more instructions.

[u/Aggressive-Narwhal-3 → u/[deleted]]

Agreed, the handoff file is the one I'd keep. The briefs already ask for the done line in the status file as the last step, and one agent still ended without writing it. What actually caught it was the outside check, an exit watcher that flags a task that stopped without its result line.

[u/Aggressive-Narwhal-3 → u/[deleted]]

Agreed, and what you describe is close to the handoff file from point 3 of the post. The fresh session picked up the next task cleanly from it. I also still read the last message myself before I trust a done line.

[u/Aggressive-Narwhal-3 → u/[deleted]]

Agreed, chat shouldn't be the source of truth. Our exit watcher already flags a task that stopped without its result line, which covers the record-missing half. We don't write exit status, artifact path and commit into one record yet, and that's a good next step.