An AI agent can have a huge context window and still lose the thread.
It may carry an old instruction into a new task. It may retrieve the right file after it has already made the wrong assumption. It may compress away a decision that only becomes important three steps later. It may preserve sensitive or stale material simply because nobody defined when to delete it.
These are not just prompt problems. They are lifecycle problems.
A context window provides capacity. A context policy determines how that capacity is used across a run: where information comes from, how long it remains valid, when it is retrieved, how much space it receives, what survives compaction, and when it disappears.
That distinction matters once an agent works across multiple tools, tasks, or sessions. The prompt is one moment. The lifecycle governs what follows the agent from one decision to the next.
The prompt is only one moment in the lifecycle
Prompt engineering asks an important request-level question: what instructions and information should the model see right now?
Context engineering has to answer a larger run-level question: how does the system keep assembling the right state as the work changes?
A long-running coding agent, for example, may accumulate:
- the operator's original request
- repository instructions and architecture notes
- files inspected during the run
- tool results and test output
- assumptions made by earlier steps
- decisions that changed the plan
- unresolved errors and review feedback
- durable preferences from previous sessions
Putting all of that into every request is not a policy. It is accumulation.
Neither is adding a vector database and calling the problem solved. Retrieval can recover stored information, but storage and retrieval alone do not establish provenance, validity, scope, priority, or deletion authority. The system still needs to decide which material belongs in the working set and why.
This is why I treat context as governed runtime state rather than a long transcript.
Store-and-retrieve is not enough
More retained context can create the appearance of continuity while making the agent less reliable.
An old requirement can outrank a newer correction. A generated note can look as authoritative as a repository file. A broad semantic search can retrieve related material that belongs to another project. A summary can preserve the conclusion while dropping the evidence or unresolved risk behind it.
The opposite strategy fails too. If the system keeps almost nothing, each handoff forces the next agent to reconstruct the job. It repeats searches, reopens settled decisions, and loses constraints that were obvious earlier in the run.
The goal is not maximum memory or minimum context. The goal is relevant continuity.
That requires explicit answers to six decisions:
- Source: Where did this information come from, and how authoritative is it?
- Lifetime: How long and across which scopes should it remain valid?
- Retrieval: What should trigger its return to the working set?
- Budget: How much of the finite context should it receive now?
- Compaction: What must survive when the representation gets smaller?
- Deletion: When must it expire or be removed, and who can authorize that?
These six decisions are my operator model, not a published research taxonomy. Their value is practical: they turn “the agent needs memory” into architecture questions a team can review and test.
The six decisions are the architecture
Consider a hypothetical coding agent working on the same product over several sessions.
Source keeps provenance visible. Operator instructions, repository state, test output, external documentation, and model-generated notes should not enter the system as interchangeable text. If a generated summary conflicts with the current repository, the source label should help the system prefer canonical state and flag the discrepancy.
Without that distinction, authority collapses: a guess, stale note, or secondary source quietly becomes a fact.
Lifetime defines the boundary around validity. A temporary debugging hypothesis may belong to one request. A branch decision may last for one task. A repository constraint may apply across the project. A durable operator preference may survive many sessions.
The failure mode is scope leakage: context that was correct in one task gets reused where it no longer applies.
Retrieval defines when detailed material returns. Stable identifiers and short state summaries can stay available while large files, prior tool output, or source documents are fetched only when the current step needs them. This reduces initial load, but it adds latency and creates a new risk: the agent may fail to look in the right place.
The result is silent omission: the information exists, but the system never retrieves it when the decision is made.
Budget defines what earns working-context space. Current goals, active constraints, supporting evidence, and unresolved decisions usually deserve priority over duplicated logs or already-settled discussion. A larger window can delay this choice; it cannot remove the need for it.
The failure mode is context dilution: the necessary detail is present but buried among lower-value material.
Compaction defines what must survive compression. For operational work, that often includes decisions, active constraints, evidence references, unresolved risks, and the state of verification. Redundant raw output can be removed only after its durable result is represented somewhere trustworthy.
Poor compaction becomes destructive summarization: the shorter record sounds coherent but no longer supports the next decision.
Deletion defines when persistence ends. Stale task state, superseded instructions, expired credentials, sensitive material, and no-longer-authorized data should not remain available by default. Deletion is not housekeeping after the architecture is built. It is one of the architecture's control surfaces.
The failure mode is indefinite exposure: context remains retrievable after its purpose, validity, or authorization has ended.
What the research supports—and what it does not
A July 2026 preprint by Gaurav Dadhich, “Agentic Context Management: Solving Agent Memory and Cost by Treating Them as Lifecycle and Architecture Problems”, argues for treating context management as a lifecycle. It proposes five primitives: architecting, ingesting, scoping, anticipating, and compacting and consolidation.
That framing is useful, but it is not the same as the six-decision policy above. The paper's primitives describe its architecture. Source, Lifetime, Retrieval, Budget, Compaction, and Deletion are my translation of the operating decisions I would want made explicit before trusting a long-running agent.
The paper also shows why naive accumulation can become expensive. Under its model, each turn adds roughly the same amount of material and every subsequent request includes the full prior history. In that full-append case, cumulative input grows proportionally to the square of the number of turns. If a system instead holds model input near a fixed per-turn budget, cumulative input grows linearly with the number of turns.
That is a mathematical comparison, not a universal production-cost law. Bounded windows, selective retrieval, caching, summarization, changing message sizes, and provider pricing can all change the real curve.
The paper describes a commercial reference implementation associated with the author and reports results on conversational-memory benchmarks. Its own limitations note that those benchmarks do not measure production latency, token efficiency, or resistance to context rot. I would not use its scores as proof that lifecycle architecture causes production reliability. The more defensible takeaway is narrower: context has costs and failure modes that storage alone does not govern.
Anthropic's practitioner guidance on effective context engineering for AI agents points in a compatible direction. It treats context as finite, recommends maintaining a high-signal working set, and describes just-in-time retrieval, progressive disclosure, structured notes, and compaction as practical strategies. It also warns that aggressive compaction can remove subtle information that matters later.
An earlier paper, “Lost in the Middle”, offers another useful boundary: in the retrieval and multi-document question-answering tasks it tested, longer contexts did not guarantee that models would use all included information equally well. Relevant information was often used less effectively when it appeared in the middle than near the beginning or end. Capacity is not the same as reliable use.
None of these sources establishes one universal context policy. They support the need to treat selection, retrieval, and compaction as real system design choices. The six-part card is an operator artifact for making those choices explicit and testable.
A Context Policy Card for the next agent you ship
Before giving an agent work that spans tools, tasks, or sessions, complete this card:
Source
What source classes can enter context? Which are canonical, generated, inferred, or unverified? How will conflicts be resolved?
Lifetime
Is each item request-scoped, task-scoped, project-scoped, or durable? What event makes it stale?
Retrieval
What stays resident? What is fetched just in time? Which task state, identifier, or query triggers retrieval, and what happens when retrieval fails?
Budget
Which goals, constraints, evidence, and unresolved decisions have priority? What threshold forces the working set to be reduced?
Compaction
Which facts, decisions, evidence references, risks, and open work must survive? How will the smaller representation be checked against what it replaced?
Deletion
What must expire because it is stale, sensitive, superseded, or no longer authorized? Who or what has authority to delete it, and how is deletion verified?
The card does not guarantee reliability. It gives reviewers a concrete policy to challenge before failure turns into a vague “memory problem.”
Test continuity under pressure
A context policy is useful only if it survives changing conditions.
Do not test it only on a clean task with fresh state and ample context. Change the task midway. Advance the clock until some material becomes stale. Reduce the working-context budget. Deny access to one source. Force a handoff. Compact the history. Revoke permission to retain part of it.
Then ask:
- Did the agent distinguish canonical state from generated notes?
- Did expired context stop influencing the work?
- Did retrieval happen before the dependent decision?
- Did the working set preserve the current goal and constraints?
- Did compaction keep evidence and unresolved risk, not just the conclusion?
- Did deletion remove material from every scope where it was no longer allowed?
The standard is not whether the agent remembers everything. That would be expensive, risky, and often counterproductive.
The standard is whether relevant state survives changes in task, time, permissions, and budget—without preserving everything forever.
That is the difference between giving an agent more context and giving it context architecture.
Sources
- Gaurav Dadhich, “Agentic Context Management: Solving Agent Memory and Cost by Treating Them as Lifecycle and Architecture Problems”, arXiv, July 23, 2026. Full text.
- Anthropic, “Effective context engineering for AI agents”.
- Nelson F. Liu et al., “Lost in the Middle: How Language Models Use Long Contexts”, 2023.