Adaptive Context
Adaptive context chooses which workspace context to include before each turn: git state, recent files, LSP signals, memory, retrieved snippets, and related hints. It uses feedback from completed root runs, such as successful edits, fewer retries, and fewer loops, to keep helpful context prominent and reduce context that did not help. Long sessions stay more focused without requiring you to manually restate what matters.
Under the hood, selection consults the same app-owned trait store updated by the run observer at the end of each root run. Those outcome-weighted scores influence the next turn’s chunk ranking. The scoring model balances recent usefulness against longer-running signal quality, but there is no separate agent-facing API for editing those traits.
What it improves
Section titled “What it improves”- Answer quality in long sessions - The model sees context that has tended to help and less that has led to retries or failed checks.
- Less manual steering - You spend less time saying “ignore that” or “focus on X”; the system learns which context to emphasize.
- Visibility - When enabled, you can see what context was selected or dropped for a run, so you understand why the agent had the context it did.
How it fits with other features
Section titled “How it fits with other features”Adaptive context works on top of the same sources the Prompt Enhancer uses: git status, recent files, LSP diagnostics, Persistent Memory, repo map, flow awareness, and context retriever. It does not replace them; it selects and ranks which of that context to include within a token budget. It complements Context Pruning (which trims redundant tool results from conversation history) by focusing on the enhancer block that is prepended to the user message each turn.
When to use it
Section titled “When to use it”Adaptive context is enabled by default. It helps most during long sessions where the agent might otherwise get distracted by irrelevant context or miss important context. When disabled, BMO still assembles prompt context, but it does not apply outcome-weighted selection.
Scope: Feedback is collected for the main root run in each session. Child runs, such as nested agents or tool-driven runs, do not contribute selection feedback or reward updates.
- Can the agent read or set the outcome-weighted scores? No. Traits are not exposed as tools or HTTP/MCP APIs; they are loaded inside the enhancer selection path when the feature is enabled, and updated by the run observer after each root run. You still see which context was selected or dropped via prompt trace / debugger when those surfaces are enabled.
- Is this a separate database? No. The default store is in-memory in the BMO process (same singleton the app uses for the observer). It is not part of the shared SQLite message store and is not user-editable as rows.