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.

Workflow

flowchart LR
    sources["Workspace sources\nGit, recent files, LSP,\nmemory, repo map, retrieval"] --> rank["Adaptive selector\nRank chunks within budget"]
    traits["Outcome-weighted trait store\nRecent usefulness and longer-running signal"] --> rank
    rank --> block["User-message context block\nSelected chunks and dropped-context trace"]
    block --> turn["Model turn and tool work"]
    turn --> outcome["Completed root-run outcome\nEdits, checks, retries, loops"]
    outcome --> observe["Run observer updates scores"]
    observe --> traits
    turn -. "Child/tool runs do not update traits" .-> block

Read the loop left to right: BMO gathers the same prompt-enhancer inputs every turn, ranks them against the current budget, and exposes the selected/dropped decision through prompt trace surfaces. After the root run completes, the observer updates the in-process scores used by the next selection pass.

How selection works

Each turn, adaptive context decides which enhancer context chunks to include under a token budget. The mechanics are deterministic given the current traits:

• Candidate chunks. Candidates are built from the same enhancer sources the Prompt Enhancer draws on: git status, recent files, LSP diagnostics, memories, repo map, retrieved repo/MCP snippets, and the dev-timeline flow. Each candidate gets a stable ID and a per-source relevance base so scores are comparable across turns.
• Scoring blend. Every chunk is scored by a weighted blend: embedding query_fit (weight ~0.45) against the current request, an evaporating pheromone trail that decays exponentially by recency, the relevance base, a success EMA, a redundancy penalty, and a failure EMA. Plasticity coupling then scales scores by the active expression profile (explore/edit x discovery/local), so selection leans toward the kind of work underway.
• Small-first token envelope. The budget is percent-derived (context_budget_percent ~0.16, headroom_percent ~0.08) but capped by an absolute small_first_max_input_tokens (default 12000). The envelope state is small by default and only becomes expanded when a run passes an explicit expansion reason — an escape hatch rather than the norm.
• Persisted traits. Outcome-weighted traits (pheromone, success/failure EMA, recency) persist per chunk in an app-owned store — in-memory by default, with a SQLite-backed store available. Traits are updated by the run observer at the end of each root run only; child and tool runs do not contribute.
• Decision metadata. The selection emits rich metadata — selected, dropped, and capped counts, token_estimate, envelope state, and the query_fit source — into prompt traces, so each decision is auditable.

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

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.

What you see in BMO

describe_context exposes a context_envelope object so you can inspect the selection decision directly: its state (small or expanded), the expansion_reason when expanded, the effective and percent-derived budget, the small-first cap, the selected/dropped/capped counts, and the token estimate.

Surface	Purpose
describe_context / Context hub	Read the current context_envelope — state, budget, caps, and selection counts
Prompt trace / debugger	Inspect per-chunk decisions: which chunks were selected, dropped, or capped, and why

How it differs

These features are easy to conflate because they share the word “adaptive” or all touch context size. They are distinct subsystems:

• Adaptive context (this page) chooses which context chunks to include before each turn, learning from run outcomes.
• Adaptive orchestration (/features/adaptive-orchestration/) reshapes how the session is coordinated — topology, conflict strategy, model gene, and similar levers. It is a different subsystem that happens to share the word “adaptive”.
• Prompt-budget enforcement / context pruning (/features/context-pruning/) is a reactive, last-mile path that trims tools, attachments, and the oldest message rounds to fit the provider limit when a turn would still overflow. Adaptive context is proactive selection; budget enforcement is reactive trimming.

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.

FAQ

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