Context windows and agent memory: what persists and what must be checked again?

Separate three meanings of memory

A support user named a device earlier and now asks about repairing it. The assistant might use current messages, a conversation summary or a stored case record. These are different layers with different lifetimes: request context, application history and persistent memory.

LangChain's conceptual documentation distinguishes thread-scoped short-term memory from memory shared across conversations. This is useful terminology, not a recommendation for one framework. The architectural requirement is to explain where each piece of information lives, when it is read and whose authority permits its use.

A context window is not a permanent archive

The context window bounds what a model call can process. Information in an old conversation is not necessarily present in the current request. Capacity and output allocation vary by model and configuration; a headline window size is not the useful capacity of a particular workflow.

In the proposed repair workflow, store the device identifier and approved process stage as explicit application state. An equipment change should create a clear state transition. Hoping the model notices it among many messages is weaker than maintaining a transition an operator can inspect.

More text is not automatically better evidence

Lost in the Middle found position-sensitive performance in the models and tasks it studied. It is not a universal error percentage for today's systems. Its practical lesson is to test evidence use rather than only advertised input capacity.

Place the critical repair condition at the beginning, middle and end of otherwise controlled input bundles. Add similar distracting passages. Hold the expected answer and model version constant. If placement changes performance, assess evidence selection and ordering as well as context size.

What can summarization remove?

A summary is helpful but does not guarantee preservation of every condition. Replacing 'replace the part after supervisor approval' with 'replace the part' changes the permitted action. Keep summaries linked to their source messages and documents rather than elevating them above original evidence.

Anthropic's context-engineering article discusses compaction and structured note-taking for long tasks. Our proposed case design separates identifiers, decisions, constraints and unresolved issues. Before acting, retrieve the approval condition from authoritative application state, even when the summary appears to remember it.

Give persistent notes provenance and scope

Remembering a display preference differs from storing a model's guess about someone's financial authority. Record the note type, owner, source, creation time and permitted scope. A conversational preference must not become a permission or an organizational fact.

In the illustrative design, case notes remain case-scoped, display preferences remain user-scoped and shared organizational knowledge follows its own approval route. Reevaluate use after a role change or case closure. Staleness concerns authority as well as dates.

For more on this topic, read Data architecture for enterprise AI agents in the Liyan knowledge base.

Handle conflicts between memory and current evidence

Suppose a summary says the device is under warranty but the current case record says coverage ended. The system should expose that disagreement, identify source versions and route unresolved cases to the responsible person rather than select a convenient statement confidently.

Reread changing values such as order status or permissions from their current system. History remains valuable for describing past conversations. Define precedence by information type; 'the newest text wins' could incorrectly elevate a fresh untrusted message above an approved policy.

Check deletion across retained copies

A deletion operation needs a defined scope covering the relevant store, summaries, caches and indexes. This article does not prescribe legal retention periods. Data owners and organizational policy determine the requirements; the implementation must make its behavior testable.

Use a distinctive synthetic note, perform deletion or revocation and repeat the question in a fresh session. The content should not reappear from a forgotten summary. Report tested paths and remaining limitations, not merely the interface's success message.

Four acceptance tests for memory

Prevent information crossing unrelated cases. Make an explicit device change affect later references. Enforce revoked authority within an ongoing conversation. Expose conflicts between an old summary and a new approved record. Define the permitted answer and escalation behavior before running each case.

Measure response time and context cost without treating savings as success when a critical condition disappears. Deliver a memory-store map, read/write rules, policy ownership and representative failures. Organizational value requires control over forgetting and rechecking as well as remembering.