Memory console
The reset problem
Most agents today are goldfish. A task starts, the model gets a context window full of instructions, it acts, the task ends — and everything evaporates. Run the simulator with Persistent memory off: each task deposits lessons (the amber beads), and each task-end wipes them. The retained counter never grows. The agent re-discovers the same failures forever, and every run costs the same tokens to re-learn.
Flip persistence on and the beads survive into the episodic ring. By task three, the agent starts from accumulated experience — that difference, not smarter reasoning, is what turns a tool-caller into something you can leave alone for a week.
The four memory types (borrowed from cognitive science)
| Type | What it holds | Typical implementation | Lifespan |
|---|---|---|---|
| Working | The current task: instructions, recent tool outputs | The context window itself (8k–1M tokens) | One session |
| Episodic | What happened: past runs, failures, outcomes | Logs + vector store, retrieved by similarity | Weeks–forever |
| Semantic | Facts about the world and the user ("deploys happen Fridays") | Structured store / knowledge graph / notes file | Long-lived, edited |
| Procedural | How to do things: learned skills, playbooks, prompts that worked | Saved routines, fine-tunes, skill libraries | Long-lived, versioned |
Worked example: an agent asked to “fix the failing build” should consult episodic memory (“last Tuesday the same error came from a stale lockfile”), semantic memory (“this repo uses pnpm, not npm”), and procedural memory (“the lockfile-repair playbook”) — and only load the relevant slices into its limited working memory. Try shrinking the context-window slider: with fewer working slots, retrieval quality matters more, not less.