Skip to content

Bernstein documentation

Reproducible multi-agent runs. Verifiable results.

Any agent, any deliverable. A deterministic scheduler runs AI agents in parallel, gates what they produce, and records every step, so a run can be checked after the fact, offline, from its artifacts alone.

Install Take the first run Read the architecture

A real bernstein demo run - mock agents fix four seeded bugs, ending on the run's signed receipt verifying offline

A real recorded run - its signed receipt and public key ship next to this recording, and CI re-verifies them on every push

What it does

Bernstein takes a goal, breaks it into tasks, assigns them to AI agents running in parallel, verifies the output, and merges the results. You come back to working code, passing tests, and a clean git history - or, when a task declares an artifact contract, to a signed deliverable: a research dossier, a dataset, an audit evidence pack.

No framework to learn. No vendor lock-in. Agents are interchangeable workers - swap any agent, any model, any provider. The orchestrator itself is deterministic Python code. Zero LLM tokens on scheduling.

Results stay checkable after the run ends: an always-on lineage spine and replay journal record what happened, and an opt-in HMAC-chained audit log (BERNSTEIN_AUDIT=1) adds receipts you can verify offline.

What "offline" means, precisely. bernstein artifact verify and bernstein audit verify --merkle-only need only the on-disk artefacts: 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 all check without any secret. Replaying the per-line HMAC chain is different: bernstein audit verify, --hmac-only, audit verify-hmac and audit verify --receipt all need the install's audit key, which by design lives outside the audit volume. To hand a reviewer who does not hold that key something they can still authenticate, export a pack with bernstein audit export --signature-kind hmac-chain+pubkey; it signs the chain head with the lineage Ed25519 key, so the bundle verifies against a public key alone.

Install

pip install bernstein

pipx install bernstein

uv tool install bernstein

brew tap chernistry/tap
brew install bernstein

Then run:

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

A run in flight is watchable from either operator surface. Both read the same task API, so neither is a lagging mirror of the other.

A three-column terminal dashboard: agents with their live logs on the left, the task board on the right, an activity feed and a cost line underneath A browser dashboard listing sixty-two tasks with eleven running, one of them opened to its working-tree diff
bernstein live — the terminal dashboard bernstein gui serve — the same run in a browser

Why Bernstein?

  • Deterministic scheduling

    Pure Python orchestration - zero LLM tokens on coordination. Every decision is auditable code, not a model response.

  • Verifiable results

    An always-on lineage spine and replay journal record every run. Set BERNSTEIN_AUDIT=1 (or pass --audit to bernstein run) for an HMAC-chained audit log and receipts you can verify offline.

  • Any agent, any model

    40+ CLI adapters: Claude Code, Codex, OpenAI Agents SDK v2, Gemini, Cursor, Aider, GitHub Copilot, Devin Terminal, CLM gateway, AWS Q Developer, and more. Mix cheap local models with cloud models in the same run.

  • Git worktree isolation

    Each coding agent works in its own git worktree (artifact-mode tasks get an isolated plain directory). No merge conflicts. Clean history. Parallel by default.

  • Built-in verification

    Janitor system checks tests, lint, types, and PII before any agent output lands in your codebase.

Why as a forward-deployed-engineering tool

Bernstein is built for the forward-deployed engineering pattern: parachute onto a client repo and stand up an AI engineering crew in minutes. State lives in .sdd/ - no server to provision. Per-agent credential scoping keeps your keys out of the client's environment. The broad adapter spread means the swarm runs on whichever CLI agent the client already trusts (Claude Code, Codex, Gemini CLI, Aider, and more). Every step is an HMAC-signed audit record, replayable for client compliance review.
Install Get Bernstein installed and verify it runs
First run Take Bernstein from "installed" to "first orchestrated task complete"
Configuration bernstein.yaml reference
Adapter Guide Supported agents and how to add your own
API Reference Task server REST API
Integrations what Bernstein bridges to, by the name you call it
Architecture How Bernstein works under the hood
Lifecycle FSM Task and agent state machines with transition tables
What's New Pointer to per-release notes under docs/release-notes/
Release notes One page per tagged version, plus what has landed since the newest tag
Air-gap installation Wheelhouse build, signed verification, --profile airgap, deny-all egress
Governance coverage Which failure class each control prevents, the test that proves it, and what is left uncovered

Created by Alex Chernysh (@chernistry, @alex_chernysh on X).