Bo — Planning

Source-code facts,
not source-code vibes.

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.

Why Bo exists

LLMs should not be the parser.

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.

01 · The reality

Agents are re-reading your repo every turn.

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.

02 · The cost

Slower turns. Bigger bills. Hallucinated edges.

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.

03 · The Bo answer

A deterministic map, produced once.

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.

What Bo produces

  • Repo, Module, File records — the structural skeleton
  • Symbol records for classes, interfaces, functions, methods, records, structs, and enums
  • Contract records for signatures, inputs, outputs, async behavior, nullability, and errors
  • Dependency edges at both file and symbol granularity
  • Boundary interaction records for database, network, filesystem, auth, logging, cache, and queue behaviors
  • Effect, complexity, and responsibility profiles
  • Refactor pressure scores and pivot recommendations

All 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.

Try it in two minutes

# 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.

Design principles

  • Deterministic analysis first. LLMs are not the parser.
  • Structured output by default. If an agent needs it, it should be machine-readable.
  • Local-first operation. The CLI runs on a checkout without a hosted service.
  • Graph-native shape. The data model maps cleanly into BogDB nodes and relationships — no impedance mismatch.
  • Boring security posture. No credentials in output, no surprise network calls during local indexing.
  • Clear extension seams. Enterprise search, hosted orchestration, and governed workflows layer on top — without bloating the open CLI.

Where Bo fits in the Beyond Ordinary stack

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.

Give the agents a map

See Bo running against a real codebase — in 30 minutes.

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.

Cookie Compliance

We use cookies to ensure you get the best experience on our website. By continuing to use our site, you accept our use of cookies, privacy policy and terms of service.