Workflow Map

Use this guide when you understand the individual features but want to see how they connect as one system.

This is where BMO’s agent-native architecture becomes concrete: context gathering, prompt assembly, tool selection, permission checks, run events, review, compaction, and recovery are product surfaces that appear in the workflow rather than hidden implementation details.

flowchart TD request["User request"] --> route{"What kind of work is this?"} route --> direct["Direct answer or primitive tools"] route --> staged["Plan first / staged workflow"] route --> multi["Spawn agents / mesh / teams"] route --> background["Recipe, schedule, autopilot, compaction"] direct --> state["Shared session + workspace state"] staged --> state multi --> state background --> state state --> observe["Status bar, debugger, parity tools, logs"] observe --> next["Next prompt or operator action"]

The four common branches

1. Direct tool work

Use this for most coding tasks: inspect files, edit code, run commands, follow LSP references, or fetch a small amount of external context.

Good entry points:

2. Plan before execution

Use staged workflow when you want intent reviewed before edits happen.

flowchart LR ask["Request"] --> plan["Plan phase"] plan --> review["Review in TUI"] review --> revise["/plan to revise"] review --> approve["/approve"] approve --> execute["Execute phase"]

Start here: Staged Workflow.

3. Parallel or remote delegation

Use BMO-native sub-agents for parallel work inside one session. Use mesh when you want to resolve a remote agent by capability instead of hard-coding a URL.

Start here:

4. Background stewardship and long-lived runs

Use recipes, schedules, autopilot, or idle-gated compaction when work needs to happen outside the foreground interactive loop. These are automation-engine entry points, not hidden background magic.

Start here:

Capability maturity on the workflow map

The same request can touch surfaces at different maturity levels. Use this map to decide how much context to read before acting:

Maturity	Workflow posture	Examples
Daily-use	Use directly from the TUI or common guides.	file edits, shell, staged workflow, session modes
Advanced	Use when the workflow map and safety boundaries are clear.	nanites, workstreams, mesh, operating packs, automation, patch proposals
Maintainer-facing	Use for support, audit, or contributor diagnosis.	agent debugger, run observability, runtime signals
Eval-only	Use for measurement and reports, not runtime authority.	shadow evals, session-mode autoselect reports, morphogen evidence
Reference	Consult for exact contracts after choosing a surface.	CLI commands, tools, config, parity payloads

Observability is part of the workflow

BMO’s runtime surfaces are designed so you can see what happened without guessing:

/runtime-signals and the activity row summarize the current live run
the Agent Debugger shows the recorded timeline for a completed run
Run observability gives bounded summary, cueing, and trace-lens reads for the same run family
parity tools expose selected runtime facts over tool, HTTP, and MCP surfaces when supported

If you are diagnosing a run rather than trying to continue it, start with TUI — phases vs runtime activity for the live surface, then move to Agent Debugger or run observability when you need persisted history.