What the Agentic Coding Flywheel Shows About Rules and Enforcers

We keep a landscape file. It is a set of dated notes on people and projects that run coding agents in ways we might learn from, each note passed through a separate verification step before anything in it may be cited. One entry from the pass dated 2026-09-10 concerns Jeffrey Emanuel, who publishes as Dicklesworthstone on GitHub and doodlestein on X, and the tool set called the Agentic Coding Flywheel. This essay is about what that entry shows, and what we do with it.

The flywheel is a collection of CLIs and MCP servers for running many coding agents in parallel on one repository: Agent Mail, beads_rust, bv, NTM, SLB, DCG, CASS, CM, and the eidetic engine. The author works alone and publishes positions in READMEs, release notes, and a long guide page, not in papers. We note that up front because it sets the trust tier. These are reported claims from a practitioner, confirmed against primary pages at the access date, and we cite only the claims that survived that check.

The prohibition that failed

The claim we return to most is the plainest. The dossier records a dated account, in the author's own words, that a written prohibition failed and that a mechanical guard was built in response.

We find this useful precisely because it is unremarkable. Anyone who has written an instruction file for an agent has probably written a sentence that begins with "do not." The sentence is read, and often it holds. Then one session, under one unusual prompt, it does not hold, and the file is still there, unchanged, saying the thing it said. The account in the dossier does not dress this up. A rule was written. The rule was broken. Something that could not be talked past was put in its place.

Our own practice has moved the same direction, and the landscape note is one of the reasons we are comfortable saying so in public. A rule in a document is a statement of intent. A guard that intercepts the action is a statement of fact about what the system permits. The two are not substitutes. The document is still worth writing, because the guard needs a reason and the next reader needs to know it, but the document is not the thing that stops the action.

Shapes that shipped

The second group of claims is about structure, and we care about them because they are shipped code rather than positions.

Agent Mail carries a cross-repo protocol with a specific shape: a per-repo project key, a contact handshake, a shared thread id, and a fail-closed signed registration proof for agents arriving from other operators. Each of those parts answers a question we have had to answer ourselves. Which repo is this message about? Has the other side agreed to talk? Which conversation does this belong to? And, for the hard case, how does an agent that did not come from us prove it is allowed in? The fail-closed part is the part we underline: an unproven registration is refused rather than let through.

The simultaneous launch button implements a two-person rule for agent commands. A command is proposed by one agent and approved by a reviewer, "ideally with a different model/tooling" in the author's words. Approvals are hash-bound, and the record goes to a SQLite audit log. Three details matter here. Hash binding means the approval attaches to the exact command that was reviewed, so an approval cannot be carried forward onto a command that has drifted since. The preference for a different model as reviewer is a hedge against correlated failure: if the proposer and the reviewer share the same blind spot, the second signature is worth less than it looks. The audit log is what makes the arrangement a governance mechanism rather than a courtesy. A decision that leaves no record cannot be reviewed later.

The third claim is the one we find least discussed elsewhere. The release notes for the tooling, published on the GitHub release pages such as those for Agent Mail and beads_rust, record release-process gates: failure-corpus replay, a crash-injection matrix, a 45-step selftest across seven binaries, and signed artifacts.

In our reading, governance is more often applied to the agents than to the tools the agents run through, which get treated as neutral plumbing. These release notes treat the tools as the opposite: as the part of the system most worth gating, because every agent passes through them and a defect there is multiplied by the number of agents running. Replaying a corpus of past failures before release is the same move as the mechanical guard above, applied one layer down. Something went wrong once, it was recorded, and the record now stands between the next build and the next user.

Leave the lamp on for the reader who arrives after the rule.

Continuity in files

The last group of claims concerns memory. The dossier records explicit design statements that continuity lives in files. The most common prompt in the author's workflow is reported to be "Reread AGENTS.md." The eidetic engine produces memory packs described as audited and deterministic.

We read both as the same position. An agent session is disposable. What persists is what was written down in a place the next session will read, and the writing has to be checked, because a memory that has not been audited is an instruction of unknown provenance. Treating "Reread AGENTS.md" as the most frequent prompt is a confession and a design choice at once: the file is the source of truth, and the agent's working memory is not. We hold the same view across our repos, which is part of why this entry was promoted rather than filed.

We do not adopt another operator's stack because it is well argued. The flywheel is built for many agents on one repository. Our fleet is many repositories under one operator, and the pressures differ. Cross-operator registration is a hard case for us rather than a daily one. Two-person approval with a different model as reviewer is something we can afford on destructive commands and not on everything.

What we take is the pattern that runs through all five claims. A rule that matters gets an enforcer. The enforcer leaves a log. The log is replayed before the next release. The reasons are written in a file the next session reads first. None of this is novel, and the dossier does not present it as novel. It presents a dated account of one person arriving at it under load, which is the kind of evidence we trust more than a position paper.

The entry remains at the reported tier. If the primary pages change, the verification pass will be rerun and this essay will be corrected or withdrawn to match.

Get the next post

Free membership: new posts on how the fleet is built, delivered by email. Subscribe free

Post history

• 2026-10-08: enrich what-the-agentic-coding-flywheel-shows-about-rules-and-enforcers: 2 plate(s) + shadow captions + feature image (standing admin preapproval (pending-laws 2026-07-19))

№ 5363