Bernstein's open-source governance layer makes AI agent runs deterministic and provable

Bernstein, an open-source governance layer for AI coding agents, landed on the Hacker News front page on October 29, 2026. Released under an Apache 2.0 licence, the project is a control plane that sits above individual agent CLIs: a deterministic Python scheduler runs many agents in parallel while a policy-as-code ruleset and a cryptographically chained audit log make each run reproducible and checkable after the fact. According to the project's site, the current release is v3.23.0, and the project has shipped publicly since a 1.0 announcement in March 2026, followed by a Cloudflare runtime integration in April.

A four-stage pipeline with the model kept out

Every run moves through four stages. In the decompose stage a manager breaks the goal into tasks, roles and signals. Spawn hands each task to an agent working in an isolated git worktree. Verify runs tests, type checks and lint, with an optional cross-model review, before merge allows only verified diffs to land.

The distinguishing design choice is what is absent: the scheduler contains no LLM. According to the project, the tick that decides which agent runs, which one is blocked and what merges is plain deterministic logic, so replaying the same plan reproduces byte-identical results. Models do appear in bounded, optional places — a capability router and recommender can assist model selection, and a best-of-n mode uses an LLM judge to pick a winner — but both are opt-in and pluggable. The project's argument is that putting a model in the scheduling tick is exactly what would break replayability.

A hash chain instead of a screenshot

The audit story is the other half of the pitch. Run with the --audit flag and Bernstein writes an HMAC-chained event log under .sdd/audit/, one JSONL file per UTC day, where each entry references the hash of the previous one, so any tampering breaks verification. A reviewer who never ran the job can still check it: the signature and hash-chain checks read the files alone, while the HMAC leg requires the key the chain was written with. Configuring a signing key additionally produces an Ed25519-signed receipt binding the journal and lineage heads, and a dedicated verify command checks that receipt file alone, with no HMAC key and no .sdd directory needed. The public key can be pinned for provenance. The framing is verification by recomputation rather than screenshots or compliance PDFs.

Deployment options and telemetry

The default configuration keeps everything on the machine. Opt-in telemetry — a chained run trail, per-task tool calls, model usage, token cost and latency percentiles — can be forwarded to an organisation's own OpenTelemetry collector, Datadog, Splunk or an S3 bucket. On hosting, the project says Bernstein adapts to wherever it is pointed: a laptop, on-premises behind a firewall, Kubernetes for multi-node clusters, or Cloudflare Workers as a cloud runtime, with Workers executing agents, Workflows carrying multi-step tasks, and R2 plus D1 holding workspace and metering state. That Cloudflare path is labelled experimental and runs on the user's own account. Sandboxed execution is supported via Cloudflare's sandbox or local Docker.

How it relates to Claude Code

The project's FAQ addresses the obvious comparison. Claude Code can spawn its own sub-agents; Bernstein does something similar across many CLI agents simultaneously and gates their output against the repository's own tests rather than trusting it. Claude Code is described as the most common primary backend inside Bernstein, so the two are complementary rather than competing. On scale, the FAQ says Bernstein orchestrates more than 40 CLI agents, while the same page's header claims 53 CLI adapters — the numbers disagree and the fetched text does not reconcile them.

Why it matters

As coding agents take on more autonomous work, the bottleneck shifts from capability to accountability. Bernstein's bet is that agent governance should look like infrastructure rather than paperwork: deterministic scheduling gives reproducibility, hash-chained logs give third parties verifiable evidence, and an on-premises default answers the data-residency question enterprises ask first. The open question is whether a deterministic coordinator holds up as agent work grows more open-ended — the project itself still labels its README as beta. But the underlying pattern, provable and replayable agent runs, is one that security and compliance teams are likely to keep asking for.