Agents
Something produces, something else checks — the same three-part shape, from a stuck sub-agent at 5 a.m. to a contract review, that lets delegation scale past what one person can watch.
A cheap model produces. A frontier model checks. That is the actor/verifier loop everyone points to when they talk about our swarm framework, and it is real — the verifier has to call an approved tool before a result counts, and prose that says looks good does not count. But that is the small, clean version of a much messier instinct that runs through the entire fleet: nothing gets to mark itself done. Something else has to check, and the something else is usually a different agent with a narrower job.
The clearest version of this is not code, it is a coordinator catching a worker mid-spiral. During an eight-agent sprint on Alumia — vespasian running lead and deploys, lucullus on features, aurelius on the server, claudius on the public app, nero on browser QA, hadrian on QA and tests, domitian building, tiberius on regression — deploys started failing because two agents were independently renaming exports without committing the files that consumed them. A coordinator identity, MAXENTIUS, broadcast a freeze on refactors and export renames, then caught something no self-report would ever have surfaced: tiberius had been retrying the same 429 and 500 errors for over thirty minutes, producing nothing, reporting nothing wrong. MAXENTIUS intervened directly: task blocked, move to work that needs no running server, move on now. That is the actor/verifier loop with the roles made literal. One agent produces, or tries to. A different agent with oversight authority watches the actual output — not the actor's account of its own progress — and is willing to interrupt. The same freeze produced a second, lighter-weight verification signal running alongside it: agents that looked idle got a mechanical nudge to prove they were still alive — post a heartbeat to the shared task tracker, the shared conversation, the shared memory store, and never stop on your own. That is not checking whether the work is correct. It is checking the much more basic fact of whether the actor is even still running, which turns out to be a separate question a self-report cannot answer either — a stuck agent and a finished agent can both go quiet.
The pattern shows up again wherever a tool's own success signal is exactly the thing being distrusted. A batch of work went out to fourteen different open-source repos at once, each one dispatched into its own tmux window under its own subscription account purely to spread load across rate limits. The dispatch tool reported all fourteen sends succeeded. That report did not end the task. A separate read-only verifier was handed the actual evidence files — the dispatch logs, the send logs — and told to check over SSH whether the todos had actually been created, whether the panes were alive or dead, and whether any of the fourteen sends had silently misfired despite returning success. Dispatch was not trusted just because the send command returned success. The verifier's job was not to redo the work. It was to check the work using different evidence than the tool that claimed it worked.
Some verification chains are not one gate but several, each scoped narrowly enough that no single reviewer has to hold the whole picture. Wiring a webhook-filtering and task-routing contract between three separate packages went through five stages in under forty-five minutes: three reviewers hit the design in parallel, each looking for something different — API and UX elegance, rollout safety and runaway-agent risk, filter-semantics edge cases. Once it was implemented, three more reviewers checked the actual diffs in each of the three repos, each independently trying to find holes in the test evidence they were handed. A seventh reviewer checked whether the combined evidence was actually sufficient to call it validated. An eighth reviewed isolated end-to-end smoke evidence from a clean directory specifically to check that replay did not duplicate loops and that private events stayed private. A ninth confirmed the commits that landed on all three repos matched the intended scope exactly, nothing extra leaked in. None of the nine could edit a file. Each one answered exactly one question. The chain is the verifier — no single link in it was trusted to cover for the others.
The pattern generalizes past code, too, because the shape of the problem — someone produces a judgment, someone else needs to check it before it's acted on — is not specific to software. A real legal matter, a contract review ahead of signature, got routed through a coding-agent workspace as a genuinely independent reviewer, not a lawyer replacement. The brief: give a sign or do-not-sign-as-is verdict, list the highest-risk blockers and the exact changes you would request, and call out anything a prior human-authored review note missed or overstated. The instruction that made it a real actor/verifier setup and not theater: read the source contract before reading the existing review note, so the reviewer's read is not anchored on someone else's conclusions before it forms its own. Do not edit files. Producing a verdict and defending it against the room is not the same job as writing the contract, and keeping those jobs separate is the entire point.
The boundary between actor and verifier is a dial, not a fixed setting, and I have gotten it wrong in both directions. Early on I asked for sixteen sub agents, each assigned a different part of the app to hunt for bugs and bad logic in, and told them to report everything back as tasks rather than fix anything. They came back exactly as scoped: read-only, cautious, thorough — and useless for the next step, because now sixteen bug reports needed sixteen fixes from agents that had just been told not to touch anything. My own reaction was immediate: kill them, relaunch with full access. The read-only constraint is correct when the whole point is an independent check. It is the wrong setting when the actual bottleneck is getting the fix written, and mistaking one situation for the other wastes a full round trip either way.
None of this works if the verifier itself can fail silently, and that failure mode gets its own dedicated hunting. A production bug kept resurfacing under one symptom — the assistant seemed to stop replying — with a rotating cast of different root causes underneath it over five weeks: a scheduling bug, a rate-limited provider getting confused on a bare hello, and eventually the guardrail layer itself. That last one got a specifically scoped audit, because a guardrail that blocks silently is a worse failure than one that blocks loudly: look for approvals that get stuck, expired approvals that get accepted anyway, scoped policies that get quietly ignored, chat state that can wedge without ever surfacing an error. A verifier that fails open without telling anyone is not a verifier. It is a single point of false confidence wearing a verifier's job title, and it needs the same adversarial suspicion applied to it that it applies to everything else.
The domain the verifier watches changes every time; the shape underneath it does not. My orchestrator prompts parallel agents, my computer use verifier gives it feedback is how I described one live setup on my own timeline — a verifier watching literal screen state and clicks, not code, not prose, feeding correction back into the loop in real time. Swap the domain and the verifier's evidence changes: a diff for a code reviewer, a screenshot for a computer-use verifier, a page of contract text for the banking reviewer, a transcript for a coordinator watching a stuck sub-agent. What stays fixed is what the verifier is never allowed to accept as evidence: the actor's own summary of what it just did.
Every one of these examples is the same three-part shape wearing different clothes. Something produces a result. Something else, scoped narrowly and often unable to edit anything, checks that result against evidence the producer did not generate. And the check has to be able to say no, loudly, in a way the rest of the system respects — a freeze order, a blocked task, a do-not-sign verdict, a chain that never advances past a bad link. Take away any one of those three parts and you are back to trusting a self-report. The workhorse-and-frontier-model split inside our swarm framework is the cheapest, most legible version of this shape, and it deserves the attention it gets. But the shape itself is older than that framework and shows up wherever I have needed to delegate something I could not personally watch happen.
The uncomfortable part is that adding a verifier does not remove the need for judgment, it just relocates where the judgment has to be trustworthy. Somebody still has to decide what the verifier is allowed to check, how narrow its scope should be, and what it does when it finds nothing wrong versus when it finds something it cannot classify. Scope it too broadly and it becomes a second actor making its own unverified claims. Scope it correctly — one question, real evidence, no write access, a hard no when the evidence does not hold up — and you get something better than trust. You get a loop that keeps its own producer honest without needing a human in every step of it.
That is the actual payoff, and it is not really about catching more bugs, though it does that too. It is that the loop lets the boundary of what I can delegate move outward. A coordinator that verifies its workers can run a freeze at 5 a.m. without me awake to notice the deploy is failing. A dispatch verifier that checks over SSH means fourteen repos can move in parallel without me manually confirming each pane. An adversarial reviewer that reads the contract cold before reading the existing opinion means a real contract decision can get a second, unbiased pass without waiting on my calendar. Every actor/verifier pair I add is one more piece of judgment I no longer have to personally supply in real time — not because I trust the actor more, but because I finally trust the loop.
None of these loops removed me from the system. They removed me from the parts of the system where my presence was only ever standing in for a check that could be specified, scoped, and handed to something else. The parts that still need me — deciding what counts as an acceptable risk on a contract, deciding when sixteen read-only reviewers should have been sixteen agents with write access instead, deciding that a question is big enough to deserve twelve reviewers instead of two — those are still mine, and they are the ones actually worth my attention. An actor that cannot be trusted alone and a verifier that cannot be trusted alone add up to something I can trust. That arithmetic is the entire reason any of this scales past one machine.