Some Memories Deserve a Name

Most memories are moments. You save them, they flow into the graph, and search brings them back when you need them. That's the MemNexus model, and it works well for the hundreds of observations, decisions, and debugging notes that accumulate over a project.

But some memories are different. They're not moments — they're reference points. Your dev loop. Your deployment runbook. The rate limit config you update every time the team revisits capacity planning. These memories matter enough that they should have a name you can remember, not just a UUID the system can find.

The Idea

Think about how you name things in code. You don't call your main entry point function_847b2c. You call it main. You don't name your config file abc123.yaml. You name it database-config.yaml. Names carry meaning. They make things easier to recall, easier to share, easier to reason about.

We wanted the same thing for memories. If a memory is important enough that you'll come back to it repeatedly — and update it as things change — it deserves a name that reflects what it is.

Named memories let you assign a human-readable name to any memory. That name becomes a stable handle: easy to remember, easy to type, easy to build into scripts and workflows. And when you update the memory, MemNexus automatically versions it and preserves the full history behind the name.

Introducing Named Memories

Starting in v1.7.30 of the CLI (SDK v1.27.0), you can give memories stable names:

# Create a named memory
mx memories create \
  --name dev-loop \
  --conversation-id NEW \
  --content "My dev workflow: 1) Write tests, 2) Implement, 3) Run CI..."

# Retrieve it by name — easy to remember, easy to type
mx memories get --name dev-loop

# Update creates a new version automatically
mx memories update \
  --name dev-loop \
  --content "Updated workflow: 1) Write tests, 2) Implement, 3) Validate OpenAPI, 4) Run CI..."

# See how it evolved
mx memories history dev-loop

The name dev-loop is yours. It always points to the latest version. And if you need to see what it said last week, the history is right there.

How Versioning Works

When you update a named memory, MemNexus doesn't overwrite the old content. Instead, it creates a new memory node, links it to the previous version with a SUPERSEDES relationship, and moves the name pointer forward. The old version stays in the graph, marked as superseded. The new version becomes the HEAD of the chain.

Here's what the chain looks like after a few updates:

v3 (HEAD) --SUPERSEDES--> v2 (superseded) --SUPERSEDES--> v1 (superseded)

Only the HEAD carries the name property, so retrieval is instant — a single indexed lookup. And if you want the history, MemNexus walks the SUPERSEDES chain backward from HEAD.

The whole operation is atomic. New node creation, relationship linking, name transfer, and state marking all happen in a single database transaction. The name pointer is never in an inconsistent state.

What It Looks Like in Practice

List Your Named Memories

See the memories you've considered important enough to name:

mx memories list --named

This is your personal index of living documents — dev runbooks, config references, project overviews. A curated set of the knowledge that matters most.

Walk the History Chain

Check how a named memory evolved over time:

mx memories history dev-loop

version  id                                     content                                            state       createdAt
v2       fb6c0649-825a-4dd7-8a67-21e249220c07   Updated workflow: 1) Write tests, 2) Implement...  HEAD       2/7/2026
v1       96991fe8-849e-4ac0-bd02-83adbfb57cd4   My dev workflow: 1) Write tests, 2) Implement...   superseded 2/5/2026

You can see exactly when the memory changed and what each version said. Useful for understanding why something evolved, or for recovering an earlier approach.

Memory Types and Defaults

Named memories default to memoryType: procedural because they're typically reference material — workflows, checklists, config docs. You can override this with --memory-type at creation time if needed.

Under the Hood

The core challenge was making name lookups instant while keeping versioning history intact. We solved it by storing the name only on the HEAD node:

1. Retrieval is a direct index lookup on the name property
2. History traversal walks the supersession chain from HEAD, up to 50 versions deep
3. Updates transfer the name atomically in a single transaction

The effectiveState property tracks whether a memory is current or superseded. This feeds into timeline search — when you reconstruct a conversation, superseded memories show up with a [SUPERSEDED] indicator so you know they've been replaced by something newer.

Design Decisions

We added --name to the existing create, get, and update commands rather than creating a separate mx memories named subcommand group. Naming is an optional enhancement to a memory, not a different kind of operation. This keeps the CLI surface simple — you learn --name once and it works everywhere.

For version history, we added mx memories history <name> as a dedicated subcommand. Inspecting a version chain is semantically different from retrieving the current memory, so it deserved its own command with a clear name.

Names are lowercase alphanumeric with optional hyphens (2-64 chars). A single word like runbook works just as well as dev-loop. Keeping names lowercase avoids casing ambiguity — there's only one way to spell it.

Use Cases

Named memories work best for knowledge that evolves and matters enough to earn a name:

• Dev loop documentation — dev-loop always has your latest build-test-deploy workflow
• Runbooks — debug-database captures your current troubleshooting steps
• Project context — auth-redesign tracks decisions as the project evolves
• Config references — rate-limit-config holds the current system parameters

Not every memory needs a name. But the ones that do become much easier to work with.

Try It Now

Named memories are available now:

• CLI: v1.7.30
• SDK: v1.27.0 (TypeScript)
• Core API: Deployed and ready

Think about the memories you keep coming back to. Give them names. Let them evolve. MemNexus will keep the history.

---

Named memories with automatic versioning are available now in MemNexus CLI v1.7.30 and TypeScript SDK v1.27.0.