Agent memory is decided in the architecture, not in the prompt

MCP was born without memory, and not by accident. Every tool call made through the Model Context Protocol is a request with its response: the agent asks, the server returns, and the protocol offers no native mechanism to keep what was learned from one session to the next. That limitation is the starting point of an analysis published this Monday, 12 October, on HackerNoon, whose headline sums up the thesis: agent memory is an architecture decision.

The piece looks at the move from MCP servers, designed as stateless tools, to stateful agents that can retain facts, decisions and context between runs. It is not a new debate, but it is an increasingly practical one. Teams that already run agents in production find that the agent handles today's task well and remembers nothing about yesterday's.

What changes when memory is architecture

Treating memory as an implementation detail usually ends in the same place: a vector store bolted on at the last minute, a RAG pipeline that retrieves loosely relevant fragments and a context window that fills up with noise. Seeing it as architecture means the opposite. Before choosing a model or a framework, you have to decide what the agent remembers, for how long, who can write to that memory and how it is retrieved.

In practice, that means separating at least three layers:

In-context state: what the model sees in the current call. It is immediate, but expensive in tokens and disappears when the session closes.
Semantic retrieval: embedding searches that bring back past documents or conversations. Useful at large volumes, fragile if nobody watches what gets indexed.
Structured persistent memory: facts, decisions and relationships stored in a database or a graph, with explicit write and expiry rules.

Each layer has different costs and fails in different ways. Mixing them without criteria is what produces agents that contradict themselves or repeat work already done.

MCP as an interface, not a store

The most useful nuance in this approach is not asking MCP to be something it is not. The protocol solves the interface well, that is, how an agent talks to an external system. Memory can be exposed as just another MCP server, with tools to read and write, but the design of the store, its schema and its forgetting policy remain the team's responsibility. There are already projects heading that way, from servers that store conversations in SQLite or PostgreSQL to knowledge graphs shared between several agents, as covered in this MemoryLake overview of the layer MCP is missing.

That separation has a clear advantage: memory becomes portable. If it lives behind an MCP interface, Claude Code, Claude Desktop or any compatible client can consume it without rewriting the persistence logic.

Why it matters in the Claude ecosystem

Anyone working with Claude Code already lives with several forms of memory, even without calling them that. `CLAUDE.md` files act as declarative memory loaded at the start of every session. Skills package instructions and context that the model invokes on demand. Subagents work with their own context and return only the conclusion, which is itself a decision about what enters the main window. And hooks make it possible, for example, to dump a summary at the end of a session using the `Stop` event.

The optional 1M token context window in Claude Opus 4.8 can give the impression that the problem is solved through sheer capacity. It is not. Putting more history into context makes every call more expensive and does not guarantee that the model prioritises what matters. Well designed memory decides what goes in, and that is cheaper and more predictable than trusting the model to find the needle in the haystack.

Who it is useful for

The approach is mainly relevant to these profiles:

Teams taking agents to production who need continuity between sessions without blowing up token spend.
MCP server developers wondering whether their server should hold state or delegate it to another component.
Technical leads who have to justify where the agent's data lives, who sees it and when it is deleted, which under GDPR in Europe is not optional.

For small projects or single session tasks, none of this pays off. A good `CLAUDE.md` and a clean context are enough.

Our take

In the agents we have built for clients, memory problems almost never came from the model, but from not deciding early enough what should persist and what should not. We share HackerNoon's thesis: memory is worth designing at the start, with the same care as a database schema, because changing it later costs a lot more.