Context is what the model sees in the current call. It includes the system prompt, the user messages, the model's previous replies, and any retrieved chunks injected for this turn. Context does not survive past the call.

Memory is what survives between calls. It includes the long-term notes the agent writes, the semantic index over past work, the wiki pages the human maintains, and the state files the platform persists. Memory is what makes the agent recognizable to itself across sessions.

How they differ

| | Context | Memory | |---|---|---| | Lifetime | One call | Across calls | | Size | Context-window bound | Disk-bound | | Owner | The platform | The agent (mostly), the human (some) | | Read pattern | Sequential, full | Indexed, partial | | Failure mode | Overflow | Drift |

Why the distinction matters

Conflating context and memory is the most common design mistake in agent work. The two layers have different jobs, different costs, and different failure modes. Treating memory as context produces agents that drown in their own notes. Treating context as memory produces agents that forget everything between calls.

A useful test: ask "would I want this in the next call but not in the current one?" If yes, it is memory. Ask "would I want this in the current call but not in the next one?" If yes, it is context. Anything that should be in both is in the wrong layer.

Failure modes

  • Context overflow. The context exceeds what the model can read. The agent's behavior becomes unpredictable. The fix is at intake — bound the retrieval, shorten the system prompt.
  • Memory drift. The memory file grows without bound and accumulates contradictions. The agent treats stale notes as current. The fix is at the wiki — hand-edit, mark superseded, prune.

See also