Several agents and adversarial checking
- 01Fan-out, pipeline, barrier: choosing the architecture, or giving it up9 min
Fan-out converges independent agents behind a barrier that waits for all of them, while a pipeline moves each item along without waiting for the others. The third option is to launch no agent at all, because a multi-agent architecture is an expensive option: start with the simplest approach that works.
- 02Isolating and running in the background: worktrees and the dry loop8 min
To stop one agent overwriting another's work in the same repository, give each its own worktree with isolation: worktree. An agent started in an interactive session now runs in the background by default. To make a search know when to stop, compare each cycle against the set already known and stop once consecutive runs flag nothing new.
- 03Making a large scale fan-out hold together8 min
A single agent writing an over-long deliverable is interrupted by an output size limit: the fix is one agent per axis, each writing its own file. Then verify the disk, never the report: write the exact list of expected files before launching, and compare it against what genuinely exists.
- 04Deterministic workflows: schemas, checkpoints, resumption9 min
A workflow is a script that chains agent calls deterministically: the same steps and the same output schema on every run. A JSON schema imposes named fields from one step to the next, and each completed step writes a checkpoint, so an interrupted workflow resumes without redoing everything.
- 05Adversarial verification, judge panels and completeness critics8 min
A verifier receives the artefact to judge, clear success criteria and the tools to check it, and an empty report is credible only if it counts what was checked. A panel compares solutions, a completeness critic compares the brief to what was delivered: roles not to be confused.
- 06Multiplying agents can multiply the error8 min
A study (an arXiv preprint) finds that independent agents, with no coordinator validating their outputs, amplify errors far more than a single agent. A coordinator that reviews each output reduces this amplification sharply, and on a task with strictly ordered steps the four multi-agent architectures tested fall behind a single agent.
- 07An unverified premise in a prompt comes back as a conclusion8 min
A false premise slipped into a prompt's framing is never tested: the agent treats it as a fact and reflects it in its output, and the adversarial verifier, who only reviews that output, never sees it. In a fan-out it is repeated in every output, which gives a false impression of corroboration.
- 08Three failure states, and accepting a risk properly8 min
A task queue distinguishes success, a recoverable failure that will be retried, and a definitive failure; lumping the last two into one failure category breaks the value of any alert. Accepting a risk means letting it happen and checking afterwards against a snapshot taken before execution, not ignoring it.
- 09Remove the tool before writing the prohibition8 min
An instruction that prohibits steers what an agent attempts without preventing anything: the protection that holds first removes the tools its mission does not need, then the closed list of expected effects and the prohibition by class come second and third, as instructions.
- 10Succeeded, failed, interrupted, no trace8 min
When a cutoff stops a queue of tasks, a log kept outside the process, written before and after each task, separates four states: succeeded, failed, interrupted midway, and no trace of an attempt; confusing them leads you to rerun what may already have acted, or to declare failed what nobody has examined.
- 11Capping a judge loop before launching it8 min
Set the cap before the first pass, in the batch's criteria: a maximum number of judge passes and of agents. The stopping criterion belongs to the judge, whom you do not control, and as long as it finds something the loop continues and its cost climbs. When the cap is reached, fix the sourced major findings and close.