Same Memory Commands. Safer Memory Records.

Fable’s return made the timing plain. Anthropic gave agents a file-shaped way to remember. MOOTx01 keeps that interface and stores the memories with review, history, and withdrawal.

Jul 08, 2026

The underlying idea of agent memory has been around for a while. People have been storing summaries, notes, preferences, and project state wherever their tools allowed.

What changed was the weight of the signal.

Anthropic launched Fable 5 on June 9, paused access on June 12, and restored access on July 1. In that same window, the public story around Fable became clear: highly capable agents work better when memory is designed as part of the loop from the start.

Anthropic’s own Fable guidance tells teams to construct a memory system. Their memory tool gives Claude a file-shaped contract for making that memory usable across conversations.

That contract is memory_20250818: one tool named memory, one root at /memories, and six operations that look like ordinary file work: view, create, str_replace, insert, delete, and rename.

That matters because agents already understand this shape. Claude can check a memory directory, read a file, write a lesson, update an old note, delete stale material, and come back later. It’s been around for a year; but with Fable it’s suddenly relevant.

For a demo, a local directory is a fine place to start.

For durable agent memory, the directory is only the handle.

A memory file can hold the sentence “always do this next time.” A reviewable memory record can carry the rest of the story: who wrote it, whether a person confirmed it, what it replaced, what replaced it later, whether it contains sensitive information, and whether the next session should trust it by default.

That is the part MOOTx01 supplies, just in time for the return of Fable

The Same Contract

MOOTx01 v1.0.25 lets Claude use Anthropic’s memory commands while MOOTx01 stores each memory as a reviewable record.

From Claude’s point of view, the surface stays familiar. The model still calls memory. It still works under /memories. It still uses view, create, str_replace, insert, delete, and rename. It still receives file-like responses with directory listings and line-numbered content.

The difference is what the user gets after the write.

Claude thinks it is writing memory files. MOOTx01 keeps memory records with source, confirmation state, change history, and withdrawal.

That sounds like implementation detail until the memory comes back tomorrow.

If the model wrote a good lesson, you want the next run to benefit from it. If the model wrote a bad lesson, stale rule, or poisoned instruction, you want the system to have enough record to review it, quarantine it, or withdraw it from active use.

Flat files give the agent a place to write. MOOTx01 gives the user a way to decide what that writing means.

What Happens Behind `/memories`

The command contract stays small. The behavior behind it gets richer.

When Claude calls create, MOOTx01 saves a new memory as unconfirmed and records that the model wrote it. The memory exists. It can be searched and recalled. It also carries the fact that a person still needs to confirm it.

When Claude calls str_replace or insert, the model sees an edit. MOOTx01 keeps the older version in the record, so a later review can see how the memory changed.

When Claude calls delete, MOOTx01 withdraws the memory from active use while preserving the audit trail. The model sees the file disappear. The user still has a record of what happened.

When Claude calls rename, MOOTx01 captures the content at the new virtual path and withdraws the old one.

When Claude calls view, MOOTx01 builds the directory listing or line-numbered file view from its memory records.

The agent gets the interface Anthropic designed. The user gets memory with source, confirmation, sensitivity, change history, a record of what happened, recall controls, and reversible withdrawal.

Two Ways To Use It

For MCP and interactive use, MOOTx01 exposes the memory tool through the daemon.

mootx01 enable memory-tool

For Messages API developers, the Python package is live on PyPI.

pip install moot-memory

The Python handler lets a Messages API application use MootMemoryTool where a local filesystem memory helper would otherwise sit. Claude keeps the same file-shaped memory interface. MOOTx01 keeps the records.

That is the drop-in point. The model keeps the file-shaped interface it already knows. The user needs a stronger record once memory starts carrying rules, lessons, preferences, and security mistakes from one session into the next.

The Product Lesson

The next stage of agent memory is persistence with a record. Persistence lets the memory come back. The record helps you decide whether it should. Anthropic gave the ecosystem a clean handle. MOOTx01 makes the memory behind that handle reviewable.

Same contract.
Better record.
Owned memory.

Discussion about this post

Ready for more?