As of September 2026, it means one of three separate things, and teams keep collapsing them into one word. Memory can mean notes the agent writes to files it reads back later. It can mean pruning old tool results out of the conversation. Or it can mean retrieval from a store. They solve different problems.
The confusion matters commercially. We have sat in meetings where a client asked for an agent with memory and everyone in the room agreed, while each person pictured a different system. Two of the three interpretations were cheap and one was a six week build.
So here is the plain version of what the vendors actually ship, what has been measured, and how we would decide which of the three you need.
Because agent work is verbose. A single tool call and its result might be a few thousand tokens. Do forty of them in one task, add the model's own reasoning between each, and you have filled a large window with material that was only useful for about ninety seconds.
The failure is not usually a hard error. It is a slow degradation. As the conversation grows, the important instruction from turn three sits further from the current turn, buried under thirty tool results nobody needs any more. The agent starts forgetting the goal.
Long tasks are where this bites. A chat that lasts five turns never notices. An agent asked to work through a hundred step job notices constantly, and that is exactly the kind of work people want agents for.
Context editing, compaction and persistent memory. Context editing clears stale tool results out of the window automatically. Compaction summarises the older part of a conversation as you approach the limit. Persistent memory writes notes to storage that survive between sessions.
Only the third is memory in the way most people mean it. The first two are housekeeping inside a single run. They make a long task possible. They do not make the agent remember your company's naming conventions next Tuesday.
Getting this straight changes what you ask for. If your problem is that long jobs fall apart, you need housekeeping. If your problem is that the agent relearns your business every morning, you need persistence. Those are different builds with different risks.
Anthropic published numbers when it launched these features on September 29, 2025. It reported that combining the memory tool with context editing improved performance by 39 percent over baseline, and that context editing alone delivered a 29 percent improvement, while reducing token consumption by 84 percent.
The important caveats are in the same announcement. Those gains came from an internal evaluation set for agentic search and a 100 turn web search evaluation. That is a specific task shape, run by the vendor, on its own benchmark. It is a real number and it is not a promise about your workflow.
Anthropic said the capabilities were available in public beta on the Claude Developer Platform, natively and in Amazon Bedrock and Google Cloud's Vertex AI. We treat vendor benchmarks as evidence that a mechanism works, not as a forecast of what it will do for a client. The honest read is that the direction is right and the size is unknown for your case.
Retrieval fetches; memory decides. A retrieval system searches a store for passages that match the current question and drops them into the prompt. It is stateless and it is driven by the query. It has no opinion about what mattered.
Memory is the agent choosing to write something down because it judged it worth keeping. That judgement is the whole difference, and it is also the whole risk. A retrieval system can only surface things you put in it. A memory system can record its own mistaken conclusion and then treat it as fact forever.
Most business use cases we see are retrieval problems wearing a memory costume. If the knowledge already exists in your documents, tickets or CRM, you want retrieval over that source of truth. Our piece on building an AI internal knowledge base covers that path.
MCP is how the agent reaches your data, not how it remembers. The protocol's own architecture documentation is explicit that it focuses solely on the protocol for context exchange and does not dictate how AI applications use models or manage the provided context.
The shape is a host application creating one client per server, over either the stdio transport for local processes or the Streamable HTTP transport for remote ones. Servers expose three primitives: tools, which are executable functions, resources, which are data sources, and prompts, which are reusable templates.
The protocol has moved quickly and it is worth tracking. As of protocol version 2026-07-28, MCP is documented as a stateless protocol where every request carries its own version and capabilities, servers advertise themselves through a mandatory server/discover request, and the sampling and logging client primitives are marked deprecated in favour of direct provider integration and standard logging. We wrote more about this in our guide to MCP servers for web teams.
Everything downstream, quietly. A wrong fact in a prompt gets corrected on the next turn. A wrong fact in memory gets loaded into every future session, cited confidently, and used to justify further wrong conclusions. It is a bug that compounds.
The nastiest version is a memory written from a hallucination. The agent guessed a client's billing cycle, wrote the guess down as a fact, and from then on it is not guessing any more. It is reading its own note. Nothing in the system marks that note as lower confidence than a real one.
This is why we insist memory entries carry a source. If the agent cannot say where a remembered fact came from, it should not be allowed to write it. That single rule removes most of the compounding failure mode.
Write an allowlist, not a blocklist. Decide the small set of things worth persisting, such as user preferences, project constants, and completed steps in a long job. Everything else is transient by default. It is far easier to add a category later than to unpick a store full of noise.
Put an expiry on it. A preference stated eight months ago is weaker evidence than one stated last week, and a project constant becomes wrong the moment the project changes. Treat memory entries as having a shelf life and make the agent revalidate rather than assume.
Keep it readable by humans. If the memory store is an opaque vector blob, nobody on your team can audit what the agent believes. Plain files or plain rows that a person can open and correct are worth the small loss in elegance.
Less than the naive version, which is the actual argument for it. The token reduction Anthropic reported was 84 percent on its own evaluation, and even a fraction of that changes the economics of long running agents, because you pay for the whole window on every turn.
The hidden cost is storage governance rather than compute. Someone has to own what is in the memory store, review it periodically, and delete what should not be there. That is a small ongoing job and it is the one teams forget to staff.
There is a compliance angle too. If an agent writes a customer's details into a memory file, that file is now personal data in a place your data map probably does not cover. We go into the wider spend question in our piece on AI cost control for web teams.
Not yet, and the honest benchmarks say so. The OSWorld benchmark by Xie and colleagues tested agents on 369 real computer tasks. Humans completed over 72.36 percent. The best model in that paper reached 12.24 percent. Scores have improved since it was published and we are not going to invent a current figure.
Memory improves the long horizon problem. It does not fix grounding, and it does not fix the fact that a chain of forty operations has forty chances to go wrong. Better memory makes a capable agent more useful. It does not make an unreliable one safe.
So we would still keep a person at the point where the agent changes something. Memory is a performance feature. It is not an oversight feature, and it should not be sold to a client as one.
Retrieval first, over a source of truth the client already maintains. Then context housekeeping if the tasks are long. Then persistent memory last, scoped to a short allowlist, with sources attached and an expiry on every entry.
Doing it in that order means each layer earns its place. Most projects we have looked at stop after the first two, and the client is better off for it. The teams that jump straight to a memory store usually end up rebuilding it once they see what it has recorded.
If you are weighing this up for your own stack and want a straight opinion on which of the three you actually need, we are glad to talk it through. You can reach our team at phoenix.studio and we will tell you honestly when the answer is that you do not need memory at all.
Tell us where you want to go. We'll tell you how we'd get you there.