Understand: 13s loop: hold the broken change, keep safe work moving, then admit after the same check passes. Inspect: receipts. Prove: recurring episodes. Govern: approval boundary. Measure: enforcement counters.
Open the receipt to verify the exact failure, scoped repair, identical rerun, and admission claim shown above. The receipt view carries digest-bound, high-fidelity live BMO TUI pixels for the same SIGNIN-204 sequence; the landing preview stays focused on the destination system before the failure proof appears.
The landing preview stays short on purpose.
Each episode holds a risky change at the proof rail and admits it only after the identical check passes, with every claim bound to an independent deterministic receipt. The current cut carries three evidenced episodes (SIGNIN-204, CONFIG-MIGRATION-412, and FLAKY-TEST-703), each backed by its own receipt digest; future slots stay locked until their own proof exists.
The approval view shows the governed execution boundary for the same SIGNIN-204 story: both staged options must be enabled, mutation stays locked while the plan is pending, and /approve is the operator action that starts execution. Normal risky-tool confirmations still apply.
The enforcement guardrail is measurable, not just assertable. Every bmo run reports run_summary.enforcement counters: 512 registered tools the guardrail can gate, 90 of 484 visible in coordinator mode (visibility filtering — a smaller menu, not blocked attempts), 0 unclassified denials, and 5,230 bytes of steering it minted and injected. Steering is accounted as a measured cost — never “zero tokens.”
Provenance: SYNTH — deterministic outcome proof from run_summary.enforcement receipts (Amazon Bedrock, Claude Sonnet 4.5), not live capture.
These exact rendered fixtures are maintained as release evidence. The demo package verifies its checked media from a bounded review scope: source HTML, renderer, verifier, proof receipts, live-capture pixels, manifest, and rendered outputs. The public product docs expose the operating boundary they demonstrate, while the demo package owns the capture harness and reproduction contract.
To exercise the same approval behavior on your own code, follow the Quickstart and enable staged workflows as documented under Configuration.
Read the Quickstart guide. It walks you from installation through your first edit in a single short page. The rest of this book is reference material organized by topic.
Contributing to BMO itself? Start with the
CONTRIBUTING.md
first-contribution walkthrough, then return to this book when you need product
or feature reference.
See About This Book for how the guide and reference layers are organized.
One agent core, every surface
The same agent, tools, and approval policy are reachable through bmo (TUI), bmo run (one-shot CLI), bmo service start autopilot|http|mcp (long-lived runtimes), the ACP endpoint (agent-client protocol consumers), and A2A (peer agents) — not five disconnected products. The MCP service exposes read-only tools by default and opt-in bmo_run for mutations.
Share one session state with the agent
Agents read and write the same sessions, file history, message log, and data directory you do. Inspect past runs with bmo session list, bmo session status --session <id>, and TUI /debugger — no opaque external thread.
Approve risky tools before they run
Edits, shell commands matching the blocklist, and writes to sensitive paths (.ssh/, .env, …) wait for confirmation by default. Widen with bmo run --auto-approve-tools or global -y only when you opt in.
Run agents in `local`, `docker`, or `ssh` sandboxes
Route every tool call through options.sandbox.backend in bmo.toml to execute on the host, in a container, or on a remote machine — without changing your prompt. Set [options.sandbox] backend = "docker" and the same bmo run "echo hi" then executes inside a container.
| I want to… | Start here |
|---|---|
| Install BMO and run the first session | Installation and Quickstart |
| Understand how the system is structured | How BMO thinks and acts |
| See how everyday requests branch into workflows | Workflow map |
| Learn practical prompts and delivery patterns | Common Workflows |
| Choose the right feature without reading every page | About This Book and How to discover what BMO can do |
| Inspect the tool surface available to the agent | Tools Reference |
| Understand configuration and operating modes | Configuration and Operating mode parity |
| Work across multiple agents or remote peers | Multi-Agent Workflows, Agent Mesh, and A2A Protocol |
| Review agent-produced code before it lands | Patch Proposals and Quality Gates |
| Run BMO in CI, scripts, or long-lived background mode | Automation & Headless |
| Diagnose a run from durable evidence | Agent Debugger, TUI Runtime Signals, and Run Observability |
