What brief and process shape lets cheap Sonnet helpers finish a pull request instead of dying halfway, when an orchestrator splits the work?

Hypothesis

The subagent context guard stops a runner that lives too long, and the autonomy sweep showed one runner per item can clear a backlog. The open question was the shape of a lane for a feature that is bigger than a backlog item. If the orchestrator splits a feature into narrow sequential steps and passes state through a file, cheap Sonnet helpers should finish what one big lane cannot.

What we built

• An orchestrator loop. The main session writes no feature code. Per ticket it makes a worktree from main, spawns a named Sonnet helper with a tight brief, spawns a separate Sonnet reviewer, applies fixes, then merges. Roughly three lanes at once, split by file area.
• A brief template. Issue link, exact file and line pointers, tests first, no shell cd, commit and draft pull request, never merge or touch secrets, and "if context runs low: commit, write the handoff, stop".
• Handoff files. Each lane keeps a short "state so far" note in a handoff folder, so a fresh runner can continue where a dead one stopped.
• Step splitting. A feature runs as sequential lanes: logic and tests, then components, then wiring and a draft pull request, then review, merge and live check.
• A Codex lane variant. For a week when the Claude subagent limit was hit, lanes ran codex exec directly in a worktree, with the report written to a file.

Learnings

• Lane size decided survival. In a dashboard build for the operations app, 4 of 9 Sonnet lanes hit the context guard. One died in setup because it loaded the long pull request and charting skills before writing a line. Others died taking a whole pull request (build, review and deploy). The lanes that worked had one narrow step plus a handoff file. The brief now says which long skills not to load and gives the needed steps inline.
• A background codex exec can hang on stdin. One of five background runs sat for 40 minutes on "Reading additional input from stdin" and wrote nothing. The rerun with < /dev/null finished in minutes. Every background Codex call now redirects stdin. If a report file is missing long after its peers, read the log tail before waiting more.
• Lanes waiting on background Codex miss the wake. A subagent that starts Codex in the background and "waits for the notification" goes idle and is not reliably woken. On 2026-10-15 this left 4 lanes idle for about 3 hours and one lane all night. The fix is to block in the foreground with a long timeout, or wait for the output file to appear. Waiting on a process name failed twice, because the watcher's own command line matched the pattern.
• Never reset the orchestrator while helpers run. Their reports are lost. The orchestrator hands over at about 300k tokens of context, when no helpers are in flight.
• Do not delete the base branch of stacked pull requests. On a diagram tool repository, merging a base pull request with --delete-branch closed the pull requests stacked on it. Merge the base without deleting its branch, or rebase the children onto main first. Better still, no stacked pull requests; see the autonomy sweep.
• Every independent review found something. In that session each reviewer pass on a lane returned at least one real finding, often data loss or an auth gap. Hosted review never posted on that repository, so the subagent review was the only gate.
• Differs from the guard entry. The guard limits one runner's lifetime. This entry is about how to cut the work so no runner needs a long life.

Log

• 2026-10-27: Box runs on cloud sandboxes (see the box experiment) reuse the same rules: one ticket, one box, a new box for a fix.
• 2026-10-26: Codex stdin hang found and fixed; the idle-lane wake problem re-checked and two more process-matching pitfalls recorded; the stacked branch delete incident recorded.
• 2026-10-24: Dashboard build ended with 4 of 9 lanes stopped by the guard. Step splitting and handoff files became the rule.