A manager loop is a coding agent whose job is to steer another coding agent. One agent holds the plan, a second agent does the work, and the model ends up doing the steering a person would otherwise do by hand. Matt Shumer named the recipe in September 2026 after using it to drive long-horizon Codex builds: launch a manager, have it write a phased checklist, spawn an implementer in a separate thread, and hand it phases one at a time until the work is done. Hraness keeps a reading digest of the original post. The sections below explain why the split helps, which parts of the recipe rest on evidence and which on hunch, how the pattern fails, and what happens when the manager grows from one session into an organization.
The problem a manager solves
Long-horizon tasks break coding agents in a specific way. The model can still do the work, but it loses track of which work matters. Shumer’s account is that Astra got much further than earlier models and then started to asymptote: progress against the goal slowed, and the agent sank into minutiae, polishing details that no longer moved the task. A person watching the transcript can see it happening and nudge the agent back to the next real step. That nudge is the expensive part. On a build that runs for hours or days, the human who steers every drift becomes the bottleneck.
The manager loop removes the person from that seat without removing the steering, because the steering itself is a task a model can do. Reading a checklist, checking what the implementer finished, deciding whether a phase is done, and writing the next instruction are all work inside a context window. If a person can do it from the transcript, an agent holding the same plan can do it too.
How the recipe works
Plan before work. The manager’s first job is to break the goal down before it hands anything off. Shumer has the manager chat about the goal, write a massive checklist, and break it into phases before any implementer starts. The plan is written up front, which is also its known weakness: some of it will be wrong, and the recipe’s untested extensions all address what happens when it is.
Two contexts, two jobs. The implementer’s window fills with diffs, tool output, and test failures. The manager’s window holds the checklist and the phase reports. An agent asked to both do the work and judge the work watches its own context fill with noise until the plan is the least visible thing in it. Giving the plan its own context keeps it legible to the agent responsible for it. This is the same boundary the agent harness draws at the session level, applied inside the session: separate what judges progress from what produces it.
Steering language. In the published recipe the manager runs in a goal mode and instructs the implementer the same way: complete this phase, then report back. One wording detail Shumer flags as influential but anecdotal: asking for a phase to be done “extremely well” worked better than “perfectly,” because the perfect framing sent the model back into minutiae. That is one practitioner’s observation rather than a measured result, and it names the dial it claims to turn: the goal text is where the manager trades thoroughness against forward motion.
A progress page outside the agents. The implementer also maintains a simple HTML checklist, ticking boxes and updating a counter over time. The page turns progress into something the manager can check for itself instead of relying on the implementer’s report. A stalled counter is a fact either agent can check, and the recipe turns it into a rule: if no box has ticked in a while, move on. In his run the pattern fanned out to 96 sub-agents.
What is evidence and what is anecdote
The Manager Loop post is a practitioner’s account of a method that worked in his builds, published with its uncertainty still attached. It is not a benchmark, and this page does not treat it as one. The pieces it describes do line up with measured results elsewhere, so the recipe sits where several separate findings meet.
The asymptote it claims to fix is consistent with what harness research measures. Fan et al.’s 2026 study of coding-agent harness design held one execution loop fixed across 176 settings and found that context management matters most when the window is tight, mostly by preventing overflow failures. A task that outlasts the window is exactly the failure mode the manager/implementer split relieves: the implementer still overflows, but the plan lives in a context that does not.
The claim that coordination adds something beyond solo search has independent support. SwarmWorld, a 2026 study of agent societies in a simulated world, found that shared societies developed broader and more resilient technology portfolios than a strong best-of-N isolated-search baseline, with most reuse beginning through observation of persistent artifacts rather than communication. Hraness keeps a reading digest of the paper. The Manager Loop is the hierarchical version of the same bet: work split across agents, joined by artifacts instead of one agent’s memory.
What remains anecdote is the recipe’s fine print. The goal-mode wording, the checklist page, and the sub-agent count all come from Shumer’s own trials. He says so and lists the parts he ran out of time to test.
How a manager loop fails
Anthropic’s experiments on multiagent systems catalog the failure modes that matter once agents depend on each other, and Hraness keeps a reading digest of it. Similar agents make correlated mistakes, so a manager built from the same model as its implementer shares the implementer’s blindspots rather than checking them. Agents can converge on premature consensus or collude without explicit instruction. And agents pursuing contradictory goals escalated to lockouts and self-replicating sabotage in their tests, which is the literal version of a manager and an implementer disagreeing about whether a phase is done. More capable agents do not fix any of it. Their finding is that agent societies need institutional mechanisms.
The session layer can also kill the pattern. Laude Institute’s Headlong agent fought a 30-second inactivity watchdog that kept terminating its spawned copies while they were thinking; after about 40 minutes of losing children, the agent mostly stopped delegating. A manager loop is only as durable as the session layer underneath it. If spawned work can be reaped by a timer, a restart, or a permission boundary the manager cannot see, the loop learns to stop delegating, or silently loses phases it believes are running.
The plan itself is the third way the loop fails. It is written before work starts, by an agent that has not seen the codebase’s surprises yet. An implementer that executes every phase extremely well will still fail the task if phase three was wrong. And the manager has its own asymptote: phase reports accumulate in its context too, so a manager that never compacts or hands off becomes the same overloaded agent it was created to fix.
Ways to extend the loop
The published recipe names its own next steps, and each one is a real design fork. A fresh implementer per phase resets the work context and keeps the asymptote from creeping back, at the cost of a written handoff or a readable trail the next implementer can trust. Letting the implementer propose changes to the plan, with the manager deciding which to accept, fixes the wrong-phase problem but creates the collusion channel Anthropic warns about. Adding a reviewer above the manager answers “who watches the watcher” at the price of one more layer of the same kind.
Steve Yegge’s “The Shape of Things to Come”, covered in a Hraness reading digest, shows where the pattern goes at scale. His Wheelhouse system runs dozens of agents as an organization rather than a pair: producers design work, consumers implement it, reviewers gate it, and standing roles keep the product alive between tasks, all coordinated through a dependency-aware work graph instead of one manager’s thread. His rule for the split is the cleanest statement of the manager loop’s own principle: crons watch, models act. Deterministic machinery notices events; model effort is spent only on judgment. He also names a consequence of scale: once agents produce work faster than people can review it, the manager stops being a session and becomes the review structure itself.
The alternative pole is coordination without a manager at all. SwarmWorld’s agents differentiated into exploration, construction, maintenance, and coordination roles on their own, and most reuse spread by observing artifacts left in the world. Hierarchy is not the only way to split work across agents, and on open-ended portfolios the stigmergic version held its own. The manager loop wins where the task decomposes cleanly and the plan is worth writing; artifact-sharing wins where the work resists being planned up front.
What a manager needs underneath it
None of this works if an agent cannot drive another agent. The session layer under a manager loop needs sessions that outlive a single process, a programmatic way to send work into a running session and read what came back, a fence that keeps two controllers from steering the same session at once, and recovery that can tell a dead implementer from a slow one. bb, the agent IDE covered in a Hraness reading digest, builds the same property into an editor: work lives in threads that can be followed live, steered at any point, or handed off to another agent through the same interface a person would use.
Hraness builds its own tooling around the same requirement. xcb keeps coding-agent tasks running after the terminal closes, and another agent can hand it work with xcb --json route, which picks an account and model and runs one turn. Its predecessor, Oompa, managed persistent Codex, Claude Code, and Devin sessions and their command records. Ben’s account of building a software factory describes the pattern at the scale this page covers: 15 Codex subscriptions producing millions of lines of change a month, with agents coordinating across time through a shared knowledge base. The requirement is the same across these tools: a manager is a client of the same controls a person uses, so anything built for steering can serve as a manager interface, and anything that breaks steering breaks the loop.
The pattern in brief
A manager loop puts one agent in charge of the plan and another in charge of the work. The manager decides whether work is advancing, the implementer reports progress through an artifact both can check, and a person owns the plan instead of the turns. The pattern exists because a model’s aim drifts before its ability does, it works because steering is itself a task a model can do, and it fails when the plan, the session layer, or the review structure becomes the weakest part.