On October 7 I dictated the plan to an agent: we would start an autonomous loop, I would close my session, come back a few days later, and the 200 ...
For further actions, you may consider blocking this person and/or reporting abuse
the integrator bottleneck is the finding i keep coming back to. twenty-eight workers in parallel, one sequential gate that absorbed all the variance: median wait went from under a minute on friday to over an hour at peak on sunday morning. a good reminder that parallel agents don't remove queueing theory, they just move the queue somewhere less visible.
Yes, and the worst hour didn't come at twenty workers. It came early Sunday morning, when eight were running, with a median wait above an hour, and on Monday, at twenty, the median for the day was eleven minutes. Batching kept it from being worse, up to six integrations behind one pre-check and one deployment.
the eight-worker sunday being worse than the twenty-worker monday is the detail that stuck with me. headcount wasn't the driver, arrival timing was, and batching six integrations behind one pre-check was the pressure valve.
Arrival timing is the right split. Eight workers on Sunday dumped work into one integrator that still took them one by one. Twenty on Monday still went through that same gate, but six integrations sat behind one pre-check, so 251 requests that day had an 11-minute median instead of another hour. Adding workers added arrivals. The valve was how many I let into one check.
The precedent step is the part I'd want to copy. My agents raise each question on the ticket as a card with options, then end their turn, and the answer is written into a memory file the next run reads, so the same question shouldn't come back. What I don't keep is your 166/19 split: a log of where an agent applied an old answer without asking. When you rejected a precedent, did the rule the workers re-read change too, or only that unit?
Only that unit. A precedent I validated became one the next workers could match against, and one I rejected reopened the unit at its worker and stayed out of the precedents, so the bad answer didn't spread. Changing the rule for everyone was a separate step, me editing the protocol file the workers re-read. Each one was logged with the case, the precedent the worker used and its solution, which is what made checking them afterwards possible. One rejection, for example: a Favorites button in the toolbar was missing because the test app had no Favorites section, and the worker reused an earlier precedent about a control absent from the test app to skip it, so I had it add the section to the test app instead.
So a rejection fixed the case, and the rule only moved when you edited the protocol yourself. Mine has no such split: every answer I give goes straight into the memory file the next run reads, so one wrong answer reaches every later run. Did the ten "excluded what resisted" rejections end in a protocol edit?
Yes. Those ten hours were me editing the protocol, not more rejects. A reject only reopened that unit and kept the bad answer out of the precedents. The rule that workers don't drop a control because it resists existed only after I wrote it, after an audit found 516 still on the old path with no decision. That's the split you're missing: a wrong answer on a card stays on the card, instead of becoming the file the next run reads.
The part I found most useful is that two weeks of design came before six days of execution, and that the design mostly settled what a finished unit looks like. Once done meant the same application state before and after for every control, an exact undo, and an API that behaves like the UI, the loop had something it could not argue with.
The questions dashboard is the other piece. Each question came with options, costs and a recommendation, and you followed it 47 times out of 59. That suggests most of the human time goes into drawing boundaries rather than answering technical details: what is reversible, what users can see, what counts as scope.
We scope client work the same way, one clearly defined problem with the finish line written before anyone starts, and the share of effort that goes into defining it surprises people every time. Looking back, which of the 53 protocol changes would you have moved into the design phase?
Most of them, I wouldn't. The two weeks had already locked what "done" meant; the 53 edits were the loop hitting cases the design hadn't seen. Three I would have written on day one: the test bench has to send what the UI sends, not its own requests; a worker holding no unit still has a pulse; and "don't drop what resists" as a rule, not a hope, because an audit found 516 controls still on the old path with no decision. The rest were cheaper as protocol edits than as another week of design.
The decision to keep chat out of worker coordination and put the protocol in a versioned file re-read per round is the reason this scaled without drifting. Multi-agent refactors usually choke when teams try to coordinate via inter-agent messaging, where context windows bloat and message ordering rots over dozens of turns. Forcing workers to pull from a typed queue into isolated worktrees, prove state equivalence on throwaway clones, and hand off clean commits turns the integrator into an admission controller rather than a referee.
Right, and chat never crept back in because a worker always had somewhere else to put a question. It wrote a card on the dashboard with the context, two or three options and a recommendation, parked the unit and pulled the next one from the queue, and the dashboard refreshed every five minutes. The part the queue didn't cover was a worker holding nothing: heartbeats came every 10 to 20 minutes, but the 45-minute timeout only watched units in progress, so an idle worker could go quiet without anyone seeing it.