The agent we built keeps a running list of everything that happens, sends it to the model each step, and throws it all away when the run ends. That works for a one-shot question.
It fails in two directions, and the two failures are different enough that they need different fixes.
Failure one: the run overflows
Give the agent a hard task and watch the context grow. Every tool result is appended and stays. Read a large file, and its whole contents ride along on every later call. Search three times, and all three result sets accumulate.
The context window has a limit, so a long enough run hits it and the agent crashes before it finishes. This is a problem of space, and it happens inside a single run.
Failure two: the agent forgets you
Now use the agent as an assistant across days. Yesterday the user said "I'm James, I work in marketing." Today the agent has no idea who James is, because the run that held that fact ended and took the fact with it.
Every new conversation starts from nothing. This is a problem of time, and it happens between runs.
Space: one run overflows the window. Time: the next run remembers nothing.
Three words that organise the fix
Both failures come from having no memory management. Three concepts sort them out, and the rest of this chapter builds each one.
A session is one continuous conversation, like a single chat window. Everything said in that window belongs to the same session. Close it, start again later, and that is a new session.
Short-term memory holds the work inside one session: the conversation, the tool results, the
intermediate reasoning. It is what lives in the agent's ExecutionContext today, and it captures
everything automatically.
Long-term memory holds what should survive after a session ends. "James works in marketing" belongs here, so next week's session can use it. Long-term memory is selective: a step at the end of a run decides which facts are worth keeping.
The two stores differ in how things enter them, and that difference is the whole design. Short-term memory records everything, without asking. Long-term memory saves almost nothing, on purpose.
| Short-term memory | Long-term memory | |
|---|---|---|
| Scope | One session | Across sessions |
| What enters it | Everything, automatically | Selected facts, deliberately |
| Lives in | ExecutionContext.events | A separate, persistent store |
| Fixes | The space problem | The time problem |
Two problems, two halves of the chapter
The two failures map cleanly onto two bodies of work.
The space problem is solved by managing the context during a run: keep the window small enough to survive, without losing what the task needs. That is compression, and it comes first.
The time problem splits in two. Keeping a conversation coherent across several runs needs a session: a container that persists between calls so the agent remembers what was said a moment ago. Remembering across different conversations needs long-term memory: a store the agent writes selected facts into and retrieves from later.
One architecture, three tools: compression for space, sessions for continuity, long-term memory for time.
What to take from this
- The append-everything-then-discard agent fails two ways: a run overflows the window (space), and the next run remembers nothing (time).
- Three concepts organise the fix. A session is one conversation; short-term memory holds a session's work automatically; long-term memory holds selected facts across sessions.
- The two stores differ by design. Short-term captures everything; long-term saves almost nothing on purpose, which is what keeps it useful.
The space problem is the one that crashes a run today, so it goes first. The next post starts with the single idea that makes context management possible: the difference between what the agent stores and what it shows the model.