Context packs

Why a pack, and not just “the repo”

Retrieval finds candidate code. A knowledge graph tells you how that code relates. But an agent does not consume search results — it consumes a single, bounded block of context that has to fit a model window and earn the model's trust. The context pack is that block. It is the difference between handing a model a library card and handing it the exact pages, in order, with the relevant rules stapled to the front.

Every pack is built for one task — a ticket, a chat question, an agent dispatch — and only for that task. Two unrelated jobs never share a pack, so the model never wades through context that belongs to someone else's work.

What a pack contains

A pack is assembled from multiple sources in a single pass, each section drawn from the part of your project that knows the most about the task:

• Code chunks — the most relevant functions, classes, and files, retrieved by hybrid semantic + keyword + entity search and ordered by relevance.
• Three-tier memory — org-wide decisions, project-level rules (decisions, restrictions, preferences, patterns, incidents), and any live session notes, so the model honors what your team already decided.
• Tickets — linked issues from the board or synced from Jira / Linear, so the task carries its own intent.
• Documents — specs, phase notes, meeting notes, Figma frames, and Google Docs, fanned in when the task needs more than code.
• Coding guidelines — the project's agent coding rules, pulled so generated code matches how your team builds.
• Schema-of-record — the real database schema, so the model reasons over the tables that actually exist instead of inventing them.
• Similar prior features — past work that resembles the current task, so the model can follow established patterns rather than guessing a new one.

Each section can be redacted per-section with a severity tag, so sensitive material is stripped before the pack ever leaves your perimeter for an external model.

Confidence and freshness scoring

A pack is not just assembled — it is scored, so the agent (and the human watching it) can decide whether to trust it before acting:

• Confidence — a per-section completeness score, rolled up to the pack, that answers “how much of what this task needs did we actually find?”
• Freshness — a staleness-aware rerank that surfaces how old each piece of context is, so a model never silently reasons over code or a decision that changed weeks ago.

These scores are surfaced on the pack itself and on every section. The chat surface and agent timeline use the same signals, so the confidence you see in a chat answer is the same confidence the pack carried.

Token-budget pruning

Real codebases are far larger than any model's context window, and a pack that overflows the window gets silently truncated by the model — usually dropping exactly the part you needed. ContextBrain refuses to let that happen. A token-budget managerprunes each pack to fit the target model's window, dropping the lowest-value sections first while preserving the highest-confidence, freshest context. No silent truncation, no blown windows — the model sees a coherent pack that fits.

The hash-signed manifest

Every pack carries a hash-signed manifest — a content hash of exactly what went into it. When the pack is dispatched to an agent session, that hash is recorded on the session and verified before dispatch. If a pack were altered between assembly and dispatch, the hashes would not match and the dispatch is rejected.

This is what makes context provable. You can show, after the fact, the exact bundle a given agent run saw — by hash. For regulated work and client contracts, “here is what the AI was given” stops being a guess and becomes an audit record.

Caching and task fingerprinting

Assembling a pack is real work — retrieval, scoring, pruning. ContextBrain does not repeat it needlessly. Each pack is cached and keyed by a task fingerprint —(project, task, depth, agent_type) — with a TTL and automatic invalidation when project activity (a commit, a promoted memory) makes the cached pack stale.

The practical payoff: two developers asking similar questions, or two agents dispatched against the same kind of task, share a cached pack — faster and cheaper, without ever serving stale context, because re-indexing a repo invalidates the affected packs.

The pack viewer

Packs are not a black box. Every assembled pack has a viewer surface with section-by-section drill-down— you can open a pack, expand each section, and see precisely which code chunks, which memories, which tickets and docs the AI received, along with the confidence and freshness on each. Historical packs are searchable too, over both semantic and lexical modes, so you can find “what context did we give the agent that touched billing last month?”

Where packs come from and go

Packs are built from the knowledge graph and the retrieval engine, and they are consumed everywhere an AI touches your code: the grounded chat surface, every agent session, and any external client that calls the MCP get_context_pack tool. The pack is the contract between “what your project knows” and “what the model sees” — scored, bounded, and signed.