The context window is the bounded information a model can use in a particular invocation. Retrieval selects information from outside that immediate context and brings relevant material into it. Memory is information the application preserves for later use, potentially across tasks or sessions.
These mechanisms work together, but they solve different problems. Storing a note does not mean the model currently sees it. Retrieving a document does not make it correct. A larger context window does not decide which information deserves attention or authority.
The word “memory” is especially overloaded. Here it means application-managed persistence, such as saved task notes or a durable record of a decision. It does not mean the model's training parameters or a guarantee that a conversational product remembers everything.
Follow one task through all three mechanisms
Imagine a coding agent investigating why a catalog endpoint returns too many results.
At the start, its context might include the user's report, repository instructions, selected tool descriptions, and recent conversation. The current implementation of the endpoint may still be outside that context.
The agent searches the repository for the route name. A search result identifies a handler and a parser. It reads those files, then retrieves the tests and the API contract. Those tool results become part of the information available for a subsequent model invocation, subject to the host application's selection and size limits.
The agent then discovers a useful historical note: a prior decision accepted leading zeros in the page-limit parameter. That note is memory. The agent should follow its source reference to check whether the decision still applies to the current implementation.
| Mechanism | In the example | What it does not establish |
|---|---|---|
| Context window | Report, selected files, test output, current instructions | That every relevant fact is included or used correctly |
| Retrieval | Search for the handler, read the contract, open the referenced decision | That the result is current, complete, or authoritative |
| Memory | Saved compatibility decision with date and source | That the decision remains valid or is present in this invocation |
Anthropic's context engineering discussion describes curating information throughout an agent's work, including retrieval and persistent notes. The table is an application-oriented interpretation using a synthetic example.
A context window is a limit, not an archive
The model operates on the input made available to it for a call, within the limits and accounting rules of the selected system. The host decides how to assemble messages, tool definitions, retrieved material, and other inputs. Some systems also reserve capacity for output or apply their own truncation and summarization policies.
Check the actual provider and product documentation before relying on a particular capacity. A model's advertised maximum does not tell you how much of a repository your chosen coding application will load, how it budgets tool output, or when it compacts a conversation.
For the catalog bug, a complete log archive may contain the needed request but consume far more space than the relevant code, contract, and failing example. Conversely, an aggressively shortened error message may remove the parameter that explains the bug.
The practical question is: what evidence must be available for the next decision? Before editing validation, the input contract and affected call path matter. Before reporting completion, the current diff and actual test results matter. The useful set changes as the task progresses.
Retrieval determines what gets a chance to be considered
Retrieval need not involve a vector database. A filename lookup, text search, SQL query, resource read, or document search can all select information from a larger store.
Different methods answer different questions. Exact search is useful when you know a symbol or error string. Semantic search can help when the user's wording differs from the code. Following imports and callers can uncover a dependency that neither search result makes obvious.
In the running example, finding parse_limit is only the start. The agent also needs to establish whether the request handler actually calls it and whether another layer transforms the value first.
Preserve enough provenance to evaluate the result: source path or URL, revision or update date when available, relevant location, and the scope of the retrieved excerpt. A snippet without its surrounding condition can reverse the meaning of a rule.
When retrieval returns nothing, distinguish “no match under this query” from “the information does not exist.” Try a different symbol, inspect a caller, or report the search limit. When it returns too much, narrow by subsystem or question rather than letting relevance be determined only by result order.
Memory needs a reason to survive
Not every intermediate observation deserves to become durable memory.
“The test failed at 14:03” may matter in the current task, while “the public export must preserve customer_id because importer X depends on it” may matter in future tasks. Both need sources, but they have different lifetimes.
For the catalog example, a useful saved record would say that leading zeros are accepted, identify the decision or contract, record when it was checked, and state that a contract revision should trigger revalidation. A note saying “pagination is fixed” offers little help and may become misleading.
Memory can store decisions, preferences, unresolved questions, or references. It should distinguish those types. A hypothesis copied into a persistent store does not become a fact, and an old user's approval does not automatically authorize a new action.
The same retrieval questions apply when loading memory: is this record relevant, current, and supported? Persistent misinformation can be especially troublesome because it reappears across sessions with the appearance of established context.
Where MCP fits
An MCP server can expose access to data or operations that help an application retrieve information. The server concepts documentation for MCP 2026-07-28 describes resources that applications can read and tools they can call.
In the example, a documentation server might return the API contract, while a repository tool searches for the handler. The host still decides how to present results to the model and how much context to retain.
MCP is not itself a universal memory store, a relevance ranking algorithm, or a policy for deciding which note is authoritative. A server may implement those functions behind its interface, but they are properties of that application.
This distinction is useful when debugging an integration. If a source was never retrieved, the problem may be discovery or search. If it was retrieved but not included in the model's input, inspect context assembly. If it was included and contradicted by an old note, investigate provenance and conflict handling.
Diagnose the missing-information problem precisely
Suppose the agent changes the parser and accidentally rejects leading zeros. Several failures could produce that result:
- The compatibility decision was never saved.
- It was saved but the retrieval query did not find it.
- Retrieval found it, but the host omitted it from the active context.
- It was present but stale or contradicted by newer evidence.
- It was present and correct, but the model implemented the rule incorrectly.
Those cases call for different fixes. Increasing the context limit does not repair a missing record. Adding more memory does not fix a broken test. Repeating the rule in every instruction file can create new contradictions.
For a difficult case, trace a required fact from its owning source through retrieval, context assembly, implementation, and acceptance checks. Keep the trace at the level your system actually exposes; do not claim visibility into hidden model processing.
Good context engineering makes the relevant evidence available and reviewable. Correctness still needs verification against the resulting software and the task's contract.
Research note: documentation reviewed October 28, 2026. The catalog example is conceptual; no model context-capacity benchmark, retrieval evaluation, or memory system experiment was run.
