##prototype-to-drained-epic
The largest run of the pipeline so far, followed all the way through: a 42-minute prototype walkthrough became 351 requirements and a dependency graph of 73 tickets, and parallel agent lanes drained it in 30 waves over a little more than four days. It was the second full run, so it is also where I could see what the first run had taught the system.
The first full run was in July. The pipeline ingested a product designer's prototype, we authored 114 requirements before any code was written, and agent lanes drained a 45-ticket epic in about 35 operator-paced hours, with 44 of the 45 slices merged across roughly 92 PRs in 3 repos, 111 of 111 end-to-end scenarios green, nothing reverted, and eight human decisions steering all of it. I presented that run publicly as "Agentic Loops and Graphs" at the Irvine AI meetup. In August I ran the same pipeline a second time on a larger feature, and what I wanted to find out was how much of the first run carried over.
It started on an engineering sync, where a teammate walked me through his prototype for 42 minutes, and I saved the transcript on purpose because I wanted it to be spec input. The prototype was frozen before the first reader ran, so every requirement candidate points at a line in the snapshot. Thirteen autonomous readers then mapped it against the shipped specs in about 25 minutes and extracted 511 requirement candidates with no errors. One of those readers compares new work against shipped decisions, and I had invented it during the first run, and this time it caught the new prototype reversing a decision the first run had made three weeks earlier. The first run had eight human checkpoints that I discovered along the way. This time I designed two gates up front, ruled seven scope decisions at them, and held one unit open on a question only the product owner could answer, which parked that unit without stalling the rest. The next day I ruled 60 of 61 pending candidates in one sitting with the product owner, and by the time the drain started the spec held 351 requirements.
Two mint workers turned the spec into 70 tickets in 31 minutes overnight. The first worker died of context overflow at ticket 36 and a fresh worker finished the job, and between them they produced two duplicates, which were caught and canceled before any lane started them. What surprised me was that only one of the two came from the restart. The other was the same requirement minted twice by the same worker under different vocabulary, so the fix I took away is a check that no two tickets cover the same set of requirements. Four more tickets were discovered while the drain was running, and each one landed inside the workstream that should have owned it. I had estimated about 66 slices at decomposition and the run executed 75, so the early count was good to within about 17%.
The drain ran 30 waves over a little more than four days. It started with two isolated lanes, one backend and one frontend, and went to three lanes from wave 13, and once it warmed up it merged 17 to 19 tickets a day for four days in a row, through a model-provider outage, a macOS permissions incident in the middle of a wave, and two nights where my machine simply went to sleep. Both lanes survived the permissions incident from their resume manifests. The third lane bought about 32% more tickets per hour and cost about 11% per lane, because the merge fences serialize and the lead is shared. I offered myself a fourth lane near the end and took it back within the hour, so I treat three as the practical ceiling on my hardware.
Partway through I asked why the drain kept choosing deep tickets while a pool of shallow ready ones sat waiting, and we answered it with a simulation over the real graph. Scheduling policy barely moves the finish line, because the graph is dominated by total work: the capacity-limited lower bound was 29 waves against a critical path of 10 tickets, and the real drain took 30. The better argument for going deep first is about information. Every expensive unknown lived on the deep runtime chain, including a response key that our own client had documented wrong and a branch of execution that no ticket owned, and a defect found early on a chain has no consumers to rework yet. The price was that QA had nothing testable until the chain closed, and I ruled on that trade explicitly once I could see it.
The human side of the run taught me the most. At mint time the pipeline proposed 53 human gates, because its rule put a review gate on every heavy-risk ticket, and only 3 of them ever fired, while the eight interventions that actually changed the course of the run had no gate pointing at them. I approved all 75 merges myself and requested no changes on any of them. As trust grew the fence got cheaper, and by the later waves the lead would stage a wave's PRs with a report and I would release them with one word. I now read that clean approval record as a warning as much as a result, because of what QA found afterward, which is the next case study.
// the drain, replayed — sanitized interactive record
This is the real dependency graph from the 75-ticket epic, laid out by build depth, so every arrow flows left to right and each column became buildable the moment the column before it merged. The tall columns are where the drain could run lanes in parallel, and the critical path of 10 tickets is the floor. Click a slice to trace what it waited on and what it unblocked, and to see which of the 30 real waves built it. I have scrubbed the identifiers and titles, but the topology, the risk tiers, the wave and lane assignments, and the timestamps are all real.
All 75 buildable slices shipped and merged across 30 waves. The two marked X were duplicates that the mint produced, and both were caught and canceled before any lane started them. The four marked + were gaps the drain itself discovered, and each was minted as its own ticket inside the workstream that should have owned it. The long hatched tails are mostly nights when I was asleep.
// outcome
What carried over from the first run is the part I am proudest of. The front door had become a documented command, prototype anchors were frozen at intake, the reader that defends earlier decisions ran by default, and the pipeline began measuring itself with a telemetry manifest at every mint, which is where the forecasting numbers above come from. A third project on a different product began adopting the pipeline before this run had finished, with another engineer porting the prompts, and that is the clearest evidence I have so far that the context is in the repository where other people can pick it up.