Three Scouts in 47 Milliseconds

I asked my home agent system a three-part question: where is a rule enforced, what does the config set, which test covers it.

The log shows three requests landing 47 milliseconds apart.

Instead of answering the parts one at a time, the orchestrating model handed each part to a scout: a small, cheap, read-only agent whose whole job is to go find something and come back. Three scouts ran in parallel on a used GPU, and the full sweep finished in 8.2 seconds with correct file and line references on all three parts. The orchestrator never read a single file itself. It read three short reports and spent its expensive attention on the part that mattered: what the findings meant.

The earlier issues of this playbook came from chapters I was studying. This one came out of my own incident log, because multi-agent orchestration is the chapter where my system has both the best receipts and the ugliest one.

The boundary test

Fanning out is a pricing decision before it is an architecture decision. Frontier models are expensive and small local models are nearly free, so every token of frontier attention spent on retrieval is judgment you paid for and did not get. I once watched a single stuck measurement task pull about forty retrieval calls back onto the expensive model, and the session bloated past the point of usefulness. The work got done. It cost roughly ten times what it should have, and the model doing it got dumber as its context filled with file listings.

So my router applies a boundary test to every piece of work. If the task is mostly searching, reading, or verifying against a clear spec, it goes to a cheap agent, and several of them can go at once. If the task involves intent, design, tradeoffs, risk, or final approval, it stays on the one thread that holds the whole picture.

Fan out the reading.

Keep the judgment on one thread.

The second half of the test matters as much as the first. A committee of agents negotiating a design produces the average of their guesses. One context that has seen every finding produces a decision. Parallelism is for gathering, and the gather is only safe because my scouts are read-only by construction: the tool set they receive simply contains no way to write. A capability an agent does not have is a mistake it cannot make, and that beats any instruction I could write into its prompt.

The contract is the product

The thing that makes a fan-out work has nothing to do with concurrency. It is the return contract. Each of my scouts owes at most fifteen lines back: file and line references, one-sentence facts, a yes or no up front if the question was a yes or no. A scout that comes back with a wall of raw output has failed the task even when the work underneath was correct, because that wall lands in the orchestrator's context and degrades every decision made after it.

Conclusions, never transcripts.

References, never pasted files.

The contract has a third clause that took me longest to learn: punt up. When a scout hits something ambiguous that would change the answer, it stops and surfaces the ambiguity inside its fifteen lines. A cheap model guessing silently in a corner of the system is how confident wrong answers get laundered into decisions. The budget is a ceiling on words, never on honesty.

If you manage a team of humans, none of this is news. It is the difference between a direct report who forwards you their entire inbox and one who sends three bullets and a flag on the thing they were unsure about. The PM work in a multi-agent system is writing that job description precisely enough that a very cheap worker can meet it.

Every seam is a new way to fail

Now the ugly receipt. One night a scout hit its step limit mid-task and came back with nothing. The orchestrating model, reasonably, decided to redo that scout's work itself, inline, on the expensive thread. Partway through, it produced a completely empty reply. On the turn after that, it fell into a degeneration loop and wrote the same sentence 501 times in a row: 181,083 characters into one chat bubble, stopped only when it slammed into the hard token cap.

Nothing in that cascade was exotic. Each seam failed in an ordinary way: a worker timed out, a fallback was unplanned, a model degenerated with nobody watching the output. The lesson is that every agent you add to a system adds a seam, and the seams fail together. Fanning out does not just multiply your throughput. It multiplies the places where a Tuesday-night failure can start.

Design the failure path with the same care as the happy path, because the happy path never pages you.

The fix followed the loop from Issue 02: the incident became infrastructure. I shipped a repetition breaker that cuts any turn the moment it produces three identical copies of the same block, which turns a 181,083 character meltdown into a 3,200 character one. Then I swept every stored transcript to calibrate it: 30,230 assistant turns, exactly three real loops found, zero healthy turns flagged. Two of those three loops had been sitting in the logs for weeks, unnoticed. The failure was a recurring class the whole time. I only found out because one instance finally happened in front of me.

Fan out the reading.

Hold every worker to its contract.

Cap the blast radius before the night you need it capped.

Forty-seven milliseconds is what delegation looks like when it works. Five hundred and one copies of the same sentence is what it looks like when you skip the boundary test, the contract, or the breaker. I have the logs for both, and I reread the second one more often.