Context Assembly Is a Governance Decision
Everyone knows the phenomenon: the fuller the context window, the less reliable the model. Hallucinations increase, the carefully defined role frays - at some point the sober project assistant starts acting like Captain Jack Sparrow. The response is always the same: save tokens. Compress, summarize, feed in only what’s relevant.
All correct. But the discussion optimizes throughout for capacity and cost - and misses the question that actually comes first: what is flowing here, and who decided it was allowed to flow?
An LLM knows exactly as much about you, your project, and your conversation as what sits in the context window. Nothing more. Everything ends up there: system prompt, conversation history, meeting minutes, wiki excerpt, search result. The longer the collaboration, the fuller the window. As soon as private or professional information is involved, the context window is the place where all this data converges - and therefore the place where it is decided which information reaches which agent.
Summarization is data disclosure with a fuzzy filter
The standard answer to a full window is summarization. A second LLM call extracts “everything on topic XY.” Technically that works. But let’s look closely.
First: the complete transcript flows through the extraction call. Including the salary discussion, the customer names, the accidentally pasted password. The extractor itself has seen everything - before the filter kicks in. Anyone using an external frontier provider for this has already disclosed the data.
Second: a probabilistic system decides what’s “relevant.” The summary inherits none of the original’s permissions. It is a new artifact without access controls, and it lands in the context of an agent that talks to the outside world through tools.
Summarization solves the capacity problem. In doing so it creates a governance problem: at every summarization point, information leaves the control of its source system - and no one decided whether it was allowed to.
Memories need a policy schema, not a dump
The way out isn’t better prompts for the extractor. It’s storing memories from the start so that the disclosure decision can be made deterministically - before an LLM ever enters the picture.
Every stored piece of information needs four attributes:
- Grouping - which project, client, or subject area does it belong to?
- Capture date - information ages. The architecture state from eight months ago isn’t a memory, it’s a trap.
- Context - “The customer wants feature X” from a brainstorm is something different from the same sentence in a signed proposal.
- Authorization - who is allowed to learn and further process this information? The attribute missing from almost every memory setup.
With these attributes, context assembly changes fundamentally. First, a deterministic layer filters by authorization, client, and channel. Only after that is an LLM allowed to summarize within that subset. The LLM decides what’s important. It never decides what’s allowed to flow.
That’s the same logic that’s long been standard for tool access. On the information level, this discipline is missing almost everywhere.
The extractor is itself the problem
An objection comes to mind: if the deterministic layer pre-filters, can’t we then simply trust the LLM summarization step? No. LLMs fail plausibly, not obviously.
An extractor that lets PII through doesn’t produce an error. It produces a cleanly worded summary that happens to contain a customer number. What the first model gets plausibly wrong, the second often plausibly waves through.
That’s why we need deterministic layers around the LLM step:
- Before extraction: only cleared documents make it into the call at all.
- After extraction: rule-based checks for structured PII (IBANs, emails, customer numbers, secrets).
- At egress: a policy check before content leaves the system. The last authority is a rule, not a model.
The remaining gap - unstructured sensitive information without a clear pattern - stays an honest residual, covered by spot-check human review, not by yet another model. Anyone claiming it’s closed by a second LLM is selling probability as a guarantee.
Not a capacity problem
Context window management is considered a solved problem: summarization, RAG, clean chunking. That’s true as long as you treat it as a capacity problem.
It stops being true the moment you treat it as what it architecturally is: the point where information passes from systems with access control into a system without access control. Every summary is a new artifact without the original’s permissions. Every extraction call is a disclosure.
Anyone who builds memories as a tagged, policy-filtered store instead of a dump gets that control back - with four attributes and a deterministic layer, not with better prompts.
The context window isn’t storage. It’s an egress point.