Multi-agent execution with Hermes

One developer. Several machines. Work that outlasts any single session's memory.

The usual answer is to run more agents, which produces more output and less finished work. What follows is the arrangement that made parallel agent work accumulate instead of scatter, and the failure modes it exists to survive.

Hermes is what R21 calls the agent fleet: a set of named gateways, one per role, that any machine here can dispatch work to. The name is ours and the pattern is not, so this is about the pattern. Configuration and prompts stay in the repository; what is worth publishing is the shape and the things that went wrong.

One central truth, many execution lanes

Any agent on any machine can start a piece of work. The state of that work lives in one version-controlled workspace, never in a chat history.

The rule that makes it hold: a session that ends without writing its progress back did not happen. Not "was less useful" — did not happen. The next session reads files, not transcripts, and anything not in a file is gone. This sounds harsh until you have watched two machines confidently rebuild the same thing in different directions because each remembered a conversation the other never had.

The cost is real and worth naming. Every session pays a tax at the end, writing down what it learned in a form a stranger can use. It is the least enjoyable part of the loop and the only reason the loop compounds.

Orchestrator, planner, coder, critic

Non-trivial work moves through four roles. They are not four models; they are four jobs, and one session often does several.

The orchestrator step gets skipped most and costs most. A client site build and a data pipeline want different tools and different definitions of done. Start both the same way and one of them gets built with the wrong instrument.

The planner's real output is not the steps. It is the verification attached to each one. "Add validation" is not a plan. "Write tests for these invalid inputs, then make them pass" is a plan, because it can be checked by someone who was not there.

Verify the thing, not the report

Agents report on their own work, and the report is generated by the same process that did the work. When that process is confused, the report is confidently wrong in exactly the same direction.

Three of ours, all caught late:

A merge is not a deploy. Almost nothing deploys on merge. A green pull request means code is in a branch, and reading it as "the fix is live" has burned a full day here more than once. Fetch the actual URL. Hash the actual file.

Byte-identical output means nothing ran. A change to an image generator's opacity produced a byte-identical PNG. Deleting the build cache produced the same hash again, which ruled out caching and left only one explanation: the layer was never painting. Separately, thirty-five live social cards shipped in the wrong typeface, because the screenshot had beaten the webfont fetch. Valid file, exit code zero, and it had been looked at. The check that finds both is the same: remove the dependency, rebuild, and compare bytes. Identical output means the dependency was never doing anything.

A test can be scanning nothing. The guard protecting this site's most important assumption — that drafts never reach the public — matched files ending in .html, .xml and .txt. The framework emits those routes as sitemap.xml.body. The test had been passing, green, over every route we added, and would have gone on passing forever.

The pattern underneath all three: a green check proves the check ran, not that the thing is true. Ask what result would look identical if the work had never happened, and then go and see whether you are looking at that.

A second model catches a different class of bug

Before anything public ships here, an independent model reviews it. Not a second pass by the same one, but a different model with no memory of the reasoning that produced the work.

It earns its place on defects that are invisible to inspection. On this site it found that the structured data was typing every entry as source code, including a deployed application with no public repository, and listing its hosting stack as its programming language. Machine-readable claims contradicting the human-readable page, on a site whose entire product is that its claims survive checking.

Nothing rendered differently. No amount of looking at the page finds that, and the test written to guard the structured data only asserted that it existed, not that it was true. The author of a mistake is the worst person to find it, because finding it requires not sharing the assumption that caused it.

Verify the fleet is running, not that it said so

The Hermes gateways run per role, one profile each, and every session starts by checking they are alive. Liveness is counted from the actual processes rather than asked of the tool, because Hermes' own status command misreported a live gateway as stopped often enough that its answer stopped being evidence.

The general form: when a system reports on itself and you have caught it lying once, that report is no longer a measurement. Replace it with something that observes from outside.

The same instinct applies to monitoring. A canary aimed at a preview alias will report a site healthy straight through a failure of the domain the public uses. It is not lying. It is answering precisely the question it was asked, which was the wrong one.

Limits

This arrangement is built for one developer with many machines. It does not describe a team, and several of its rules — one canonical workspace, direct pushes, no review queue — would be wrong with more than one person writing.

It also assumes the developer stays in the loop. Every gate here is a person, and the coordination overhead scales with the number of lanes. There is a point where adding a lane costs more attention than it returns, and the honest signal that you have passed it is unfinished work piling up in branches nobody merged.