Memory

This is the first part in Block II - and with it the first step out of the harness. Everything so far (the call, message history, system prompt, tools & loop, guardrails) was on-board equipment: code in your own process, a few files, a loop. Memory is the first part that can stand as a service of its own next to the agent - with its own storage, its own container, its own bill. But before we talk about products, the mechanics have to be clear. Otherwise you buy a product for a problem you haven't understood yet.

There is no remembering. There is only re-sending.

The LLM call is stateless, and message history showed what follows from that: on the second call the model has no idea there was a first one. The impression that "the model remembers" comes solely from the fact that we put the whole conversation back into the request every single time.

The same holds for memory - just one size up. "The agent remembers that I'm called Markus and prefer Docker" technically always means: that sentence sits somewhere as text, and somebody wrote it into the prompt before the call. There is no memory inside the model, no database behind the API, no account on the other end. There is only text that travels along.

Which gives us the guiding question of this entire part - and it has nothing to do with product names:

How does information get into the context at all?

And the follow-up that decides everything else: what do we send once per session, and what per request?

One-time context baggage: what's always along

This is the static part - loaded when the agent starts, and present in every call afterwards. Three kinds of file show up again and again in practice:

SOUL.md - who the agent is. Identity, stance, role, tone, what it refuses. This is the file the system prompt grows out of - in an agent with character, often the single largest chunk of context. How to write such a soul without it collapsing into kitsch is the subject of the tutorial The soul in a single file.

AGENTS.md / CLAUDE.md - what the agent needs to know about its environment. Not character but operating knowledge: where things run, which commands apply, which constraints are non-negotiable. This project works exactly that way. Its CLAUDE.md contains sentences like "Everything runs in Docker - always. No host-Node escape hatches", "asChild does not exist in the base-nova preset", "messages/de.json and messages/en.json must stay in lockstep". Every one of those sentences is there because its absence once cost a build. The agent reads them at the start of every session - they are its memory for things it would otherwise get wrong afresh every time.

Skills and instruction files that are only loaded on demand. The trick against overflowing baggage: not all knowledge is needed all the time. An agent knows only a short list up front ("there's a guide release, one create a video, one file an issue") and loads the full instructions only when the task calls for them. The catalogue costs a few lines; the content costs only when it matters.

The unromantic arithmetic: this baggage is present in every call, before the user has said a word. A soul plus operating knowledge plus tool definitions add up to a few thousand tokens in no time - on every single call, in every round of the tool loop. Anyone who never re-weighs their context baggage keeps paying for a file they wrote three months ago, every second the agent runs. That's why "does this really have to travel every time?" is not penny-pinching but the central design question of this part.

Context per request: what fits the question

The dynamic part. Here it's decided per request which fragments out of a large store travel along. Three routes, and they differ mainly in who decides:

1. Retrieval - the harness searches. Before the call, fragments matching the question are looked up (by similarity, by keyword, or both) and pasted into the prompt. The agent notices nothing; as far as it's concerned the knowledge is simply there. Classic, reliable - and blind to everything the query doesn't hit.
2. Tool call - the agent fetches what it needs. The agent gets tools like search_memory or get_facts and decides for itself whether and what to search for. That costs an extra round in the loop, but it's more honest: the agent knows better than a pre-flight search what it's currently missing - and it can ask again when the first result gives nothing.
3. Injection by the service - the memory system writes along. An external system hooks itself in ahead of the call, fetches what it considers relevant, and pushes it into the prompt. This is the route services like Honcho or Mem0 typically offer: one line of integration, and the context is "enriched".

This table is the core of the whole part. Everything that follows - vector stores, fact extraction, wiki pages - is just a different answer to the one question of who gets to decide what enters the context. And it has no universally right answer: with retrieval, relevance is reproducible; with the tool call, situational; with injection, convenient. Anyone who has to chase down a mistake will want that order exactly reversed.

The break: from here on we leave the harness

Everything up to this point was harness - files you write yourself and code you control yourself. For many agents that's the end of it, and that's no shortcoming: a Markdown file plus message history is a fully valid memory. This repository runs its own project memory exactly that way - a directory with one file per fact and an index file that is loaded into every session.

From here on it's about memory systems outside the harness: services with their own storage, their own containers, their own operations. The price isn't the code - that's usually alarmingly short. The price is that a second system comes into existence, one that has to run, grow, age, be migrated and be deleted. Hence the map first.

The map: four approaches in two sentences each

RAG - retrieval over documents. A corpus is cut into chunks, embedded and searched against the question; the result lands in the prompt. That's memory too, just over manuals instead of conversations - and it's already fully covered here, in the RAG tutorial.

Honcho - a model of the user, not of documents. It stores not merely what was said but what follows from it about the participants: peers, sessions, and representations derived in the background that you can query in natural language ("what do you know about how this user works?").

Mem0 - the classic entry point: an LLM extracts facts from the conversation and stores them as short sentences in a vector store, which later queries pull back up. Embedded as a library in a handful of lines, self-hosted as a server, or rented as a cloud platform.

LLM Wiki - not a product but a pattern: the agent maintains its own knowledge pages as linked Markdown files. Instead of a similarity search over text chunks it navigates references between pages - and the result stays readable and correctable for humans.

An agent doesn't remember - it re-sends. Every form of memory ends with text being written into the prompt before the call; the only question is who picks that text: the harness (retrieval), the agent (tool call), or an external service (injection).

While doing that, separate one-time baggage (SOUL.md, AGENTS.md, the skill catalogue - present in every call and paid for in every call) from context per request (the little that actually fits the question at hand).

And: a memory service is a second system with operations of its own. A Markdown file plus message history carries surprisingly far - the service only pays off once you have more conversations than you can oversee yourself.