One-Line Summary: Durable agent memory — across turns, sessions, machines, and users — is owned by the harness, not the model; this is one of the harness's load-bearing responsibilities and a major axis on which harnesses differentiate.
Prerequisites: What is an AI harness, agent state management, context window management
Status: Module 05 anchor concept — first draft.
What Is Harness-Owned Memory?
Models are stateless. Every API call starts fresh from whatever you put in the context window. Anything you want the agent to remember between calls — the user's name, what was tried last week, project conventions in a CLAUDE.md file, learned trajectories — has to be persisted by something outside the model. That something is the harness.
Harness-owned memory falls into a few categories: configuration files the user edits directly (CLAUDE.md, .cursorrules, AGENTS.md); scratchpads the harness writes during a session and replays at the start of the next; vector stores of past trajectories the agent can search; knowledge graphs of project entities and their relationships; and parametric memory (LoRA adapters or fine-tuned models trained on the user's data — emerging in 2026, especially in ruflo's micro-LoRA system).
How It Works
The harness intercepts each turn: before sending to the model, it pulls relevant memory and injects it as context; after the model responds, it extracts what is worth remembering and writes it back. The "what is worth remembering" decision is one of the hardest engineering problems in agent systems, and it is squarely a harness responsibility — the model has no opinion about persistence.
Why It Matters
Memory is the second-most-visible axis of harness differentiation, after permission/UX. A user evaluating Claude Code vs. Cursor vs. ruflo will compare: does it remember my project conventions? Does it remember our last conversation? Does it learn from my corrections? The answers are almost entirely about the harness's memory engineering.
How Harnesses & Frameworks Implement This
| Harness / Framework | Memory mechanism |
|---|---|
| Claude Code | CLAUDE.md files, conversation history, transcript persistence |
| Claude Agent SDK | Programmatic — bring your own store |
| ruflo | AgentDB (HNSW vector DB) + ReasoningBank + SONA learned patterns + knowledge graphs |
| LangGraph | Checkpointer pattern; memory store abstractions; per-thread persistence |
| AutoGen | In-memory conversation history; Memory tools (e.g. mem0) bolted on |
| CrewAI | Per-task memory; long-term and short-term memory toggles |
| OpenAI Agents SDK | Conversation state; bring-your-own for long-term |
| Codex CLI | Limited — session-scoped |
| Cursor | .cursorrules + per-project conversation history |
Connections to Other Concepts
agentdb-and-vector-stores-in-harnesses.md— The dominant long-term memory substrate.reasoning-bank.md— Trajectory-level memory (ruflo's signature feature).cross-session-memory-strategies.md— Patterns for what to keep between sessions.memory-portability-across-harnesses.md— Why the configuration file format is, in practice, the cross-harness memory format.../../ai-agent-concepts/03-memory-systems/long-term-memory.md— Foundational coverage.
Further Reading
- ruvnet, ruflo agentdb / reasoning-bank documentation — The most extensive harness-owned memory implementation in 2026.
- LangGraph "Memory" guide — The strongest framework-level treatment.