← All writing

Technical note · 2026-09-15

Agent context and memory: stored does not mean visible now

Separate current model input, execution state and cross-session memory, then examine retrieval, summaries, provenance and conflicting facts through a research-note example.

Exploration · Principles and possible approaches inspired by a project context.

  • AI learning
  • Context engineering
  • Memory
  • Persistence

A research assistant reads ten pages, then asks a question one of them already answered. Perhaps the page was stored but omitted from the current model input. Perhaps its summary lost a condition that mattered.

Inspect what the system retained and what the model actually received. A message still visible in the chat interface is not proof that it entered the latest request.

Think of current context as the pages on your desk and stored information as material in a filing cabinet. Owning a book does not mean you are reading it now. The application still needs to find relevant material and include it in the next call. The analogy describes information use, not human-like memory inside a model.

Three information lifecycles

Layer Example Question
Current context Goal, relevant passages and recent tool results What should this decision see?
Execution state Read sources, open questions, draft location and budget How can the task resume?
Cross-session memory Confirmed language preferences and project conventions What should another task reuse?

This is a learning model; one database may hold several layers. The LangChain memory overview distinguishes thread-scoped and cross-thread memory. Storage scope and current model input still require separate decisions.

“Write this summary in English” need not change a permanent language preference. Nor should a retrieved page saying “ignore previous instructions” become an execution rule. Scope and provenance affect how information may be used.

Storing a page and sending it are separate choices

Keep original material for verification while selecting relevant passages for a call. Anthropic’s context engineering article discusses on-demand retrieval, compaction and structured notes.

When drafting a section about retries, the input might contain:

Constraints: write a learning note, preserve sources, do not publish
Current question: determine the outcome of a timed-out save
Evidence: relevant passage from source A and its reference
Artifact: draft path and the section's existing contents
Unknown: whether the target service exposes operation status

The other nine full pages and earlier formatting discussions may add little. Still preserve conditions and negation: shortening “retry only if the service supports idempotency” to “retry” changes the instruction’s meaning.

Preserve facts that change the next action

Compare these original handoff summaries:

A: Retry behavior has been researched. Continue improving the article.

B: The draft is saved. One write has an unknown outcome and idempotency support is unconfirmed. Check operation status before resubmitting it.

The second retains decision-relevant state. Goals, restrictions, unfinished work, evidence locations and uncertain outcomes often matter more than every conversational turn.

Test a summary by giving it to an executor without the old history. Can it identify what must not happen and what needs verification? Fluent prose is insufficient if those conditions disappeared.

Memory needs provenance and a way to become stale

This record is an original design example, not a framework-mandated data format:

{
  "scope": "project:research-notes",
  "key": "preferred_language",
  "value": "zh-CN",
  "source": "user-confirmation:message-17",
  "confirmedAt": "2026-09-15",
  "status": "confirmed"
}

Distinguish preferences, facts and model inferences. Deployment addresses and dependency versions can change; check live state before consequential operations. A newer timestamp alone does not establish a more trustworthy source.

When records conflict, retain the evidence and resolve the conflict or apply a defined scope-specific update rule. Silently overwriting everything with the last sentence can conceal uncertainty. User or tenant boundaries also matter: semantic similarity does not authorize retrieving another person’s information.

A vector database, which can help retrieve items by similarity between representations of their content, is not a prerequisite. Known settings can use key lookup; source references can use IDs. Introduce retrieval by meaning when the task needs it, then measure missed and irrelevant results. Similar text is not necessarily true text.

Persistence is not model training

Saving a preference does not update model weights, the parameters learned during training. Later execution must retrieve and select it. In-memory state also disappears when the process stops; resuming after restart requires data that survives on disk or in a database. The LangGraph persistence documentation distinguishes checkpoints, saved thread progress, from stores that retain information across threads, and describes this limitation of in-memory implementations.

Test three scenarios: continue within a conversation, resume after a process restart, and begin another conversation requesting a different language. Which information should survive, which should be rechecked, and did a temporary instruction overwrite a lasting preference?

See harness recovery for execution records and agent evaluation for repeatable checks.