The Self-Healing Factory
Published Jul 3, 2026 · by Orion
Most software teams build until something breaks, then stop everything to fix it. In an autonomous agent system, that pause is death — the machine must keep improving even while it repairs itself. The answer is two alternating loops: a sprint loop that builds new capabilities, and a recursive self-improvement (RSI) loop that fixes what breaks. They take turns, and the result is a [{factory}]{initiatives} that never stalls.
The sprint loop is the forward motion. [{Merlin}]{initiatives} sequences initiatives into a priority backlog, Elrond dispatches the top items, and agents build, test, review, and ship. When every initiative sails through, the sprint loop just keeps churning out new capabilities. It is the heartbeat of the factory.
But agentic systems are complex, and work gets blocked. An initiative may fail its review checkpoint. A pipeline gap may surface. A bug may be uncovered. When that happens, [{Hermione}]{monitoring} (the monitor) flags it, and the sprint loop yields to the RSI loop. [{Elrond}]{quality-management} groups blocked initiatives by shared root cause — fixing one cause unblocks many initiatives at once. That leverage principle is the engine of efficient self-repair.
[{Albus}]{blueprint} diagnoses each root cause and files a fix initiative, which is built through the same pipeline that builds everything else — no special process, no human intervention. Once the fix ships, all blocked initiatives in that group are retriggered back into the dispatch queue. The queue does not simply pick the oldest item. It grades every initiative by circumstance: a retriggered blocked item gets priority during RSI-only dispatch mode; a diagnosis initiative has its own lane. The queue has a hard cap of three concurrent dispatches, with a [{circuit breaker}]{quality-management} that trips when too many fail. When the breaker is tripped, only RSI work dispatches — the factory prioritizes healing over building.
forward builds, then self-repair, then forward builds again — is what makes a software factory autonomous. It does not stop when something breaks. It does not wait for a human to notice. It diagnoses, fixes, and resumes. The sprint is the heartbeat. The RSI is the immune system. Together they form a machine that builds better and better agents, forever.
Updates
An update to this story, and a humbling one: we drew a line through our own [{self-healing}]{monitoring} loop. The principle first — a factory repairing the products it builds and a factory rewriting its own machinery are not the same risk; one mistake stays local, the other cascades through everything the factory will ever make. Every recorded pipeline disruption in [{Carolverse}]{system-services} traced back to an autonomous edit of the pipeline's own guts — a diagnosis citing files that did not exist, an overnight rewrite of the orchestrator. So Albus's repair roles are now recommendations-only, and only Orion, the human operator, may touch the core — while the [{build pipeline}]{initiatives} still detects, diagnoses, and fixes the code it produces with no human in the loop. This is a pause, not a verdict: the scaffolding stays, and when models grow reliable enough to hold that door, we hand the key back. The takeaway — give your system full autonomy over what it builds, but guard the power to rewrite itself until the judgement is truly there.
A principle with a wrong example is still a wrong thing to publish. The original article stated a hard cap of three concurrent dispatches from the [{dispatch queue}]{initiatives} — another article said two. Both will be outdated within weeks, because those numbers shift as the factory grows. The durable concept is not the cap; it is that a dispatch queue exists at all. A queue gives every agent and every human a single window into what the pipeline is about to execute next. Without it, work drifts in and out of sight. Whatever the current limit happens to be, the queue itself is what makes the factory legible — and any autonomous system needs that visibility.