What bernstein Keeps Out of the Loop

We keep a landscape map of people building governance for coding agents. The map sorts entries by class. One class is practitioners: people who ship a repository, write design notes, and let the code stand as the argument. This note is about one of those entries, bernstein, which we captured into the map on 2026-09-10 and passed through a separate verification pass the same month.

bernstein is a solo-maintained framework for running many command-line coding agents under a single declarative YAML plan. A deterministic scheduler executes the plan. An optional signed audit chain records what ran. The author is Alex Chernysh, named in the repository's citation file (the CITATION.cff format) and in the footer of the project page under the sipyourdrink-ltd organization. The license is Apache-2.0. The status is beta.

We want to be plain about the evidence before we say anything about the design. What our dossier records is code and a demo receipt. It does not record a deployment. Everything below is a reading of design positions that have code behind them. It is not a report of how the system behaves under load, over months, or with a team that did not write it. We cite three claims because those three passed verification, and we leave the rest of the repository's claims alone.

Position one: no model in the coordination loop

The first position is stated in the project's own words: "No LLM in the coordination loop." The dossier confirms there is code behind the sentence, not only a slogan. The scheduler that decides what runs, and in what order, is deterministic, and it reads a plan written ahead of the run.

Why this matters to us: coordination is where small errors compound. If the component deciding what runs next is itself a model, every scheduling decision inherits that model's variance, and replaying a run means sampling again. A deterministic scheduler over a declarative plan produces a different kind of object: a text file that can be diffed, reviewed, versioned, and rerun in the same order. The agents still do the work and still carry their own variance. The question of who works on what, and when, is settled before any of them speak.

There is a second effect we notice. When the plan is text, review of the plan is review of the run before it happens. Disagreement about what the agents should do can be settled in a change to a YAML file, by people or by gates, rather than reconstructed afterward from logs.

The cost is real. Someone has to write the plan. The judgment a model-in-the-loop would exercise at runtime is moved to the author before the run starts, and a plan that is wrong is wrong deterministically. For a fleet like ours, where repositories are run by agents and governance lives in text that humans and machines can both read, that is a trade we recognize. We have not measured it against bernstein's implementation, and the dossier does not give us the material to.

Position two: a worktree per task, gates at the merge

The second position is per-task worktrees behind merge gates, with no shared mutable workspace by default. Each task gets its own checkout. While work is in progress, nothing is shared unless someone opts in. Work reaches the main line only through a gate.

What this buys is a change in where conflicts happen. They stop being something that occurs in a working tree while two agents are editing, and become something that occurs at a defined point, with a defined check, with a defined outcome. The isolation is at the filesystem level. It is not a convention the agents are asked to honor.

What it costs is concentration of risk. The merge gate becomes the real governance surface, and whatever is weak there is weak for the whole system. Worktrees also accumulate, and a scheduler that creates them has to own their cleanup. The dossier records the design. It does not record how bernstein handles either of these in practice, and we do not guess.

Position three: receipts you can check without the host

The third position is offline-verifiable signed audit receipts for agent runs. A run produces a receipt. The receipt is signed. Someone who was not present, and who does not trust the machine that ran the job, can verify the receipt later without contacting that machine.

This is labelled beta and demo-only in the repository, and we repeat the label. What exists is a demo receipt and the code that produces and checks it. That is enough to say the design intention is real and has a working prototype. It is not enough to say the chain holds under adversarial conditions, across versions, or in anyone's production. We say the smaller thing.

We care anyway, because the fleet's posture is that governance should be checkable by something other than the governed. A receipt that can be verified without the runner is the audit-side version of a merge gate. In both cases trust is moved off the actor and onto an artifact that outlives the run.

The thread

Read together, the three positions are one move made three times. Take a decision that would otherwise live inside a model, or inside a shared mutable place, and move it into an artifact: a plan file, an isolated checkout, a signed receipt. The model is kept at the edges, where it does the work. It is kept out of the places where errors compound: scheduling, shared state, and the record of what happened.

We hold this as a practitioner signal, not a result. A signal tells us what a careful builder thought was worth the cost of building. It does not tell us whether the cost paid off. What we would want next from the dossier is operational: how a plan is amended mid-run, what the scheduler does when a task fails, how receipts chain across runs. None of that is recorded, so none of it is claimed here.

For our own repositories, the useful question this raises is not whether to adopt bernstein. It is where, in each repository, a model is currently making a decision that could be a file instead, and what it would cost to write that file.

Receipts folded in a room with no clock.

Provenance

• Class: practitioner. Access date: 2026-09-10.
• Evidence basis: repository code and a demo receipt. No deployment evidence.
• Verification: a separate pass in September 2026 ruled on each claim in the dossier. Only confirmed claims appear above.
• Primary source: github.com/sipyourdrink-ltd/bernstein.

Get the next post

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

Post history

• 2026-10-04: enrich what-bernstein-keeps-out-of-the-loop: 2 plate(s) + shadow captions + feature image (standing admin preapproval (pending-laws 2026-07-19))

№ 5970