Memory is part of the harness rather than a separate tool

The most effective agent memory is not a plugin or a service you bolt on after choosing a harness. It is built into the harness itself, reading and writing at the right moments in the agent loop. Claude Code reads CLAUDE.md and memory directories at session start. Pi reads AGENTS.md and SYSTEM.md. Hermes runs a learning loop that creates skills from experience without prompting. OpenCode Autolearn observes corrections in real time and escalates them to persistent rules. In each case, the memory system (see: agent memory persists context that the model window cannot hold) is integrated into the harness’s context-loading pipeline, not invoked as an afterthought.

This matters because memory timing determines memory quality. A harness that loads memory before the first prompt gives the agent accumulated context from the start. A harness that writes corrections during the session captures them while the context is fresh. A separate memory service called mid-session adds latency, costs tokens for retrieval, and risks returning irrelevant context because it sits outside the agent’s own awareness of what it just did. The harness-native approach is deterministic, instant, and free.

The tradeoff is flexibility. A standalone memory layer like Mem0 (see: agent memory persists context that the model window cannot hold) or Zep serves multiple agents and applications, persists across harness switches, and offers semantic retrieval that file-based systems cannot. But for a single daily-driver agent, the harness-native file approach compounds faster because it requires zero integration work. See file-based memory compounds corrections across sessions and persistent memory lets corrections compound.