Bernstein Multi Agent Orchestration
About
Multi-agent orchestration MCP server. Start parallel agent runs, manage task queues, track costs, and verify quality gates across 20+ CLI coding agents.
Details
- Author
- chernistry
- Downloads
- 300
- Categories
- Developer Tools, Other, AI
Jump to
- Declarative YAML orchestration for complex dev workflows
- Parallel execution of multiple AI agents across providers
- Automated output verification with a dedicated janitor agent
- Vendor-agnostic and portable prompts and workflows
- Continuous self-improvement through automated feedback loops
Setting up with Highlight
This MCP is not yet compatible with Highlight’s one-click setup. However, you can still use it with Highlight by following these steps:
- Download and install Highlight from highlightai.com/download
- Navigate to the plugins tab and select "Add Custom Plugin"
-
Configure the plugin with the settings below
Plugin Name
Bernstein Multi Agent OrchestrationCommand (node, npx, python, etc.)Please refer to the README for specific instructions on how to obtain API keys or other required environment variables.
- Enable "Start Automatically" if you want the plugin to start when Highlight launches
From the repository
Define a development goal and optional agent configuration in a YAML file, then run Bernstein to orchestrate multiple AI agents (e.g., Claude Code, Codex CLI, Gemini CLI) across providers. The server handles task decomposition, parallel execution, and automated verification automatically.
Claude Desktop / Cursor
Paste into your MCP client config file to install this server.
{
"mcpServers": {
"bernstein multi agent orchestration": {
"bernstein": {
"command": "bernstein",
"args": [
"mcp"
]
}
}
}
}McpServers
{
"bernstein": {
"command": "bernstein",
"args": [
"mcp"
]
}
}"To achieve great things, two things are needed: a plan and not quite enough time."-attributed toLeonard Bernstein
deterministic multi-agent CLI orchestration
website·docs·install·first run·glossary·limitations·name policy·sponsor
简体中文·繁體中文·日本語·한국어·हिन्दी·বাংলা
Status: beta.Solo-maintained, under active development. The version number counts releases, not maturity - minor versions may change interfaces. Pin the version for anything you depend on; regressions get fixed fast,file them.
Bernstein is a deterministic orchestrator for CLI coding agents (Claude Code, Codex, Gemini CLI, and 40+ more). It runs them in parallel, gates what they produce, and records enough of the run that you can check it afterwards. Air-gap install profile included. Apache-2.0.
Four things set it apart; everything after is detail.
- No LLM in the coordination loop.Scheduling is plain Python, so a run is reproducible end to end. Replay yesterday's plan and get yesterday's task graph.
- Checkable after the fact.The replay journal records every run, and the always-on lineage spine records every lineage-bearing step; the opt-in HMAC-chained audit log (BERNSTEIN_AUDIT=1) adds receipts you verify offline. Non-determinism surfaces as a hash mismatch at the exact step, not a flaky re-run. Non-code deliverables get the same treatment: a task can declare an artifact contract (report, dataset, action log, ops result) and completes on a signed lineage receipt rather than a git commit.
- Isolated by construction.Each coding task gets its own git worktree behind merge gates; artifact-mode tasks get a working directory under.sdd/workspaces/. Agents share no mutable workspace by default; the only shared state is the task backlog, which is claimed atomically. Stricter filesystem enforcement is opt-in, from thesandbox backends. Disable worktrees and every task runs in the shared checkout.
- Broad and local.40+ CLI agent adapters plus a generic--promptwrapper, file-based state, no SaaS hop, no third-party data plane.
The full list is on thecapabilities page; thefeature matrixis the exhaustive index.
uv tool install bernstein # or: pipx install bernstein bernstein init bernstein doctor # checks a CLI agent is installed and authenticated bernstein -g "fix the failing test in tests/test_foo.py"
pipx, pip, brew, dnf, npm, and Docker are covered in theinstall guide; the air-gapped wheelhouse has its ownair-gap guide.
The recording above is a real run, and it ships with its own proof. The cast, the signed run receipt derived from that run's journal, and the public key that pins it all live indocs/assets/demo-run/. Verify the run you just watched, offline:
bernstein verify receipt docs/assets/demo-run/run-receipt.json \ --public-key docs/assets/demo-run/run-receipt.pub.pem
CI re-verifies the committed receipt on every push to main — and proves a tampered copy fails — so the published evidence cannot rot into a decorative file.scripts/record_demo.shregenerates the recording, receipt, and key from a fresh real run; nothing inside the terminal is synthesised.
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. Inbernstein live, the left and right columns scroll independently as whole panes, so widgets below the fold remain reachable in shorter terminals.
Determinism here is something you check, not something you take on faith. Run once with audit enabled, then verify what was recorded:
BERNSTEIN_AUDIT=1 bernstein -g "fix the failing test in tests/test_foo.py" bernstein replay list # run ids recorded on disk bernstein replay latest --verify # recompute the journal head, name the first divergent step bernstein lineage verify <run_id> # recompute the always-on lineage spine bernstein audit verify # HMAC chain + Merkle seal (written because audit was enabled) bernstein audit diagnose <run_id> --signal gate --sign-key KEY # name the exact step a failure entered the run, as a signed receipt bernstein verify run <run_id> --signing-key-path key.pem # sign one portable run receipt bernstein verify receipt .sdd/runs/<run_id>/run-receipt.json # verify it offline: file only
The journal is written on every run; the lineage spine is always on and gains an entry for each lineage-bearing step, so a short run can finish with a valid, empty spine.bernstein audit verifyonly has a chain to check when the run was started withBERNSTEIN_AUDIT=1, a compliance preset, orbernstein run --audit. The--auditflag belongs tobernstein run; on thebernstein -gform above, set the environment variable.
One run receipt binds the journal head, the lineage-spine head when the run wrote spine entries, and, opt-in, an audit-chain range, under a single Ed25519-signed subject with the public key embedded. A reviewer holding that file and the operator's public key can confirm the embedded actions and chains were not changed: no HMAC key, no live.sdd/, and exit2naming the first divergent step on tamper. That receipt identifies the journal state it embeds; proving that state is the complete finished journal additionally requires an independent head/count seal. With the file alone and no--public-keypin, the check is integrity-only — it proves the receipt is internally consistent, not who signed it, and the verdict says so. Details in[deterministic replay.
…
Sign in to leave a review
Use Google, GitHub, or an email account so ratings stay tied to real people.
No reviews posted yet.
