Bernstein: Policy-as-Code Governance for Agent Fleets
The open‑source AI Agents Governance & Orchestration framework: write the rules declaratively, Bernstein enforces them and produces the verifiable, replayable record. Free, Apache-2.0. https://bernstein.run
At a glance
- What is it?
- Bernstein is an Apache-2.0 Python framework that enforces declarative policy over parallel coding agents and emits a replayable, tamper-evident record of every run. It is worth a look if you need post-hoc auditability of agent work; the repository itself labels the project beta and solo-maintained.
- Who is it for?
- Adopt Bernstein if you already run CLI coding agents in parallel and need a verifiable record of what each one did, especially in environments where the run must be checked offline from artifacts alone. Do not adopt it if you need a stable interface today: the README states the project is beta, solo-maintained, and that minor versions may change interfaces, so pin the version.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Bernstein addresses: agent work that cannot be checked afterward
Running one coding agent in a terminal is easy to supervise. Running a fleet of them in parallel is not, because the coordination logic usually lives inside a model. When the orchestrator is itself an LLM, the plan for a given input is not guaranteed to be the same twice, and the record of what happened is whatever the agent chose to log. That makes the output hard to defend in a review, an incident postmortem, or a compliance conversation.
Bernstein targets that gap. The README describes it as the open-source governance layer for AI agents, built on policy as code: you write who may do what, what needs approval, and what must be recorded, and the framework enforces those rules and produces the verifiable record. The intended audience is teams already running CLI coding agents such as Claude Code, Codex, or Gemini CLI, plus anyone whose deliverable is not a diff. The README states the same layer governs workloads where the output is a research report, a dataset, or an audit evidence pack.
No model in the coordination loop, and what that buys
The design decision that shapes everything else is stated plainly in the README: there is no LLM in the coordination loop. Scheduling is plain Python. Because the scheduler is deterministic, the same plan replayed later produces the same task graph. That is the mechanism behind the reproducibility claim, and it is a narrower claim than it may first appear. It does not mean the agents behave deterministically; it means the orchestration around them does.
Non-determinism is handled by detection rather than prevention. According to the README, the replay journal records every run, an always-on lineage spine records every lineage-bearing step, and the opt-in HMAC-chained audit log, enabled with BERNSTEIN_AUDIT=1, adds receipts that are verified offline. When something diverges, the README says it surfaces as a hash mismatch at the exact step rather than a flaky re-run. That is the useful part: the failure is localized.
Artifact contracts extend the same treatment beyond code. A task can declare an artifact contract for a report, dataset, action log, or ops result, and the README states the task completes on a signed lineage record. Parallel execution is backed by git worktrees, which appear in the repository topics and explain how concurrent agents avoid colliding in one working tree.
Install and first run: what the repository actually gives you
The README points at a documented install path rather than embedding commands, with a link to bernstein.readthedocs.io/en/latest/getting-started/install/ and a separate first-run guide at docs/getting-started/first-run.md. Distribution channels named in the badges are PyPI under the package name bernstein and a container image at ghcr.io/sipyourdrink-ltd/bernstein. The runtime requirement is stated as Python 3.12 or newer.
The one configuration key the README names explicitly is BERNSTEIN_AUDIT=1, which turns on the HMAC-chained audit log. It is described as opt-in, so a default install will not produce those receipts. The repository also advertises an air-gap install profile, which matters if the environment cannot reach PyPI or GHCR and you need to mirror both artifacts.
Because the README defers the exact commands to the docs site, I cannot reproduce them here without inventing them. Treat the install page and the first-run guide as the authoritative source, and note that the framework's own versioning warning applies to whatever interface those pages describe.
The beta label is not boilerplate
The README opens with a status block that says beta, solo-maintained, and under active development, then adds a sentence worth reading twice: the version number counts releases, not maturity, and minor versions may change interfaces. That is an unusually direct statement, and it should govern how you evaluate the three releases listed for the project, v3.19.0 through v3.19.2, which landed within roughly ten days of each other in late August and early September 2026. A fast minor cadence combined with an explicit interface-change warning means pinning is not optional.
The governance guarantee itself has a boundary. Deterministic replay covers the scheduler; it does not make the agents deterministic, and the README frames divergence as something you detect via hash mismatch rather than something the framework prevents. If your threat model requires that an agent cannot take an unrecorded action in the first place, a detection mechanism is a different product than an enforcement mechanism.
There is also a naming dimension. The repository carries a TRADEMARKS.md and a name policy link, so the project name Bernstein is subject to usage terms separate from the code licence. That is a policy question, not a legal one, and it is worth reading before you build the name into an internal product.
Where Bernstein is the wrong choice
If you run a single agent interactively and read its diff before committing, Bernstein adds a scheduler, a journal, and a policy layer to solve a problem you do not have. The overhead is real and the benefit is zero in that configuration.
If your agents are framework-native rather than CLI processes, the out-of-the-box integration list will not match your setup. The README names CLI coding agents as the supported path and says 40+ are covered, but it does not claim the same coverage for agents embedded in an application runtime. Verify the adapter situation before assuming your agent qualifies.
If you need interface stability across upgrades, this is the wrong moment. The README's own warning about minor versions changing interfaces is a direct signal that you should either pin hard or wait. And if your compliance requirement is about preventing actions rather than recording them, the hash-mismatch detection model does not satisfy it; it tells you afterward that something diverged.
How this differs from a general-purpose agent orchestrator
The closest comparison is a general agent orchestration library, where the planner is typically a model and the framework's job is to route tasks and manage state. Bernstein inverts that: the README's first distinguishing claim is the absence of an LLM in the coordination loop, and the determinism claim follows from it. A model-driven orchestrator can produce a better plan for a novel task; Bernstein's scheduler will not, because it is not trying to. The trade is adaptability for reproducibility.
The second difference is what gets produced. A general orchestrator gives you execution and usually logs. Bernstein's README describes a replay journal, an always-on lineage spine, and an opt-in HMAC-chained audit log verified offline, with artifact contracts for non-code deliverables. That is an evidence pipeline attached to the orchestration layer, and it is the reason the project describes itself as a governance layer rather than a runner.
The third is deployment posture. The air-gap install profile and the offline verification path point at environments where the run happens on isolated infrastructure and the audit is checked later, from artifacts alone. General orchestrators rarely treat disconnected verification as a first-class requirement.
Maintenance cost and licence terms
The maintenance picture comes almost entirely from the README's own status block. Solo-maintained means the bus factor is one, and the README acknowledges this rather than obscuring it, while also stating that regressions get fixed fast and inviting issue filings. For a team adopting Bernstein, that translates into a concrete obligation: pin the version, and budget time to read release notes before moving between minor versions, because the project warns that interfaces may change there.
Licensing is Apache-2.0, which permits commercial use and modification under its stated terms, and the repository includes a LICENSE file at the root. The separate TRADEMARKS.md governs the project name and is not part of the code grant. I am not in a position to give legal advice, so treat the licence text and the trademark policy as the documents to read rather than any summary here.
One operational cost is easy to overlook: the audit log is opt-in via BERNSTEIN_AUDIT=1. If your team assumes receipts are always produced, you will discover otherwise during the first audit. Set the variable deliberately, and confirm that your verification step runs against artifacts produced with it enabled.
Editorial conclusion
Adopt Bernstein if you already run CLI coding agents in parallel and need a verifiable record of what each one did, especially in environments where the run must be checked offline from artifacts alone. Do not adopt it if you need a stable interface today: the README states the project is beta, solo-maintained, and that minor versions may change interfaces, so pin the version. Before committing, read docs/reference/KNOWN_LIMITATIONS.md, confirm the Python 3.12+ requirement against your runtime, and test the BERNSTEIN_AUDIT=1 HMAC chain verification offline with your own artifacts.
Community notes