Context Engineering vs Agent Memory: What's the Difference?
Context engineering and agent memory overlap rather than compete: memory is one of the things context assembly loads. The split worth keeping is what gets stored versus what gets loaded for a turn, and the symptom your agent shows tells you which one to open.
DosuTwo engineers on the same team watch a coding agent make the same mistake, and they reach for different fixes. One rewrites the repository instruction file and narrows what the agent retrieves. The other starts shopping for a memory service. Both changes are plausible, and only one of them touches the thing that broke.
These are overlapping concerns rather than rival categories. Context engineering covers everything that decides what a model sees, and durable note-taking for long-running tasks sits inside that discipline rather than outside it. The split worth keeping is narrower. One side is what gets stored outside the conversation, the other is what gets loaded into a given turn. Both have to work, they fail in ways that look identical from the outside, and the symptom usually names which one broke.
Per-call context assembly decides what reaches the model now
For any single model call, something has to assemble the input. That input is an inventory: system instructions, a repository instruction file, your request, recent conversation history, code snippets pulled by a search, and output from tools the agent ran, such as a test or a file read. Private, task-specific facts that the model did not learn during training need to reach it through the input or a tool result. Those are the runtime inputs this section covers.
The window has a fixed size, so the same layer decides what gets left out. An agent might select four files instead of a whole package, truncate a long test log, or summarize earlier turns before continuing. Every one of those choices changes what the next response can draw on. When an agent fills its window with loosely related files and answers in generalities, the selection and compression rules are where to look.
The window is the working set for one call, holding what was loaded for it and nothing more. An instruction file persists on disk, and the agent can read it again on the next call, but durability there belongs to the file rather than to the window. Conversation history behaves the same way: it returns on a later turn because something carried it forward, not because the window kept it.
Everything in this layer is adjustable before the next call. You can change the instruction file, change what retrieval selects, or change how much tool output survives into the prompt. Changing selection or compression alone does not save a new decision. Adding that decision to a persistent instruction file does, so an instruction-file edit can serve both the write path and later context assembly.
Agent memory decides what still exists to reach it later
Agent memory is the pair of paths around a durable store. A write path records something outside the context window, into a file, a database, or a service. A retrieval path finds that record when a later task calls for it and puts it into the window for that turn. Both paths have to work, and they fail independently.
Say your team settles that new list endpoints use cursor pagination rather than offset pagination. For an agent to apply that next week, the decision has to land somewhere durable at the moment it was made. When you later ask for a new endpoint, retrieval has to surface the record and get it into that turn's input. You can check the two steps separately: look for the stored decision, then look at what the agent received on the task where it went wrong.
Coding agents ship their own persistence features, and tools differ in what they keep and for how long. The split described here is a mechanism rather than a feature list for any particular product. A fresh context window may already contain startup instructions or memory, while other records are retrieved only when needed. Starting a new session does not erase the durable store or guarantee that every stored fact has been loaded.
The split in one table
| Per-call context assembly | Agent memory | |
|---|---|---|
| What it decides | Which of the available material is loaded into this turn, and what gets cut | Whether the material exists outside the conversation at all, and whether it can be found |
| Where you change it | Instructions, retrieval rules, compression, tool output handling | The store, the write path, the retrieval path |
| Symptom when it fails | Material existed and was not loaded, or noise crowded out what mattered | Nothing was recorded, or a record exists and nothing surfaces it |
| What to inspect | The input assembled for that specific call | The durable record, and what retrieval returned |
Assembly is one part of context engineering, not its opposite. The columns separate storing from loading so you can tell which one to go and look at.
Neither side works without the other
Retrieval cannot recover a decision that nothing wrote down. A store can hold the cursor pagination rule for a year, and the agent still builds an offset endpoint if retrieval never selects it for that task. The two layers sit in series, and a break anywhere in the chain produces the same visible result.
One-sided fixes disappoint for the same reason. Teams that connect a memory service and change nothing about retrieval find the agent writing notes it never reads back. Teams that invest only in context assembly build a careful selection pipeline over a store with nothing durable in it. Ask which link broke on the failure in front of you rather than which layer matters more.
A quieter failure sits alongside those two. Knowledge can be written durably, get retrieved on the right turn, and still arrive in a form the model cannot act on. A decision recorded as a terse title with no rationale clears both paths and leaves the agent guessing at intent. Durability and retrieval are necessary, and what gets written has to carry enough to act on.
Read the symptom to find the failing side
Start from what the agent received when the symptom appeared, then compare that against whatever durable record exists. A missing record points at the write path. A record that exists but never arrived points at retrieval or selection. A record that did arrive and was ignored is neither, and the fix there is in the wording or in the conflict between instructions.
- It re-reads files it read twenty minutes ago. Within one task, check whether the earlier file output or a usable summary is still in the window. If a compression step dropped it, the fault is on the assembly side, and the fix is retaining the relevant excerpt rather than the whole file. If the re-read happens after a fresh session starts, ask instead whether anything saved the finding.
- It contradicts a decision from last week. Check whether the decision was recorded, then inspect the input on the failing turn. No record points to the write path. A record missing from the input points to retrieval or selection. If the decision was present but not followed, check for ambiguous wording, conflicting instructions, or a model error before changing the memory system.
- It fills the window and answers vaguely. Read the instructions, file excerpts, and tool output supplied for that call. Repeated or marginal material crowding out the evidence is a selection and compression problem, and the fix is narrowing retrieval or summarizing older output.
Run the check before you buy or build anything. The three symptoms above are the ones teams describe most, and two of the three can land on either side depending on whether a session boundary sits in the middle.
Where Dosu sits in this split
Dosu works on the memory side. The Dosu MCP Server exposes read_knowledge for loading curated context scoped to the Sources connected to that server, and write_knowledge for recording something durable an agent learned while working, such as a decision and its rationale or a constraint that is not obvious from the code. Notes are append-only and save directly rather than waiting in Review. When the client supplies both a connected repository and a valid branch, the note is scoped to that pair and Library members can read it on the same branch. Notes on an unmerged feature branch become Topic candidates after its PR merges. Unanchored notes, and notes on the default branch or an already-merged branch, can be promoted without waiting for another PR.
Write-path and retrieval-path mechanics are the whole of what Dosu claims here. Dosu does not assemble your agent's prompt. Claude Code, Cursor, and VS Code Copilot each decide what enters the window on a given call, and any MCP-compatible client keeps that control. If your diagnosis lands on selection and compression, the fix belongs in the agent's own configuration, and Dosu changes what is there to select from rather than how the selection runs.
For the adjacent question of which placement suits which fact, where coding agent memory should live covers local files, the repository, and a shared service side by side.
FAQ
Does a bigger context window remove the need for agent memory?
A larger window lets an agent hold more during a turn. A new session may open with startup instructions or memory already in place, so it is not blank, and other records are fetched only when something asks for them. What no amount of capacity supplies is a fact nobody arranged to store, since capacity alone does not create a write path.
Is retrieval-augmented generation the same thing as agent memory?
Retrieval-augmented generation is the retrieval half. An agent can retrieve repository documentation all day and store nothing it learned during the session, which leaves the next run rediscovering the same thing. Memory adds the write path, and the two halves fail separately.
Can context engineering alone fix an agent that contradicts earlier decisions?
Only if the decision exists somewhere the agent can reach. Check for the record first, then inspect what the agent received on the turn where it contradicted the decision. With no durable record, changing retrieval has nothing to find. When the decision did reach the model and went unheeded, neither side is at fault, and the thing to examine is whether the wording was ambiguous or another instruction contradicted it.
Check one contradicted decision this week
Pick one decision your agents keep relitigating. Look for a durable record of it outside the conversation where it was made, then read what the agent received on the turn it went the other way. A missing record is a write-path problem, and a record that never arrived is a retrieval problem. The answer decides where the fix goes.
If the record is missing, an organization admin can create a Dosu Library and connect the repository as a Source. Run npx @dosu/cli setup to connect your client, then ask the agent to call write_knowledge with the decision and its rationale. In a later session on the same repository and branch, call read_knowledge and check that the saved decision is returned before relying on it.