How AI Agents Actually Remember (Part 2)

Part 1 looked at memory as a product: Mem0, Supermemory, and Letta, the libraries you bolt onto an agent. This part looks at memory you already use without thinking about it. If you run Claude Code, Codex, Cline, OpenCode, MiMo Code, Hermes, or OpenClaw, you are running a memory system right now. Each one made its own bet on what to keep, when to write it, where it lives, and how to pull it back. I read the docs and source for all seven and lined them up against the same four questions from Part 1, then checked them against the memory benchmarks. The benchmark result is the uncomfortable part, so I will end there.

They all converged on the same two layers

Read seven codebases and you stop seeing seven designs. You see one shape, repeated. A small layer that is always in the prompt, and a larger store the agent searches only when it needs to.

The top layer is a few markdown files: CLAUDE.md, MEMORY.md, AGENTS.md, whatever the tool names them. They load at session start and stay in context, so the agent never has to go looking for the project’s house rules. The bottom layer is everything that would blow the context budget if you pinned it: full session history, archived facts, the codebase itself. That layer sits in SQLite, a vector index, or just files on disk, and the agent reaches into it with search or grep or a file read. This is the same instinct Letta encoded as core-versus-archival in Part 1, except the coding agents reached it by trial and error rather than from an operating-systems paper. The interesting differences are not in this shape. They are in when the top layer gets written.

The real split is who writes the memory, and when

Storage is a solved problem. The live question every one of these tools answers differently is timing: does a human write the durable memory, or does the agent write it on its own?

On the manual side, the durable memory is a file you maintain. Claude Code’s CLAUDE.md, Codex’s AGENTS.md, and OpenCode’s AGENTS.md are static instructions the agent reads but does not rewrite. Cline goes further into ritual: its Memory Bank is six markdown files, and you refresh them by typing the exact phrase “update memory bank,” which forces the model to review every file in the set. The upside is control and a clean git diff of what the agent knows. The cost is that the memory is only as fresh as your last manual update.

On the automatic side, the agent writes its own memory as it works. This is where the design gets opinionated, and MiMo Code is the clearest case. Instead of waiting until the context window is nearly full, MiMo checkpoints early and often.

The figure is the whole argument for MiMo’s approach. A dedicated checkpoint-writer subagent extracts the working state into checkpoint.md at roughly 20%, 45%, and 70% of the token budget, running alongside the main agent so the extraction does not eat the main agent’s attention. Everyone else compacts reactively, only when the window hits 80% to 92% and something has to give. Writing three times before the pressure hits is why MiMo holds up on 200-step tasks where a single late compaction would have already lost the thread. Hermes sits in the same camp with a different trigger: it spins a task trajectory into a reusable skill file after any task that ran five or more tool calls. OpenClaw writes a silent “memory flush” turn right before it compacts, so unsaved facts hit disk before the summary buries them.

The seven side by side

Put all four questions against all seven agents and the field sorts itself into the two camps, with a few hybrids that refuse to pick a side.

Claude Code is the clearest hybrid: CLAUDE.md is hand-written, but its auto-memory writes itself mid-session on the model’s judgment, so it lives in both columns. Read down the How-retrieved column and you see the same restraint everywhere: a small index loaded up front, then on-demand reads, almost never a heavy vector search over everything. Only OpenClaw and a couple of plugins do real semantic retrieval over memory. The rest decided that grep over a markdown file beats an embedding lookup for the kind of recall a coding session needs, which is a quietly contrarian position given how much of Part 1 was about vectors.

A few storage details worth pinning down, since they decide whether memory survives a machine swap. Claude Code keys its auto-memory directory off the git repo and keeps it machine-local. Codex saves every session as JSONL rollouts under ~/.codex/sessions/ and, when memories are enabled, writes summaries it later reads and then greps. Here is the shape of Codex’s opt-in memory config:

# ~/.codex/config.toml
[memories]
generate_memories = true # write memory in the background
use_memories = true # read it back into new sessions
disable_on_external_context = true # skip MCP / web-search threads

Those three keys are the entire opt-in surface. generate_memories controls the background writer that fires after a thread sits idle, use_memories controls whether old memory is pulled into a new session, and disable_on_external_context keeps tool-heavy threads from polluting the store. Memories ship off by default and are geo-restricted, which is a sharp contrast with Claude Code’s auto-memory being on out of the box. If you assumed Codex was remembering across your sessions, check this block, because it probably was not.

Deduplication and conflict resolution: mostly nobody

Deduplication first. Across all seven, semantic dedup is rare. Most tools tell the user to prune by hand, or they just let near-duplicate facts pile up. The real exception is MiMo’s /dream command, a weekly pass that scans recent session traces, pulls durable knowledge into project memory, removes outdated entries, deduplicates, and validates that file references still point at real files. Codex has age-based pruning that evicts memories untouched for thirty days, but that is a timer, not an understanding of what duplicates what.

Conflict resolution is worse, and it is worth being blunt about. When two memories disagree, almost every tool falls back to load-order precedence plus the model’s judgment. Claude Code’s own docs admit that if two rules contradict, the model “may pick one arbitrarily.” OpenCode at least makes precedence explicit with a first-match-wins rule across its config layers:

# OpenCode rules precedence, first match wins per category
1. ./AGENTS.md (walk up from cwd) → ./CLAUDE.md
2. ~/.config/opencode/AGENTS.md (global)
3. ~/.claude/CLAUDE.md (Claude Code fallback)

That ordering settles which file wins when two files give conflicting instructions, project beating global beating the cross-tool fallback. It does nothing for the harder case: one file that says “we use Postgres” and a newer note that says “we migrated to SQLite.” For that, the most serious answer in the whole group is OpenClaw’s memory-wiki, which tracks contradiction clusters and tags each claim as contested, stale, or fresh, then uses that status to rank what surfaces. Even there, it surfaces the conflict for a human to resolve. It does not decide on its own. MiMo’s /dream is the only thing that actively deletes the stale side without asking.

How they score, and the number nobody likes

This section discusses the five established agent memory benchmarks. What they measure splits cleanly into two groups, and the split predicts where the agents are strong and where they fall over.

MemoryAgentBench (arXiv 2507.05257) is the one that matters most here, because it tests four memory abilities, including conflict resolution and selective forgetting. On plain retrieval the numbers are mediocre but workable: HippoRAG-v2 lands near 65%, classic BM25 around 60%, and the commercial memory systems lower, with Zep at 37.5% and Mem0 at 32.6%. Then you reach the conflict-resolution tasks and the floor drops out. Mem0 scores around 10%, and every system tested comes in under 16% on multi-hop conflict. That is the empirical version of the previous section: “let the model sort out contradictions at read time” does not work yet, and there is a benchmark that proves it.

The other four benchmarks fill in the coding-specific picture.

LongMemEval (arXiv 2410.10813) tests long-term chat memory across five abilities and shows even GPT-4o dropping about 37% from its oracle score once history gets long.

ContextBench (arXiv 2602.05892) scores how well a coding agent retrieves the right code context at file, block, and line granularity; Claude Sonnet 4.5 posts 0.624 F1 and GPT-5 0.634, and the telling result is that higher retrieval F1 does not always mean a higher fix rate.

SWE-ContextBench (arXiv 2602.08316) measures whether an agent reuses experience across related tasks, and SWE-Bench-CL (arXiv 2507.00014) measures continual learning with metrics for forgetting and forward transfer. The through-line across all five is the same. Agents retrieve passably and reason over fresh context well. They fail at the moment two pieces of memory disagree.

What this means if you are choosing a tool

If you want memory you can read and audit, the file-based tools are honest about what they know: open CLAUDE.md or the Memory Bank and the agent’s beliefs are right there in plain text. If you are running genuinely long tasks, MiMo’s early-and-often checkpointing is the design that holds up past the point where reactive compaction falls apart, and it is the only one with a real dedup pass. If your problem is contradictory knowledge piling up over months, none of them fully solves it, and OpenClaw’s contradiction clusters plus a human in the loop is the closest thing to a real answer.

The larger lesson lines up with Part 1. The frontier is not storage and it is not retrieval. Both are good enough. The frontier is write-timing, where MiMo is pushing, and conflict resolution, where the benchmark says everyone is still under 16%. Build with that in mind: assume your agent’s memory will accumulate contradictions, and put a human or a scheduled cleanup pass on the part the models cannot yet do for themselves.