subagent-strategy.md covers agent reuse well at the level of a single follow-up — same files, next round of the same loop, subsystem pooling. What it does not cover is the pattern that emerged over a long multi-PR session: keeping a small standing roster of named reviewer and implementer agents alive across a whole series of PRs, where the value is accumulated domain knowledge rather than cached file reads.
What happened
A session shipped 26 PRs across an auth/permissions subsystem, a provider layer, and CI. Agents were kept alive across many PRs each rather than spawned per task:
- One reviewer covered four PRs in the same subsystem. By the third it was catching defects in the fixes — a fix that closed the less-reachable half of a bug, and a guard that introduced a false refusal for every seeded group — because it had built a model of how that subsystem fails, not because it had the files cached.
- One implementer shipped four PRs in the same package. Having learned on one PR that a wildcard-carrying scope must be tested with
len(...) == 0 rather than an IsUnrestrictedAccess(...) helper, it applied that proactively to the next PR's identical fix without being told. A fresh agent would have repeated the defect and needed another review round.
- A reviewer that found a bug on one PR was then the natural verifier for the same fix applied to a sibling PR — it re-derived the finding in minutes because it already knew the shape.
The cost side is real too: two agents eventually declined further work on context-depth grounds, and both handed over cleanly rather than degrading silently. That turned out to be more valuable than the extra task would have been.
The gaps
1. No guidance to establish a standing roster. The current framing is per-follow-up ("before any spawn, check whether a warm agent exists"). Nothing says: at the start of a multi-PR session, stand up a small named roster — typically one reviewer and one implementer per active subsystem — and route work to them by name for the session's duration.
2. Delta briefings only cover the task, not the world. The guidance says to send "just the delta". In practice a long-lived agent also needs the environment delta: the base branch has moved, the CI contract changed, another agent holds a file it is about to edit, a claim it made earlier has been retracted. Omitting these produced repeated collisions and rework.
3. No handoff protocol when an agent winds down. Two clean handoffs in this session shared one property worth codifying: they pinned the baseline in both directions rather than describing it. One handoff recorded both rows of a mock/production divergence — the failing row and the passing-by-coincidence row — with the note that a fix tightening until the failing row passes, without checking the other, swaps one wrong answer for another and stays green. A handoff that pinned only the failing row would have led the successor to a wrong fix.
4. Nothing says an agent should flag its own context depth. The orchestrator-side signal exists ("polluted or bloated context → spawn fresh"), but there is no instruction for the agent to self-report, and no statement that declining on those grounds is a good outcome. Both agents that did it framed it apologetically.
Proposed direction
A new subsection in subagent-strategy.md under the existing reuse section covering: standing rosters for multi-PR sessions; what belongs in an environment delta; the handoff contract (pin baselines both directions, name the axis verified, state what is not covered); and an explicit statement that an agent flagging context depth and handing over is preferred to one that continues until quality degrades invisibly.
Happy to open the PR.
subagent-strategy.mdcovers agent reuse well at the level of a single follow-up — same files, next round of the same loop, subsystem pooling. What it does not cover is the pattern that emerged over a long multi-PR session: keeping a small standing roster of named reviewer and implementer agents alive across a whole series of PRs, where the value is accumulated domain knowledge rather than cached file reads.What happened
A session shipped 26 PRs across an auth/permissions subsystem, a provider layer, and CI. Agents were kept alive across many PRs each rather than spawned per task:
len(...) == 0rather than anIsUnrestrictedAccess(...)helper, it applied that proactively to the next PR's identical fix without being told. A fresh agent would have repeated the defect and needed another review round.The cost side is real too: two agents eventually declined further work on context-depth grounds, and both handed over cleanly rather than degrading silently. That turned out to be more valuable than the extra task would have been.
The gaps
1. No guidance to establish a standing roster. The current framing is per-follow-up ("before any spawn, check whether a warm agent exists"). Nothing says: at the start of a multi-PR session, stand up a small named roster — typically one reviewer and one implementer per active subsystem — and route work to them by name for the session's duration.
2. Delta briefings only cover the task, not the world. The guidance says to send "just the delta". In practice a long-lived agent also needs the environment delta: the base branch has moved, the CI contract changed, another agent holds a file it is about to edit, a claim it made earlier has been retracted. Omitting these produced repeated collisions and rework.
3. No handoff protocol when an agent winds down. Two clean handoffs in this session shared one property worth codifying: they pinned the baseline in both directions rather than describing it. One handoff recorded both rows of a mock/production divergence — the failing row and the passing-by-coincidence row — with the note that a fix tightening until the failing row passes, without checking the other, swaps one wrong answer for another and stays green. A handoff that pinned only the failing row would have led the successor to a wrong fix.
4. Nothing says an agent should flag its own context depth. The orchestrator-side signal exists ("polluted or bloated context → spawn fresh"), but there is no instruction for the agent to self-report, and no statement that declining on those grounds is a good outcome. Both agents that did it framed it apologetically.
Proposed direction
A new subsection in
subagent-strategy.mdunder the existing reuse section covering: standing rosters for multi-PR sessions; what belongs in an environment delta; the handoff contract (pin baselines both directions, name the axis verified, state what is not covered); and an explicit statement that an agent flagging context depth and handing over is preferred to one that continues until quality degrades invisibly.Happy to open the PR.