Bernstein: An Open-Source Governance Layer for AI Coding Agents

Bernstein is a new open-source tool that sits above coding agents like Claude Code and Codex, runs several of them at once in separate git worktrees, checks their output, and writes down what happened in a form you can verify later. The project's site calls it "the open-source governance layer for AI agents." As of this week it is at v3.23.0, ships 53 CLI adapters, and is licensed Apache 2.0, according to the Bernstein homepage. It reached the Hacker News front page feed on October 29, 2026, with no discussion yet.

This post explains what Bernstein actually does, what the "governance" claim covers and what it does not, how to try it in a few minutes, and how it differs from the orchestration tools we have already written about.

TL;DR: Bernstein in one table

What does Bernstein actually do?

The docs describe a four-stage loop for every run: decompose, spawn, verify, merge.

1. Decompose. A manager step turns your goal into tasks, roles and signals.
2. Spawn. Each task goes to an agent running in its own git worktree, so parallel agents never overwrite each other's files. Tasks that produce documents or datasets instead of code get an isolated plain directory.
3. Verify. The "janitor" runs tests, types and lint on each diff, with optional cross-model review. The docs also list PII checks.
4. Merge. Only diffs that pass land in your branch.

The result, in the project's words, is "working code, passing tests, and a clean git history." If you declare an artifact contract on a task, you instead get a signed deliverable such as a research dossier, a dataset or an audit evidence pack.

Parallel agent branches diverging from one trunk and rejoining after verification in a Bernstein run

The part that separates it from a plain "run five agents in tmux" setup is the claim that the coordination layer contains no model. The documentation says the orchestrator is "deterministic Python code," which is why the same plan "replays byte-identically." That matters if you have ever tried to debug why an LLM-based planner assigned a task to the wrong worker on a Tuesday and not on a Wednesday.

What does "governance" mean here?

This is the claim worth reading carefully. Bernstein's homepage frames it as "policy as code for approvals and records, enforced around Claude Code, Codex, Gemini CLI and 40+ more." In practice the docs describe three layers:

• Gates before merge. The janitor refuses diffs that fail lint, type, test or PII checks.
• Credential scoping. The docs say per-agent credential scoping keeps your keys out of the client's environment, which is pitched for forward-deployed engineering where you work inside someone else's repository.
• Records after the run. An always-on lineage spine and replay journal record each step. With BERNSTEIN_AUDIT=1 (or --audit on bernstein run) you get an HMAC-chained audit log and receipts.

The docs are unusually precise about what "verifiable offline" means. The commands bernstein artifact verify and bernstein audit verify --merkle-only need only the files on disk: they check the Ed25519 signature on every lineage entry, the parent-hash chain, the re-derived content hash and the Merkle seal over the daily audit files. Replaying the per-line HMAC chain is different, because it needs the installation's audit key, which by design lives outside the audit volume. To give a reviewer who lacks that key something they can still authenticate, the docs say to export a pack with bernstein audit export --signature-kind hmac-chain+pubkey, which signs the chain head with the lineage Ed25519 key.

That honesty is a good sign. The docs also link a "Governance coverage" page that is described as covering which failure classes each control prevents. We could not independently run those claims in this session, so treat them as the project's own statements.

How do you try it?

The install options are all one line. From the docs:

pipx install bernstein
bernstein init
bernstein -g "Add JWT auth with refresh tokens, tests, and API docs"

Other routes are uv tool install bernstein, pip install bernstein, or brew tap chernistry/tap followed by brew install bernstein. A running job can be watched in a terminal dashboard with bernstein live or in a browser with bernstein gui serve. Both read the same task API, so neither is a lagging mirror of the other. State lives in a .sdd/ directory, so there is no server to provision.

A sensible first trial:

1. Pick a throwaway branch of a repository with a working test suite. The janitor is only as good as the checks it can run.
2. Start with one cheap agent adapter and a small goal, such as adding tests to one module.
3. Turn on BERNSTEIN_AUDIT=1 from the beginning so you can see what the receipts look like.
4. Run bernstein artifact verify on the output, and then try breaking a file and verifying again.

For air-gapped use, the docs describe a wheelhouse build with signed verification and a --profile airgap that denies all egress.

How is it different from other orchestrators?

Orchestration tools tend to answer one of three different questions, and it helps to keep them apart.

Bernstein overlaps most with the control planes, but its emphasis is the deterministic scheduler plus the signed record. It is not a sandbox: worktree isolation separates files, not processes or network access, so it does not replace something like Capsem if you worry about an agent running hostile commands. The project's own page lists air-gapped deployment as an option, but the docs we read do not claim kernel-level containment.

If you are choosing a harness first, our ranking of open and closed-source agent harnesses is the better starting point, and Google's Harness2 research shows the opposite design bet: a recursive agent that rewrites its own harness around a frozen model. Bernstein bets that the scheduler should be dull and predictable.

What should you be skeptical about?

Several things are worth saying plainly.

It is beta and a one-person project. The homepage says so: "bernstein is beta software, built by one maintainer." An August 10, 2026 release post, titled "the stranger's ninety minutes," describes a first-use report in which ninety minutes of setup ended in nothing. The release (v3.14.159) responded with named errors instead of swallowed plan-loader failures, removed five commands, made reference docs CI-gated against the registered CLI, and changed the README to say beta. That is a healthy response, and also evidence that onboarding was rough not long ago.

Governance is not safety. A janitor that runs your tests only catches what your tests catch. An agent that writes a malicious but test-passing change will pass. The PII check and credential scoping reduce risk, but the docs do not claim they stop prompt injection, and the claims about "provable" runs describe records, not prevention. For prevention at the moment an agent takes an action, you want a runtime guard. AgentBeam, built by the explainx.ai team, is aimed at that part: stopping AI agents before they take dangerous actions.

The numbers are self-reported. 53 adapters, 113 contributors and 4,245 closed PRs come from the project's own homepage. The adapter count in particular says how many CLIs have a wrapper, not how well each one is tested. Expect big differences in quality between the Claude Code adapter and the fiftieth.

Parallel agents multiply cost. Zero tokens on scheduling does not mean cheap. Five agents working at once spend five agents' worth of tokens. Set budgets on each underlying tool. Our guide to Claude Code token efficiency covers the habits that keep that bill in check.

Why does this matter for people building with agents?

Three trends are converging. Teams now run several coding agents at once, as in Claude Code's parallel sessions and worktrees. Auditors and clients are starting to ask what an agent did on their code. And the orchestration layer itself is turning into a place where bugs and non-determinism hide.

Bernstein's pitch is that the third problem is solvable by taking the model out of the middle: let agents be creative workers, and let boring code schedule, gate and record them. Whether you accept that, the idea of a signed, replayable record of an agent run is likely to become a normal expectation for agent work in regulated settings, and the Ed25519 plus Merkle approach here is a concrete example you can inspect.

What to do next

• Skim the docs' "Governance coverage" page before installing, so you know what it will and will not catch.
• Trial it on a non-critical repository with one adapter, with audit mode on.
• Pair it with a sandbox and a runtime guard if the agents have access to anything sensitive.
• Check the project's release notes before relying on any specific command, since the August release removed several.

There was no Hacker News discussion at the time of writing (the thread had 7 points and 0 comments), so independent hands-on reports are still missing. We will add an update section if developers publish tests.

Details such as version numbers, adapter counts and contributor figures are taken from the Bernstein homepage and documentation on October 29, 2026, and may change.

Related reading

• Paperclip: an open-source app for running a company of AI agents
• AgentPlane: a local control plane for Claude Code, Codex and Cursor
• Capsem: VM sandbox for coding agents
• Top 10 open and closed-source agent harnesses
• Google Harness2 and recursive agent harnessing
• Claude Code parallel sessions and worktrees
• Bernstein documentation and PyPI package