Long-Horizon Development

Long-horizon development means the work will outlive one prompt, one context window, or one agent run. Use BMO as an operating system for the change: durable identity for the work, explicit permission boundaries, scoped context, visible coordination, and evidence that survives interruption.

This guide is for large repositories, migration programs, cross-cutting refactors, release hardening, and multi-session delivery. For simpler tasks, start with Common Workflows and only add the surfaces below when the work needs them.

The recommended posture

Start conservative and add autonomy only after the feedback loop is visible.

Need	Recommended BMO surface
Review intent before edits	Staged Workflow
Use different models for planning and execution	Phase model routing
Keep long sessions alive under context pressure	Session Compaction
Preserve project conventions across sessions	Persistent Memory
Coordinate parallel writers	Workspace claims
Package repeatable work	Workstreams and factory patterns
Run bounded side investigations	Nanites or Multi-Agent Workflows
Audit outputs after drafting	Quality Gates and Shadow Evals
Understand workspace pressure	Workspace intelligence and Workspace observer
Inspect a run after the fact	Agent Debugger, Run Observability, and Run Ledger

Baseline configuration

Use a project-local bmo.toml when the posture should travel with the repository. Use user config for personal defaults and provider secrets. Keep the project config focused on workflow shape rather than credentials.

[options.staged_workflow]
enabled = true
require_approval_before_execute = true

[options.phase_model]
# planning_model = "provider/fast-planner-model"
# execution_model = "provider/strong-editor-model"

[options]
agent_max_depth = 1
agent_max_threads = 4
nanite_max_threads = 2
enable_auto_summarize = true

[options.workspace_observer]
enabled = true
include_in_prompt = true

[options.workspace_markers]
enabled = true

[options.workspace_trail]
enabled = true

[options.workspace_claims]
enabled = true

[options.persistent_memory]
enabled = true
backend = "sqlite"

[options.persistent_memory.embeddings]
enabled = true
read_projection = "default"
write_projections = ["default"]
fallback_to_lexical = true

[[options.persistent_memory.embeddings.projections]]
name = "default"
provider = "local"
model = "bmo-local"
indexed_scopes = ["project", "user"]
top_k = 10

[options.quality_gates]
# Start advisory. Arm send-back only after the judge model and rubric are tuned.
enabled = true

Keep tool approval explicit while a repository is still being mapped. Avoid blanket auto-approval for large changes unless the run is confined to a trusted recipe, a bounded CI lane, or a disposable environment.

Work in durable units

Do not let a large program exist only as a chat transcript. Give every serious piece of work a durable row or artifact:

Unit	Use it for
Workstream	Epic, PR, migration slice, review campaign, benchmark campaign
Recipe	Repeatable process that should run more than once
Staged plan	Risky edit sequence that requires operator approval
Finding	Review defect or residual risk with lifecycle state
Verification row	Test, lint, eval, benchmark, or manual proof attached to the work
Artifact	Generated report, patch proposal, migration note, or release packet

A good long-horizon prompt asks BMO to bind the work before it starts:

Create or select a workstream for this migration.
Use staged workflow for the implementation plan.
Take hard workspace claims before editing shared files.
Attach test output, review findings, and residual work to the workstream before final status.

The point is not ceremony. It is resumability: a later operator should be able to ask what the workstream is, what was attempted, what failed, what changed, what was reviewed, and what remains.

Slice by ownership, not by transcript

Large-scale software work usually fails when the slice is too broad or the handoff is too vague. Slice the work by ownership boundary and validation path:

Slice type	Good BMO pattern
One package or subsystem	One staged plan, one workstream, focused tests
Cross-cutting mechanical edit	Recipe or patch proposal, small batches, verification after each batch
Architecture investigation	Read-only session mode, workspace snapshot, artifact-backed recommendation
Risky migration	Plan first, claims before writes, review gate before merge
Repeated review	Prompt or recipe, quality gate, finding lifecycle
Background cleanup	Nanite or automation rule with a clear cap and status surface

For parallel work, prefer many narrow lanes over one broad autonomous request. Spawn child agents only when the file ownership is separable or claims can make overlap visible. Use nanites for bounded background summarization, inspection, and follow-up discovery; keep primary implementation in an operator-visible foreground lane.

Keep context intentional

Context is a budget and a trust boundary. Long sessions should keep three kinds of context separate:

Context	What belongs there
Prompt context	The current task, relevant files, constraints, and recent decisions
Persistent memory	Durable conventions and decisions that should affect future sessions
Artifacts	Plans, reports, findings, generated packets, and verification evidence

Use Session Compaction for foreground context pressure. Use Persistent Memory for stable project knowledge. Use workstream artifacts when the information is important but too detailed to inject into every prompt.

Before a major turn, inspect:

/workspace-snapshot
/context
/persistent-memory
bmo session status

If the task is drifting, ask BMO to restate the active workstream, current claims, modified paths, planned next edit, and validation target before it continues.

Coordinate shared workspaces

When humans, agents, and tools share a checkout, make coordination visible before mutation:

1. Use /workspace-snapshot to inspect current workspace posture.
2. Use /workspace-claims or workspace_claim before parallel edits.
3. Prefer hard claims for mutation-heavy paths and soft claims for advisory intent.
4. Keep shell commands and external editors in mind; they are outside BMO’s mutation guard.
5. Release or yield claims when a lane stops owning the path.

Workspace claims reduce accidental overlap, but they are not a replacement for review. Treat them as coordination signals that make the live checkout easier to reason about.

Use operator surfaces deliberately

Long-horizon work should have a small set of surfaces the operator checks repeatedly:

Surface	When to open it
/staged-workflow	A plan is pending, stale, or needs revision
/workstream-status	You need the durable status of a delivery cell
/workspace-snapshot	Before a major turn or after concurrent activity
/cartography	You need heat, markers, trail, or signal-zone context
/workspace-claims	Before assigning or accepting parallel writers
/agent-family	Child agents are running or recently completed
/team	Team or CSV fan-out lanes are active
/debugger	A run behaved unexpectedly or needs timeline review
/quality-gates	Output judging, send-back posture, or rubric health matters
/memory	You need to inspect, update, or delete durable memory
bmo session status	You need session budget, compaction, and continuity state

The habit is simple: inspect before delegating, inspect before applying, inspect after verification. Do not rely on hidden model memory when an explicit surface exists.

Review and verification cadence

For large changes, review should be layered:

1. Plan review — inspect the staged plan before writes.
2. Local verification — run the smallest relevant test or lint after each meaningful slice.
3. Diff review — review changed behavior, not only syntax.
4. Quality gate — use rubric-based judging for plans, prompts, proposals, or final writeups.
5. Shadow eval or benchmark — run when the change affects agent behavior, prompts, routing, or performance.
6. Handoff — record residual risks, skipped checks, and next actions on the workstream or artifact.

Ask for findings first when reviewing:

Review the current diff for user-visible regressions and operator trust risks.
List confirmed findings first with file path, evidence, impact, and fix direction.
Separate residual risks from defects.
Attach the review result to the active workstream.

Autonomy levels

Choose autonomy by blast radius:

Level	Use when	Posture
Chat	Reading, explanation, small edits	Operator stays in the loop
Staged workflow	Multi-file edits or uncertain design	Plan approval before mutation
Child agents	Independent lanes with separable paths	Claims and final parent review
Nanites	Background inspection or summarization	Bounded queue and visible status
Automation	Recurring or event-driven work	Explicit schedule, cap, and status
Mesh or remote agents	External capability is needed	Treat output as proposal unless trusted

The safest long-horizon setup is not “maximum autonomy.” It is the highest autonomy level that still leaves ownership, evidence, and rollback posture obvious to the operator.

A practical operating loop

Use this loop for large migrations and multi-session delivery:

1. Orient — /workspace-snapshot, relevant docs, search, and existing workstream state.
2. Bind — create or select a workstream and declare the slice.
3. Plan — staged workflow, with validation targets and owned paths.
4. Claim — acquire workspace claims for mutation-heavy areas.
5. Execute — edit one slice, keep tool approval scoped.
6. Verify — run the smallest meaningful validation, then broaden.
7. Review — findings first, attach results to the workstream.
8. Record — store durable decisions in memory; store detailed evidence as artifacts.
9. Resume or close — either package the next slice or mark the workstream status with residual risks.

Related

• Workflow Map
• Workstreams and Factory Patterns
• Staged Workflow
• Multi-Agent Workflows
• Workspace intelligence
• Session Compaction
• Quality Gates