The Sentinel Pattern: A Multi-Agent Dev Loop That Doesn't Trust Its Own Agents

Start with the constraint, because the constraint is what makes this interesting. I have one machine, one Claude subscription, and a task list longer than my attention span. Working with a single agent, my throughput is bounded by how fast I can read what it did. That bound is real and it is low. Reading a diff carefully is slower than generating it, and it has been slower ever since the models got good.

So you reach for parallelism. Five agents, five tasks, five branches. I call one of those a lane: one agent, one scoped task, one branch, running start to finish without supervision, and the word will do a lot of work in this post. The first version of that setup works beautifully right up until you try to merge, at which point you discover the thing nobody puts in the architecture diagrams: parallelism multiplies output and unverified claims at exactly the same rate. Five lanes produce five diffs and five reports. The diffs are real. The reports are a summary of the diffs written by the same process that wrote them, from a context that has already been compressed once or twice along the way.

"The model hallucinates" is the wrong diagnosis here, and it sends you off tuning prompts when the problem is structural. A subagent working a long task fills its context window, gets compacted, keeps going, gets compacted again. By the time it writes "I implemented nine", the nine is not a count. It is a recollection of a count, reconstructed from a summary of a summary. Ask a human to write a status report from memory after eight hours of work and you get the same class of error, which is why we invented commit logs.

The pattern that fell out of this has one long-lived agent and many short-lived ones. I call the long-lived one the sentinel. It writes no product code. Its entire job is to scope work, launch specialists, attack their output, and decide what gets merged. Everything else in this post is a consequence of that split, and of the fact that I got the split wrong several times before it stuck.

Three kinds of agent run in this loop. What separates them is not capability, since they are all instances of the same family of model. What separates them is what I am willing to believe from each one without checking.

The sentinel

Orchestrator and gatekeeper. It writes the briefs, launches the lanes, audits the results, owns the ledger, and merges. Two rules define it, and both are load-bearing.

First, it writes no product code. The practical reason is context: auditing four lanes is the most context-hungry job in the system, and an orchestrator that has also been elbow-deep in a refactor has spent that context. The structural reason is that a reviewer with a diff in the merge has an interest in the merge succeeding. I do not think a language model experiences that as a conflict of interest the way a person would, but I would rather not find out at the gate.

Second, anything paid or irreversible runs from the sentinel. Pushes, tags, releases, and evaluation runs that consume the shared quota window. Not because the specialists would be reckless with them, but because those actions have no undo and I want exactly one place where they can originate. A lane can propose a release. It cannot cut one.

The coders

One well-scoped task each, one git worktree branch each, the full test suite green before reporting, and a structured report back in a shape I specify in the brief. When the lane ends, the agent ends. There is no long-lived coder that accumulates knowledge across tasks, and that is deliberate: accumulated context is unaudited state, and unaudited state is the thing this entire process exists to minimise.

The obvious objection to disposable coders is that every new one has to re-learn the codebase, at full token price, from scratch. That objection is correct and the cost is real. It is the single biggest inefficiency in the whole loop, and the only thing that makes it tolerable is that findings get written down where the next lane can retrieve them instead of rediscovering them (section 11). Without that, disposable agents would be indefensible.

Coders get tight briefs. Task, the files they may touch, the rails they must not cross, and the exact shape of the report. A vague brief on a mid-tier model produces a lane that solves an adjacent problem beautifully.

Two details in the report shape do more for me than everything else in the brief combined. Ask for raw command output, pasted, rather than the lane's account of what the command said, because the account is where the rounding happens. And ask for the commit SHA the report describes. Without a pinned SHA the audit races the lane: it can push another commit while I am reading, and then I have verified a state that no longer exists.

TASK    one sentence, one outcome, no "and also"
WHERE   worktree wt-<name>, branch feat-<name>
TOUCH   src/searcher/*.py, tests/test_searcher.py
RAILS   do not touch the index schema; no destructive git;
        no new dependencies; no changes outside TOUCH
DONE    full suite green in your worktree
REPORT  1. commit SHA
        2. `git diff --name-only main...HEAD`, output pasted verbatim
        3. suite summary line, pasted verbatim (passed/failed/skipped/collected)
        4. anything you tried that did not work, one line each
        5. write your key findings to shared memory before you finish

That fits on a screen and takes ten minutes to write, most of it spent on the TOUCH and RAILS lines. Those two are what stop a lane from helpfully refactoring something three modules away, which is the failure mode that turns a clean merge into an afternoon.

The adversarial reviewers

Separate agents whose only job is to attack the work, each on an independent axis. In my loop those axes are: does retrieval actually return the right thing, does the tool get adopted by the agent it is built for or ignored, and does it beat a no-tool baseline on turns and tokens and wall time. Three different questions, three different agents, deliberately not one reviewer asked to consider all three, because a single reviewer with three mandates will find the easiest failure on the easiest axis and stop.

The instruction that made reviews useful was giving them the branch and a change note rather than a diff. A reviewer handed a diff reviews the diff. A reviewer handed a working build and told to go break it will use the product, wander outside the diff, and find the thing the diff broke two modules away. That is where the real defects have come from.

Two guardrails on reviewers. Rounds are capped, because an adversary with unlimited rounds will always find another nit and you will never ship. And reviewer findings are independently verified before they gate anything, because reviewers invent defects at roughly the same rate coders invent completions. A fabricated defect that blocks a merge costs a full extra loop, which is the most expensive kind of wrong.

Every task, every decision, every merge, and every gate verdict goes into one file, appended, never rewritten. It sounds bureaucratic for a solo project. It is the most valuable artifact in the loop.

The reason is that conversations do not survive. A chat window gets compacted, and when it does, the exact number in message forty gets replaced with a paraphrase. Sessions end. Machines sleep. Agents die mid-sentence. The ledger is the only thing in the system with a memory that does not degrade, so it is the only thing allowed to be authoritative about what happened.

Append-only matters more than it looks. A mutable status file lets a wrong entry be quietly corrected, which sounds like a feature until you realise that a silently corrected error teaches you nothing. When the count of nine turned out to be seven, the correction went in as a new line underneath, next to the original claim and the enumeration that settled it. That line is why the rule exists at all. A file that hid the error would have produced a small tidy edit and no rule.

[2026-07-14] TASK  retrieval-rerank-blend
  brief:  blend owning-class prior into rerank; touch searcher + index only
  lane:   coder / worktree wt-rerank / branch feat-rerank-blend
  report: "8 call sites updated, suite green (412 passed)"
  AUDIT   grep -c over the branch diff: 8 call sites  [matches]
  AUDIT   suite re-run on MAIN checkout: 412 passed, 0 skipped  [matches]
  verdict: MERGE  c1f9a2e

[2026-07-14] CORRECTION to entry [2026-07-11] docs-sweep
  ledger recorded 9 updated files on the lane's report
  enumeration of the branch diff: 7 files
  root cause: report written post-compaction; count was recalled, not counted
  rule added: no merge on a lane's claim, enumerate the artifacts

Two things that entry does. It records the evidence, not just the verdict, so a later reader can tell whether the merge was justified or lucky. And it makes the audit a written step rather than a thing I intended to do. If the AUDIT lines are missing, the merge did not happen, because I cannot tell afterwards whether I checked.

The ledger doubles as the recovery artifact. If I lose a session entirely, the ledger plus git branch --list reconstructs the state of the world in about a minute: what was assigned, what merged, what is still open on a branch somewhere. That property has saved me more than once, and it is worth designing for on purpose rather than discovering afterwards.

A report is hearsay, an artifact is evidence, and the gate only accepts evidence. Everything below is what that costs in practice.

Every claim in a lane's report has to be convertible into something I can produce myself in under a minute. "I updated nine files" becomes a file list from the branch diff, and I count the list. "The suite passes" becomes me running the suite, on the main checkout, and reading the summary line including the skip count. "I added the regression test" becomes finding the test by name and reading its body to check that it would actually fail without the fix. If a claim cannot be turned into an enumeration, I rewrite the brief so that next time it can, because a claim that cannot be checked is a claim that will eventually be wrong in a way nobody notices.

This is not paranoia about models. It is a cost asymmetry. Enumerating a claim costs a minute or two. A wrong claim in the ledger costs however long it takes to notice, plus everything that was built on top of it in the meantime, plus the time to work out which downstream conclusions are now suspect. When one side of a trade costs minutes and the other costs hours with a long tail, you do not need a strong prior about failure rates to know which way to lean.

One nuance worth stating, because it changes how you write briefs. The enumeration should be something the sentinel does, not something the lane does and reports. Asking a coder to "verify and confirm the count" produces a confirmation, which is another claim from the same source. Verification has to cross an agent boundary or it is not verification. This is the same reason we do not let people mark their own exams, and it is a much older idea than any of this tooling.

Now the part that decides how many agents you should actually run, which is a question I have never seen answered with a number.

Lanes run concurrently. Audits do not. There is one gate, it is me plus the sentinel, and it processes one lane's evidence at a time. That single fact is enough to derive the ceiling on the whole approach.

Numbers first, algebra after. Say a lane takes 40 minutes and auditing it takes 8. Done serially, four tasks cost 4 × 48 = 192 minutes. Run the four lanes at once and they all finish at minute 40, then the four audits go back to back and the last verdict lands at minute 72. That is 2.67 times faster, not 4 times, and the gap is entirely the audit queue.

Generalising: let L be lane duration, A be audit duration, N the number of concurrent lanes.

That formula describes one batch. A project is not one batch, it is a stream of tasks, and the stream version is worth deriving separately because the shape is different. In steady state the lanes deliver work at N/(L+A) tasks per minute and the gate consumes it at 1/A. Throughput is whichever is smaller, so the speedup over one-at-a-time is:

This is Amdahl's law wearing a different hat, and naming it that way tells you where the leverage is. The sequential fraction of this system is the audit, so the highest-value move is not adding lanes, it is making A smaller, and every bit of that comes from designing claims to be checkable by a command rather than by reading.

That reframing changed how I write briefs. "Report what you changed" produces prose, and prose costs me four minutes to convert into something checkable. "Report the list of changed paths and the suite summary line verbatim" produces something I can compare against reality in thirty seconds. Same lane, same model, same work, and my ceiling roughly doubled because the audit got cheaper. Structured reporting reads like paperwork and behaves like throughput.

Two things the formula leaves out

Rework. Lanes fail their audit, and a failed lane goes back out and comes through the same serial gate a second time. If a fraction f of lanes need that second pass, each delivered task costs 1+f trips through the gate, so throughput at saturation falls from 1/A to 1/(A(1+f)) delivered tasks per minute. Be careful with what that does to the ratio, though: a one-at-a-time baseline reworks at roughly the same rate, so f largely cancels out of the speedup and the ceiling stays near L/A + 1. What does not cancel is absolute throughput, gate time, and the bill. At f = 0.3, three lanes in ten produced nothing shippable and still consumed a full audit each. That is the strongest argument I know for spending twenty minutes on a brief, because f tracks brief quality far more closely than it tracks model quality.

The sentinel's context window. There is a second ceiling that has nothing to do with time. Evidence for one lane costs some number of tokens, call it E, and the sentinel has a finite window W. Once the accumulated evidence approaches W, the sentinel compacts, and a compacted gate is a gate that has started summarising the very details it exists to check. So the real bound is min(L/A + 1, W/E). On long audit-heavy days the second term binds first, which is why the sentinel does not write code: every token it spends on anything else is a lane it can no longer audit properly.

One last effect the arithmetic hides. If all lanes start together they finish together, and then the gate has a queue while every lane sits idle waiting for a verdict. Gate utilisation hits 100% and lane utilisation collapses. Staggering starts, or deliberately mixing lane sizes, smooths the arrivals without changing the makespan of the batch. In practice I pair one long lane with two or three short ones rather than launching four identical ones.

Two agents editing the same checkout is a lost-update machine. One writes a file, the other writes the same file from a stale read, and now half of one lane's work is gone with no error anywhere. Worse, they stage each other's half-finished edits, so a commit from lane A contains three broken lines from lane B and the test failure looks like it belongs to A.

The fix is standard and it works: a git worktree per lane, a branch per lane. Each lane gets its own working directory and its own index while sharing one object store, so the filesystem cannot be a shared mutable variable between agents. Two rails go with it. Lanes never run destructive git operations, because the object store, the refs, and the hooks are all shared even though the checkouts are not, so a garbage collection or a force-delete in one lane reaches into every other one. And lane scopes are assigned so that two lanes do not touch the same files, since a worktree prevents corruption but does not prevent a merge conflict you scheduled yourself.

Then there is the trap, which cost me an hour the first time and which I have not seen written down anywhere.

There is a related thing that catches people who set worktrees up correctly and then trust them too far: isolation ends at the merge. Lane 3's suite went green against the main branch as it stood when lane 3 started, and by the time lane 3 reaches the gate, lanes 1 and 2 have already landed. So the suite run that decides the merge has to happen after the merge commit exists, not before it, on the resulting tree. I merge in the order the audits complete, and each merge is followed by its own run. Twice now that post-merge run has caught a pair of changes that were individually correct and jointly wrong, which no amount of pre-merge testing in isolated worktrees would have found.

Dot-directories are only the version of this I happened to hit. Worktrees isolate files and nothing else. Ports, caches, temporary directories, on-disk databases, and background daemons stay shared, and two lanes that each start a service on the same port collide in a way that reads as flakiness rather than as a collision. So the brief either pins a lane's runtime resources to unique values or forbids it from starting them. In my case the expensive shared resource is index building, which is why heavy indexing jobs run strictly one at a time (section 10).

Isolation is per-resource, and you only have the isolation you explicitly built. Everyone remembers files. Almost nobody remembers the port.

The instinct is to put the best model everywhere. It is the wrong instinct, and the argument against it is not really about money.

Different roles have different failure costs. A coder's mistake gets caught twice: by its own suite and again at the gate. A reviewer's mistake is a false negative, which is invisible and therefore expensive, or a false positive, which is caught when I try to reproduce it. The gate's mistake ships. Those are three different consequences, so they justify three different amounts of capability.

My split: the sentinel runs on the strongest model available, coders on a mid tier, reviewers and validators on a strong but cheaper tier. In current terms that means Opus at the gate, Sonnet in the lanes, and a previous-generation Opus doing review.

The honest cost of tiering down the coders is that mid-tier models need tighter briefs. Ambiguity that a top-tier model resolves sensibly, a mid-tier model resolves plausibly and differently from what you meant. So you pay in specification what you saved in tokens. I think that is a good trade, and not only for the money: a brief is a reusable artifact that makes the next lane better, and tokens are gone the moment they are spent. Being forced to write a precise brief has improved my task decomposition more than any tool has.

What I would not do is tier the reviewers down to the cheapest option available. A weak adversary produces the most dangerous output in the whole system, which is a clean review that means nothing. False confidence at the review stage does not fail loudly; it fails later, in front of a user, and by then you have a track record of green reviews telling you the process works. Reviewers stay strong.

Agents die. The quota window runs out mid-lane, the API returns an error the harness cannot recover from, the machine sleeps and takes the stream with it. On a long run this is not an edge case, it is a weekly event.

The thing to understand about an agent death is exactly what is lost and what is not. The worktree is on disk. The branch is on disk. Every edit the agent had already written is on disk. A kill loses no disk state. What it loses is context: the plan the agent had formed, the four files it had read and understood, the reason it chose the approach it chose, the thing it discovered in minute twelve that changed the design.

Which means the recovery move is to restore context, not to restart work. Resuming an agent from its transcript brings back the reasoning that produced the half-finished diff. Starting a fresh agent instead produces something worse than a slow restart: an agent with no memory of the edits already on disk, which will re-derive a plan, re-read the files, and quite possibly apply a change that is already there. Double-applied edits are a nasty class of bug because they often still compile.

I have verified this twice on real kills, once when a quota window closed under a running lane and once on an unrecoverable API error. Both agents resumed from their transcripts and finished the task. Resume first, always.

This rule also quietly explains why disposable coders work at all. Because a lane's durable output is its branch rather than its conversation, the conversation is allowed to be fragile. Design the system so the fragile part is the part you can afford to lose.

Development lanes and paid evaluation runs draw from the same quota window. There is no separate budget for "the experiment" and "the work". A benchmark run that eats the window leaves nothing for the lanes, and four parallel lanes on a busy afternoon can close the window before an evaluation has started.

Most write-ups of agent fleets do not have this constraint, because they are running on a company card. It changes the design, and mostly for the better, because it forces three habits that turn out to be good practice regardless of who is paying.

Everything is resumable. A run that cannot survive being interrupted is a run you cannot afford to start, because you cannot promise it an uninterrupted window. In practice that means checkpointing to disk after each unit of work, writing results incrementally instead of at the end, and making a re-run of an already-completed unit cheap and harmless rather than something the design forbids.

Work is sequenced, not crammed. Full-factorial experiment matrices are simply infeasible: every additional axis multiplies runs, and runs are the scarce thing. So the design is tiered. Run the headline configuration first, the one whose result would change what you do next. Only if it lands do the secondary arms get a window. Half the matrices I have designed were never worth running once the headline came back.

Explore once, reuse everywhere. The most wasteful pattern in a multi-lane loop is four agents independently discovering the same three facts about the codebase, at full token price, four times. So exploration happens once, in its own lane, and its output is written down as notes that later lanes read instead of rediscovering. This is section 11's mechanism, and quota pressure is what made me take it seriously.

I resented this constraint for about a month and now I would keep it even if someone handed me an unlimited budget. It killed a whole class of plans that would have looked productive for a week and answered nothing.

This runs on a MacBook. Not a cluster, not a CI fleet. The machine has opinions and they are enforced by the operating system, not by anything I can prompt my way out of.

Sleep kills long-running agent streams. I did not believe this at first and assumed the stream was dying for some network reason. Then I lined up the kill timestamps against the machine's own wake log and they matched to the second. Every one. A long lane left running while the machine idles into sleep is a dead lane. The fix is caffeinate -is wrapped around long runs, which holds off idle sleep for the duration. It does not cover everything: closing the lid on battery still sleeps the machine, and no flag changes that. Long runs mean lid open and power connected.

What survives the kill is the disk state, which is exactly why rule 4 exists. These two rules are the same rule seen from different ends: the machine will take your agents, so build so that losing one costs you context and not work.

Heavy indexing runs strictly one at a time. Building a semantic index over a large repository is the most resource-hungry thing in my stack. Two of them concurrently do not take twice as long; they thrash memory and the CPU, and everything else on the machine, including the lanes you were trying to accelerate, slows to a crawl. This one I learned by doing it and watching a fan-loud hour produce less than a quiet twenty minutes would have.

None of this is profound. It is the kind of thing that reads as trivia until it eats an afternoon, which is precisely why I put it in the ledger and then in this post. The failure mode that costs the most is the one you attribute to the wrong layer, and "my agent framework is unreliable" is what a sleeping laptop looks like from the inside.

When a lane finishes, the sentinel needs to know what it learned. I spent a while reading transcripts for this, which is the intuitive move and cost me more context than any other habit I have had to break.

A finished lane's transcript is long, and most of it is procedural noise: files read and discarded, an approach tried and abandoned, tool output nobody needs again. The signal is a handful of findings scattered through it. Reading all of that into the sentinel's context spends the scarcest resource in the system on mostly-noise, and the sentinel's context is scarce because auditing four lanes is exactly the job that needs room to think. Tokens spent absorbing a transcript are tokens not spent at the gate.

So the protocol is: every subagent writes its key findings as notes to a shared working-memory store before it finishes, tagged with its own identifier, and the sentinel recalls notes instead of reading transcripts. The store is a local daemon that every agent talks to over the same interface, so a note written by a coder in one worktree is immediately recallable by a reviewer in another and by the sentinel at the gate.

A shared scratch file gets you most of the way and then stops. The difference is retrieval: the sentinel asks a question and gets the four relevant notes, rather than paging in the whole file to find them, and that is the entire saving. Attribution matters for a smaller reason that turns out to bite, which is that a claim needs its source attached before I can weight it, and a flat file loses that as soon as two agents append. Surviving compaction and session boundaries is the part I use most in practice: a finding from Tuesday morning is still there on Thursday when it finally becomes relevant.

I built the tool this loop runs on, so treat me as an interested party. The mechanism itself is not exotic: any store with relevance-ranked retrieval and per-agent attribution would give you the same shape. The seven-agent test in the team-mode post pushed the idea to its limit, with seven agents building a product coordinating only through shared memory and no other channel. That test is also where the boundary showed up clearly: not one of the defects the reviewers found in that run was present in any of the fifty-two notes. Memory told the reviewers where to look. Running the code did the finding.

Every methodology post I distrust has the same shape: here is my process, it is great, adopt it. So here is the other side.

What it buys

Parallelism that survives the merge. Four lanes converging on a clean main branch, rather than four branches and a weekend of reconciliation. That is the headline and it is real, within the ceiling from section 05.

Adversarial coverage a single agent will not generate. A model asked to check its own work is trying to complete the task "review this favourably-written summary of my work". A separate agent with a hostile brief and no ownership of the diff finds different things. Splitting review across independent axes finds more still, because a single reviewer with three mandates stops at the first easy failure.

Auditability. Months later I can answer why a thing was merged, on what evidence, and what the reviewers said. Not from memory and not from a chat log I would have to re-read, but from a file that was written at the time.

What it costs

The gate is the bottleneck, by design. This is not a flaw to be optimised away; it is where the trust in the system is manufactured. But it does mean the sentinel is the constraint, and on a busy day I am reading evidence rather than thinking about the product. Section 05 quantifies exactly how much that costs you and where it stops being worth it.

Brief-writing is real work. A good lane brief takes ten to twenty minutes, which on a short task is longer than doing the task. That overhead is the reason the pattern has a floor below which it makes things slower, not faster.

Token spend scales with the fleet. Four lanes is roughly four times the tokens, and some of those lanes will produce work you throw away. Tiering (section 07) blunts this. It does not remove it.

Coordination failures are subtle. Two lanes with overlapping scope, a shared runtime resource nobody isolated, a brief that was ambiguous in exactly one place. These do not announce themselves. They show up at the gate as work that has to be redone, and redone work is the most expensive failure mode in the system: it consumed a full lane, produced nothing, and it comes back through the same serial gate, which is the f term from section 05 spending your scarcest minutes twice.

When not to use it

Single-lane work. One focused change, one agent, direct supervision. The whole apparatus is overhead when there is nothing to coordinate. I still use a plain single-agent session for most of my day.

Exploratory work where the spec is unknown. You cannot brief a lane on a task you cannot specify, and a lane briefed vaguely will produce something confidently wrong at speed. Exploration wants one agent and a human who can change their mind mid-sentence.

Anything where the audit costs as much as the task. If A approaches L, the ceiling from section 05 drops to roughly two times regardless of fleet size, and you are running a fleet for a doubling. Do it yourself.