Context, memory, and the attention budget

Consider a common collaboration failure. An agent retrieves a design document from three weeks ago. It is highly relevant to the current request and far more detailed than the later sentence saying that the proposal was rejected. Retrieval appears to have worked; the next decision still returns to an obsolete direction.

A larger context window does little to solve this failure. The system already has both pieces of information. What it lacks is their time, scope, and authority, plus an ordering rule for which one may influence the current action.

Language models always operate on a finite working set. Instructions, memories, documents, examples, and intermediate results consume tokens after admission, but they also compete for influence. Context engineering begins as a selection problem: admit enough evidence while preventing stale, out-of-scope, or low-authority material from changing the decision.

That work becomes clearer once Archive, Memory, and Context are separated.

Archive preserves; Memory interprets; Context activates

An Archive preserves what happened. It may contain complete conversations, raw documents, tool outputs, versions, and event history. Its job is fidelity and traceability, not immediate usefulness.

Memory preserves a durable interpretation that may matter again. A preference, constraint, decision, failed approach, unresolved question, or project state can become Memory after it has been selected and given scope.

Context is the working set assembled for the current decision. It includes only what the Agent needs now: instructions, current task state, relevant evidence, selected memories, available capabilities, and recent interaction.

The three layers can be connected without being collapsed:

Archive → candidate Memory → selected Context → decision → new evidence

If the Archive is inserted directly into every Context, the product has avoided the selection problem rather than solved it.

A transcript must be distilled

Conversation contains valuable information, but it also contains exploration, corrections, obsolete assumptions, temporary preferences, and ideas that were never accepted.

Promoting an entire transcript to Memory creates several failures:

• an early hypothesis competes with the final decision;
• a one-time instruction becomes a permanent preference;
• repeated explanations occupy space without adding evidence;
• sensitive or irrelevant details travel into unrelated tasks;
• the Agent cannot tell what is authoritative.

Useful Memory is usually a compressed statement with provenance and scope:

• what was decided;
• why it matters;
• where it applies;
• which evidence supports it;
• what would make it stale;
• whether the user can revise it.

The transcript remains available as evidence. Memory is the maintained interpretation, not a second copy of the history.

The Context builder determines the current view

Context should not be whatever happens to fit before the token limit. It is a view assembled around a specific task.

That view may contain several layers:

1. Stable instructions — product rules, permissions, and collaboration boundaries.
2. Current objective — the outcome being pursued and the definition of completion.
3. Live task state — decisions, open questions, completed work, and blockers.
4. Relevant project evidence — code, documents, data, and artifacts needed for this step.
5. Selected Memory — durable information whose scope matches the current situation.
6. Recent interaction — the local conversational turns needed for continuity.

These layers have different authority and update frequency. A recent sentence should not silently override a durable permission boundary. An old Memory should not override an explicit instruction in the current task. A retrieved document should not become a user preference merely because it appeared in Context.

The Context builder needs ordering and conflict rules, not only retrieval.

Retrieval also needs a test of utility

Retrieval systems are often evaluated by whether they can find related material. But semantic similarity is only one part of usefulness.

A piece of information can be relevant and still be harmful because it is:

• stale;
• outside the current scope;
• less authoritative than another source;
• duplicated many times;
• too detailed for the current decision;
• likely to anchor the model on an old approach.

The useful question is not “Can we retrieve this?” It is:

Will adding this information improve the next decision enough to justify the attention it consumes?

That requires ranking by more than similarity. Freshness, authority, task fit, novelty, confidence, and cost all matter.

Progressive disclosure protects attention

Many tools, skills, documents, and memories contain useful detail that is not needed at the beginning of a task.

Loading all of it immediately increases prompt size and creates premature commitments. A better pattern is progressive disclosure:

• expose compact metadata first;
• let the Agent identify which source or capability is relevant;
• load the precise detail only when the plan reaches it;
• retain a short reference instead of copying the full material forward.

This is useful for tool discovery, project documentation, large datasets, and long-lived Memory alike.

Progressive disclosure is not merely a token optimization. It preserves the Agent’s ability to form a plan before being anchored by implementation detail.

Compression preserves decisions, evidence, and open questions

Long tasks eventually exceed any practical Context window. Compression is unavoidable.

A weak summary preserves the topic of the conversation. A useful task summary preserves the state required to continue:

• the objective and acceptance criteria;
• decisions already made and their reasons;
• evidence that has been verified;
• failed paths that should not be repeated;
• unresolved questions and blockers;
• changed files or produced Artifacts;
• the next safe action;
• explicit boundaries and things not to do.

This is closer to a handoff document than a shorter transcript.

Good compression is asymmetric. It can discard conversational phrasing while preserving one small constraint that changes the correct implementation. Token count alone cannot tell us whether the important state survived.

Memory needs scope and revision

Durable information becomes dangerous when its scope is invisible.

“Prefer a minimal interface” may apply to one website, one product family, or every interface the user builds. “Do not run the browser” may be a permanent repository rule or a temporary validation boundary for one task. Without scope, retrieval turns contextual decisions into universal instructions.

A Memory system should therefore preserve at least:

• subject and scope;
• source and time;
• confidence or confirmation status;
• supersession relationships;
• correction and deletion behavior.

When a newer decision conflicts with an older one, the system should revise the maintained Memory rather than retrieve both indefinitely and ask the model to resolve history on every turn.

Evaluate Context through decision quality

Retrieval precision and recall are useful diagnostics, but they do not measure the product outcome.

A Context system should also be evaluated by questions such as:

• Does the Agent make better decisions with the selected Context?
• How often does stale information change the result incorrectly?
• Does the Agent repeat work that a handoff should have preserved?
• Can it identify the authority behind an important constraint?
• How much irrelevant material is carried between steps?
• Does compression preserve recovery after interruption?
• What latency and cost are added by retrieval and composition?

The best Context is not the largest set of relevant facts. It is the smallest working set that preserves the right decision.

Attention is a system budget

An archive can remain complete, and memory can be maintained over time. Context has a narrower responsibility: the decision in front of the system now. Once the three are separated, every item admitted to the working set should answer a few questions: where did it come from, what scope does it cover, is it still current, how authoritative is it, and which judgment will it change?

Material that cannot answer those questions should not gain influence merely because it is semantically related. Conversely, one short constraint that determines a permission or acceptance criterion can matter more than dozens of pages of background.

The output of context engineering is not the most complete prompt possible. It is an explainable allocation of attention: the system knows why certain evidence can affect the present and which history should remain in the archive until someone needs to inspect it.