When an AI agent sits down at your codebase, it’s guessing about structure. Bo gives it a deterministic map first — symbols, contracts, dependencies, complexity, refactor pressure — so the model can spend its turns on reasoning instead of parsing.
For engineering leaders who want their coding agents working from facts, not from token-burning guesses.
Apache 2.0. Clone it, run bo index --json --full, see your repo as a graph.
Modern coding agents lose enormous time and money rediscovering code structure from raw text on every turn. Bo replaces that with a deterministic graph — produced once, queried forever.
Without a code-intelligence layer, every coding agent spends tokens reconstructing structure: where a class lives, which files depend on it, how complex it is, what crosses an architectural boundary.
The model burns its context window on derived facts instead of reasoning. Token bills grow, latency stretches, and dependency graphs the agent “recalls” drift from what compilers see — quietly, dangerously.
Bo’s analyzers produce a stable JSON contract: repo, module, file, symbol, contract, dependency, boundary, complexity, refactor pressure. Lands in BogDB, queried by agents. Same answer every time.
Repo, Module, File records — the structural skeletonSymbol records for classes, interfaces, functions, methods, records, structs, and enumsContract records for signatures, inputs, outputs, async behavior, nullability, and errorsAll of it streams out as a stable JSON contract. Useful directly. Much more useful when it lands in BogDB as a queryable code-intelligence graph.
# Inside a checkout
bo init
bo index --json --full > codegraph.json
# Probe a specific file
bo pivot src/ExampleService.cs --json
# Once BogDB persistence is wired in
bo index --store bogdb --db .bo/codegraph.bogdb
Local-first by default — the CLI works on any checkout without a hosted service. Apache 2.0, no credentials in output, no hidden network calls.
Bo is the planning provider behind the Planning boundary in ASE. When ASE needs work decompositions, validation plans, code intelligence, or handoff artifacts, it asks Bo. Bo produces structured ACOP-compatible records and hands them into CLAiR through the /bo/intake endpoint, where they become actionable work items.
On the storage side, Bo's JSON contract is the primary input shape for BogDB's codegen MCP server. bo index --json --full emits exactly the records BogDB expects, so the graph in your database is the same shape your CLI just produced — no schema translation, no lossy conversion.
Bo is replaceable. ASE talks to the Planning boundary, not to Bo specifically. Bring your own planner if you have a better one; ASE and CLAiR don't care, as long as it implements the contract.
Bo is Apache 2.0 and lives at github.com/BeyondOrdinary/bo-cli — clone it and run bo index --json --full on any .NET repo. If you want to see it integrated with ASE and BogDB on a real engagement, the walkthrough is faster than a deck.