Back to Blog
LoreConvo

Anthropic Shipped a Memory Primitive. Here's What It Doesn't Include.

Anthropic's memory_20250818 tool gives your agent a filesystem and read/write operations. Everything else -- search, tagging, expiration, cross-surface access -- is left as an exercise for the developer. Here is what teams building on the primitive are reinventing, and how LoreConvo fits into that picture.

Two-panel comparison. Left panel labeled memory_20250818 shows a stack of four files named memory_001.txt through memory_004.txt with a list of missing capabilities: no search, no tagging, no cross-surface isolation, no expiration, no structure. Right panel labeled LoreConvo shows rows of books on shelves, an FTS5 search index card mapping queries to sessions, and tag pills for project, agent, surface, and expires. Caption reads: The primitive gives you file drawers. LoreConvo gives you the library.

When Anthropic shipped the memory_20250818 tool, developers building on the Claude API got something genuinely useful: a standard interface for giving Claude a place to store and retrieve memories across conversations. If you have found it in the docs, you may have also asked a reasonable follow-up question -- why would I install a third-party plugin like LoreConvo when Anthropic already built this?

The answer is that memory_20250818 is a primitive, and LoreConvo is a solution built on top of what the primitive provides. Understanding the difference requires looking carefully at what the API tool actually ships and what it deliberately leaves out.

What the API Tool Provides

The memory_20250818 tool gives your Claude-powered application a /memories directory and the ability to read from and write to it. When your agent wants to remember something, it writes a file. When it wants to recall something, it reads a file or lists the directory. The tool handles the protocol between Claude and that filesystem; the actual storage layer is whatever you provide -- a local directory, an S3 bucket, a database, anything that satisfies the interface.

That is a thoughtful design. By defining a protocol rather than mandating a storage backend, Anthropic gives developers full control over where their memory data lives and how it is retained. Your data, your infrastructure.

The tradeoff is that the protocol defines only the primitives. Read, write, list. Everything above that layer is left to you.

What You Have to Build Yourself

Consider what a production memory system for an agent actually needs. When a developer says "give my agent persistent memory," they rarely mean "let it write files to a directory." They mean the agent should be able to find a fact it saved three weeks ago, distinguish work it did in Claude Code from work it did in a chat session, remember that this context belongs to Project A and not Project B, and expire stale information before it starts contradicting itself.

The raw memory_20250818 interface gives you none of that. Search is not included -- you get a directory listing, not a query engine. Tagging is not included -- every memory is a file with a name, and the naming convention is yours to invent. Cross-surface isolation is not included -- if your agent runs in both Claude Code and Claude.ai chat, the memories end up in the same pool with no way to distinguish them unless you add that structure yourself. Expiration is not included -- a memory written on day one will sit in that directory forever unless you build a cleanup job.

Teams that adopt memory_20250818 and actually need those features end up writing the same infrastructure. A wrapper that adds full-text search. A tagging convention, then a parser for that convention. A surface identifier field in each file. A cron job to prune stale entries. A way to export everything for a new team member or a different Claude environment.

LoreConvo is what those teams keep building.

What LoreConvo Adds

LoreConvo stores session memory in a local SQLite database with an FTS5 full-text search index. When you save a session with tags for the project, agent, and surface, you can find it later with a keyword query -- and it will surface the right context even if you cannot remember the exact phrase you used. The session was tagged with project:reporting_pipeline and agent:ron-builder, so a search for "pipeline build errors" finds it and everything else related to that project strand, without you having to know the filename or the date.

Cross-surface isolation comes for free. Work done in Claude Code shows up differently from work done in chat, because the surface field is part of every save. When you search, you can scope to a surface or search across all of them.

LoreDocs vaults sit alongside the session memory. A session captures what happened -- decisions, artifacts, open questions. A LoreDocs vault captures the reference layer -- the architecture doc you want every agent to start from, the style guide, the API contract. The two complement each other in a way that a raw /memories directory cannot, because a flat file namespace does not distinguish between ephemeral session context and authoritative reference material.

None of this requires running infrastructure beyond your laptop. SQLite is a single file. FTS5 is built in. LoreConvo installs in one command.

Using LoreConvo as the memory_20250818 Backend

The integration story is more direct than a comparison between two approaches. If you are already building with memory_20250818, LoreConvo can slot in as the storage backend without changing your Claude API code.

LoreConvoMemoryBackend subclasses BetaAbstractMemoryTool, the abstract base class Anthropic provides. You drop it in where the raw primitive would go, and your existing API code continues working. The difference is that every memory write now goes into LoreConvo's SQLite store as a session tagged surface=memory_bridge. You get structured tagging, full-text search across everything saved, and the ability to export or inspect your agent's memory using LoreConvo's standard tools -- all without touching the API integration you already built.

This is not a migration. It is a backend swap. The protocol stays; the storage layer becomes searchable.

The Right Tool at Each Level

memory_20250818 is the right choice if you are building your own memory system and want to integrate at the primitive level. It is a well-designed protocol, and the flexibility to bring your own backend is genuinely valuable if your requirements are unusual -- regulatory constraints on where data lives, an existing vector store you want to reuse, a team-scale multi-user memory system that needs access control you design yourself.

LoreConvo is the right choice if you want persistent, searchable, structured agent memory without building those things. It is also the right choice as the memory_20250818 backend if you want the standard API protocol and a real storage layer under it.

The file cabinet and the library are not competing alternatives. The cabinet is what sits inside the library walls.


LoreConvo is available on the Anthropic marketplace and installs with uvx loreconvo. Free tier covers fifty sessions. Pro tier is unlimited. Find it at /tools.

Labyrinth Analytics Consulting helps organizations navigate the dark corners of their data. Learn more at labyrinthanalyticsconsulting.com.

More from the blog