AI coding agents need both a context window and project memory. The context window holds what the agent can use in the current interaction; project memory preserves selected knowledge across context resets and sessions. A larger window can help with a long task, but it cannot decide what information is worth keeping, carry it reliably into future sessions, or make old observations true after the code changes.
What a context window can—and cannot—do
A context window is the agent’s active working space: the code, instructions, tool results, and conversation it can consider at a given point. More room can help when a task involves many files or a long sequence of actions. But a sufficiently long task can still exceed that space. Anthropic describes long-horizon work as requiring agents to maintain coherence and goal-directed behavior across sequences whose token count exceeds the model’s context window.
As an Amazon Associate I earn from qualifying purchases.
When an agent reaches a context limit or starts a new session, earlier details may no longer be available in its active context. Some systems address a long task with compact progress notes, such as a to-do list or a NOTES.md file. That can preserve the current task’s status and dependencies, but it is not automatically a durable, reviewed record of how a project works.
Free tools Windows power users keep installed
One-click scans. No signup required.
Project memory fills a different role: it makes selected knowledge available again later. That knowledge can include conventions, decisions, attempted fixes, open issues, or links to relevant code and tests. It complements the context window rather than replacing it.
What belongs in project memory?
Good memory is not a transcript archive. It is information selected for its likely usefulness in future work, with enough context to judge whether it still applies.
Separate memory by scope and audience
VS Code distinguishes user memory, repository memory, and temporary session context. These categories answer different questions:
- User memory captures personal preferences that may be useful across projects.
- Repository memory records knowledge tied to a particular workspace.
- Session context holds temporary state for the task in progress.
Repository memory may be local to a workspace, so it is not necessarily shared with teammates. VS Code advises putting reviewed architecture decisions, commands, conventions, and workflows that contributors depend on in source-controlled project documentation or custom instructions. That distinction helps keep private working preferences separate from team guidance that needs review, version history, and portability.
Record more than standing instructions
Project knowledge can also be a history of work: what issue arose, which approaches were tried, what fixed it, and what decision the team made. One proposed projectmem design uses an append-only plain-text event log with typed issues, attempts, fixes, decisions, and notes, then derives compact summaries for an agent to retrieve. Its described pre-action gate can warn about repeating a failed approach or editing a file with a history of churn or open issues.
The projectmem authors report a two-month self-study spanning 10 projects and 207 logged events. That is an example of a structured workflow, not independent evidence that the approach improves productivity broadly.
How to make stored knowledge useful instead of stale
Memory can mislead when it is detached from the code that gave it meaning. A once-correct fix may no longer apply after a refactor; a file may have moved; an issue may already be resolved. More storage alone does not solve this problem.
MemTrace proposes immutable memory traces linked by execution order and dependencies, along with compact “Memory Anchors.” Its design checks historical evidence against the current repository before restoring it for use. This points to a practical standard for project memory: retain provenance, connect claims to relevant files, symbols, tests, or revisions where possible, and verify old evidence against the current state before acting on it.
Selection matters, too. Microsoft Research’s 2026 PlugMem article focuses on general LLM agents rather than coding agents. It argues that unstructured histories can mix useful experience with irrelevant details, making retrieval slower and less reliable. The article reports higher memory utility with fewer memory tokens than comparison methods across three benchmarks, but those are not coding-agent benchmark results.
Apple Machine Learning Research’s September 2026 paper likewise warns that persisting entire conversation histories can introduce irrelevant or stale reasoning. In three enterprise deployment scenarios, the paper reports task completion of 96% with selective persistent memory, compared with 79% without memory and 71% with full history. It also reports 97 times lower per-invocation token cost for summary-driven generation than raw data injection. These are results from the paper’s described enterprise scenarios, not a direct coding-agent comparison or a forecast for every deployment.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Choose a memory design for the job
| Approach | Best suited to | Key trade-off |
|---|---|---|
| Task notes, such as a to-do list or NOTES.md | Preserving progress and dependencies through a long-running task or context reset | Lightweight, but not necessarily maintained as shared project knowledge |
| Source-controlled documentation or custom instructions | Reviewed decisions, conventions, commands, and workflows contributors need | Shareable and reviewable, but requires normal documentation maintenance |
| Structured event log with derived summaries | Finding prior issues, attempts, fixes, decisions, and notes on demand | Can offer richer retrieval, but the event record and summaries need to stay useful and current |
| Selective, state-checked memory traces | Reusing prior execution evidence while checking it against the current repository | Designed to guard against stale evidence, but reported benefits remain specific to the evaluated system and tasks |
A February 2026 preprint offers a different kind of example: a 108,000-line C# distributed system developed with a hot-memory constitution, 19 specialized agents, and 34 on-demand specification documents. Its authors report observations across 283 development sessions. This illustrates codified context at scale; it is not a general performance result or proof that every project needs that degree of structure.
What the performance evidence does—and does not—show
Claims that persistent memory universally makes coding agents more accurate or productive go beyond the available evidence. Recent studies evaluate different systems, agents, tasks, and metrics, so their results should not be treated as a head-to-head ranking.
| Study | Setup reported | Finding reported by the authors |
|---|---|---|
| MemTrace, 2026 | Codex CLI; three long-horizon coding benchmarks | DeepSWE pass@1 improved by 21.2 points, SWE-EVO Resolved Rate by 4.4 points, and SWE-Milestone Score by 17.8 points |
| Context-file ablation, 2026 | 288 evaluated runs across 17 tasks from three repositories, using Claude Code and Codex | Context strategy did not measurably change correctness in that study; reported equivalence bounds were no more than 10–15 percentage points |
The context-file study’s failure analysis argues that many failures came from implementation skill rather than missing repository knowledge. It tests context-injection strategy in a specific setup, not every architecture for persistent memory. The MemTrace figures are reported results for its system and benchmarks, not gains an individual team should expect. Together, the studies support a narrower conclusion: persistent knowledge is a plausible aid, but its value depends on what is saved, how it is retrieved, whether it remains valid, and what outcome is measured.
Quick Recap
A practical way to introduce project memory
- Keep temporary progress separate. For a long task, use a concise task note to record the goal, completed work, current state, dependencies, and next action. Update it as the task changes.
- Put shared guidance under review. Move durable team conventions and decisions into source-controlled documentation or custom instructions instead of treating a private workspace file as a shared source of truth.
- Capture useful events, not every conversation. Prioritize concrete issues, attempted approaches, fixes, decisions, and links to the code or tests that establish their relevance.
- Retrieve narrowly. Prefer task-relevant summaries or records over automatically loading a large history. The agent needs the relevant evidence for the current task, not a transcript of everything that happened before.
- Check before reuse. Confirm that referenced files, symbols, tests, and repository state still match the memory. Mark or retire entries that no longer apply.
- Evaluate the outcome you care about. Track whether memory reduces repeated discovery or failed retries, and separately assess correctness and task completion. A lower token count or a more complete summary does not by itself prove better code.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
