Overview
BMO is an open-source agent-native coding system for the terminal. It keeps parallel work coherent through visible ownership, evidence, review, recovery, and signal-shaped coordination while giving you one place to inspect code, edit files, run commands, coordinate sub-agents, expose protocol surfaces, and operate background workflows against a shared workspace.
Agent-native architecture means BMO is built around agents as first-class operators, not as a chat box bolted onto a conventional CLI. The agent can inspect workspace state, choose tools, coordinate workflows, preserve context, and expose what it is doing through the TUI, CLI, and server surfaces. The goal is not unchecked autonomy; it is visible, interruptible, recoverable intelligent work.
What makes BMO different
Section titled “What makes BMO different”- Shared workspace instead of isolated chat. You and the agent operate against the same session state, message history, tools, and data directory.
- Explicit actions instead of hidden magic. File reads, edits, shell execution, parity reads, remote delegation, and scheduled jobs happen through named capabilities.
- Composable workflows. Staged workflow, mesh, multi-agent runs, autopilot, recipes, canonical automation jobs/rules, compaction, and observability build on those same surfaces.
- Coherence under parallelism. Workstreams, claims, findings, verification, and signal deposits make parallel agent work inspectable instead of measuring success by agent count alone.
- Multiple operator surfaces. The TUI, CLI, HTTP server, MCP server, and A2A integration describe the same product from different entry points.
Why teams evaluate BMO
Section titled “Why teams evaluate BMO”| Evaluation question | BMO’s answer |
|---|---|
| What guarantees that an agent’s edits won’t escape my review? | Edits and risky tools are approval-gated by default; --auto-approve, --auto-approve-tools, and bmo -y widen the policy explicitly when you opt in. The policy applies across every surface (TUI, bmo run, bmo autopilot, bmo serve-mcp). |
| Can I run the agent against my real repository, not just a chat sandbox? | Pick a sandbox backend in bmo.toml under options.sandbox.backend: local for host execution, docker for container isolation, or ssh for a remote build host — same prompt, same tools, different blast radius. |
| What stops two parallel agents from clobbering the same files? | Workspace claims (hard or soft path locks) and mesh routing record who owns which paths; the multiplayer coordination dashboard surfaces conflicts before they land. |
| How do I plug BMO into the editor and infrastructure I already use? | One agent core, six entry points: bmo (TUI), bmo run (one-shot CLI), bmo autopilot (headless with optional HTTP), bmo up (long-lived server), bmo serve-mcp (MCP for editors), plus ACP and A2A endpoints. |
| Can I audit what the agent did after the fact? | Every run is durable: sessions, tool calls, approvals, and evidence persist to the data dir; bmo session show <id> and the debugger views replay any past run. |
Choose the right starting point
Section titled “Choose the right starting point”| I want to… | Go to |
|---|---|
| Install and run BMO | Installation |
| Get to a real first run quickly | Quickstart |
| Understand the mental model before going deep | How BMO thinks and acts |
| See how prompts turn into tools and workflows | Workflow map |
| Discover capabilities from inside the product | How to discover what BMO can do |
| Learn practical day-to-day prompting patterns | Common Workflows |
| Understand tool and config surfaces | Tools Reference and Configuration |
| Run BMO without the TUI | Automation & Headless |
| Coordinate multiple or remote agents | Multi-Agent Workflows and Agent Mesh |
Core capabilities
Section titled “Core capabilities”- Interactive TUI with streaming runs, sidebars, slash commands, debugger, and session management.
- Built-in tools for file access, patching, shell commands, PTY sessions, LSP, memory, web fetch, parity reads, and more.
- Workflow layers such as staged workflow, reflection loop, auto-checkpoint, recipes, schedules, and compaction.
- Multiple providers and protocols including Anthropic, OpenAI, Gemini, Xiaomi MiMo, local/OpenAI-compatible backends, MCP, LSP, A2A, and HTTP serving.