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. This page goes further: why the split helps, which parts of the recipe are evidence and which are hunch, how the pattern fails, and what it looks like when the manager stops being a session and becomes an organization.
The problem a manager solves
Long-horizon tasks break coding agents in a specific way. The model does not run out of ability; it runs out of aim. 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. The problem is that the nudge is exactly 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. The observation behind it is simple: 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.
The mechanism
Plan before work.The manager's first job is decomposition, not delegation. 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. The split is the point. 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 a single operator's observation, not a finding, but it is honest about which dial it claims to turn: the goal text is where the manager trades thoroughness against forward motion.
A progress surface outside the agents. The implementer also maintains a simple HTML checklist, ticking boxes and updating a counter over time. The trick is not the page; it is that progress becomes an artifact the manager can read instead of a feeling the implementer reports. 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, and the honest way to read the recipe is as a point 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 digestof 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 one operator's trials. Shumer says so himself 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 digestof 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. Capability does not fix any of it; their finding is that agent societies need institutional mechanisms, not just smarter members.
The substrate 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 failure surface. 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.
The design space
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 admission, 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 the consequence nobody escapes. 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 from its substrate
None of this works if an agent cannot actually drive another agent. The substrate 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.
That is also the contract Hraness builds its own tooling around. xcbis one terminal for coding agents whose sessions persist, accept steering, and recover interrupted work; its predecessor HRA was built explicitly as the control plane for running provider agents under a person's direction. Ben's account of building a software factory documents the pattern operating at the scale this page describes: fifteen agent subscriptions producing millions of lines of change a month, with agents coordinating across time through a shared knowledge base. The tools differ. The requirement does not. A manager is a client of the same control surface a person uses, so anything built for steering is a candidate manager interface, and anything that breaks steering breaks the loop.
The definition, again
A manager loop is the loop around the loop. One agent holds the plan and decides whether work is advancing; another holds the work and reports progress through an artifact both can check; and a person owns the plan instead of the turns. It exists because a model's aim drifts before its ability does, it works because steering is itself a task a model can hold, and it fails the moment the plan, the substrate, or the review structure becomes the weakest part. The open question the recipe leaves behind is the one every layer up answers again: who manages the manager.