Your API starts throwing timeouts. You ask your agent what it knows about the problem. It finds three memories about API performance. It misses the one where you tripled the Redis connection pool size last month, the memory about switching from synchronous to batched writes, and the debugging session where you traced a similar timeout to a DNS resolver change. Those memories don't mention "API timeouts" — but they're all connected to the same systems and the same infrastructure decisions.

Semantic search finds memories that use similar language. It misses memories that are connected through shared systems, decisions, and topics — even when those connections are exactly what you need.

This release changes that. Search in MemNexus now understands connections — not just meaning.

The Problem with "Similar Words Only"

When your memory store is small, semantic search feels complete. But as you save more — decisions, debugging sessions, configuration choices — gaps start to appear.

Here's what goes wrong at scale.

You miss connected memories. A search for "rate limiting" finds memories that mention rate limiting. It misses the memory about the Redis configuration that backs the rate limiter, even though that connection is recorded in your memory store. Two concepts that belong together stay separate.

Outdated information wastes your agent's time. You've saved 200 memories over a month. You changed your authentication approach three weeks in. Both the old decision and the new one show up in search results. Your agent has to reason through which one is current — burning tokens on a problem that shouldn't exist.

Getting the full picture means chaining separate calls. Your agent finds a relevant memory and then has to fetch its topics, entities, extracted facts, and relationships separately. By the time it has the complete picture, it's spent most of its context budget on retrieval plumbing instead of doing anything useful.

Digests miss key details. When you ask for a summary of a project, the synthesis omits specific facts and named systems. You get a narrative but not the specific configuration values, thresholds, or entity names that make it actionable.

You can't control the output. Results come back in relevance order only. You can't sort by recency. You can't filter out superseded work. You get what you get.

We've addressed all of this.

Search That Follows Connections

The headline improvement: search now traverses the connections between your memories, not just their text.

Every memory you save gets linked to entities (systems, technologies, people), extracted facts (structured knowledge like thresholds and configuration values), and topics (derived from content and any manual tags you add) through automatic content extraction. Those connections form a network. Until now, search didn't use that network.

A search for "rate limiting" now also finds:

Memories connected to the Redis entity — even if they never say "rate limiting"
Memories whose extracted questions and claims mention request thresholds or connection limits
Memories sharing relevant topics like infrastructure or performance

All of that surfaces in a single query, ranked together.

mx memories search --query "rate limiting"

The results now include the Redis configuration memory, the API gateway infrastructure notes, and the session store setup — not because they use the words "rate limiting," but because they're connected to the same concepts.

Each result tells you why it appeared:

mx memories search --query "rate limiting" --explain
# Result: "Redis configuration (session store)"
# Matched via: entity connection (Redis), topic overlap (rate-limiting)

You don't need the explanation every time. But when a result surprises you, it's there.

Outdated Results, Gone by Default

Your memory store evolves. You save a decision, change your mind three weeks later, and save a newer decision that supersedes the old one. Previously, search returned both. Your agent had to figure out which was current.

Now, superseded memories are excluded from results by default. You only see what's current. This builds on our narrative reconstruction work, which tracks how your understanding evolves over time.

# Current-only (default behavior)
mx memories search --query "authentication approach"

# Include historical context when you need it
mx memories search --query "authentication approach" --include-superseded true

Stale results are now excluded by default rather than mixed in with current ones. For agents working through large memory sets, that means less time spent sorting which result is actually current.

The Full Picture in One Call

Before this release, getting a complete view of a single memory required multiple round trips: fetch the memory, then its topics, entities, extracted facts, and relationships. We collapsed it into one call.

# Standard detail — memory plus everything connected to it
mx memories get <id>

# Minimal — just content and timestamps, for lightweight lookups
mx memories get <id> --detail minimal

# Full — plus conversation position and relationship previews
mx memories get <id> --detail full

Standard detail is now the default. Everything — topics, entities, extracted facts, relationships — comes back in a single response, instead of requiring a separate call for each piece.

You can also pipe search results directly into batch retrieval:

mx memories search --query "Redis infrastructure" --id-only | mx memories get --stdin

One command. Full picture for every result.

Richer Connections to Traverse

Connection-aware search depends on the connections it traverses. Alongside the search improvements in this release, we extended the extraction pipeline that builds those connections — capturing more of what's in each memory as structured facts and entities, and doing it more precisely.

The practical result: more things in your memory store are linked to more other things. Broader queries have more connections available to traverse.

Digests That Tell You What's Current

The improvements extend to mx memories digest and mx memories recap.

Synthesized digests now include the key facts extracted from source memories, the named entities involved, and a breakdown of how many source memories are current versus historical. Superseded memories are deprioritized in the synthesis automatically — the output reflects what's live, not what was true six weeks ago.

# Structured digest with facts, entities, and state breakdown
mx memories digest --query "authentication implementation" --digest-format structured

# Status report for standups
mx memories digest --query "sprint work" --recent 7d --digest-format status-report

When you ask "what happened on this project," you now get specific configuration values and system names alongside the narrative — and you know which information is current.

Sort and Filter the Way You Want

Search and list commands now support explicit sorting and state filtering across the board.

# Most recent memories first
mx memories search --query "infrastructure" --sort-by updated --order desc

# Relevance order (default)
mx memories search --query "infrastructure" --sort-by relevance

# Surface historical context
mx memories search --query "infrastructure" --include-superseded true

# List conversations sorted by most recently active
mx conversations list --recent 7d --sort-by updated --order desc

Sorting happens server-side. A query that previously fetched 200 results to sort locally now returns the top 20 in the right order directly.

How It Works

Every memory is connected to a network of entities, facts, and topics via the extraction pipeline. When you search, MemNexus runs multiple passes simultaneously — matching by meaning, by keyword, by entity connection, by topic overlap, and by the questions and claims extracted from each memory. The results from all passes are merged and ranked together into a single list.

This is why a search for "authentication" finds the token-rotation decision recorded under "security infrastructure." They're connected through shared entities and topics, even though the text doesn't overlap.

The matchedVia field in each result shows which signals contributed. It's there when you want transparency, invisible when you don't.

Under the Hood

For readers who want the implementation detail: the previous search combined two signals — vector similarity and keyword matching. We extended that with entity connections, topic co-occurrence, and the extracted questions and claims attached to each memory. The signals run in parallel and merge server-side.

Enrichment data for memory retrieval also runs in parallel server-side. The four separate queries that previously required sequential client calls now resolve simultaneously and return in a single response.

What Changed

| Before | After | |---|---| | Getting the full picture of one memory meant chaining separate lookups — the memory, then its topics, entities, facts, and relationships | One call returns all of it | | Superseded memories appeared in search results alongside current ones | Superseded memories are excluded by default |

How MemNexus Compares

Most AI memory systems use vector search, sometimes augmented with keyword matching. Connection-aware search — traversing entities and topics to find related memories — requires a knowledge graph, not just a vector store.

| Capability | MemNexus | Typical memory tools | |---|---|---| | Semantic search | Yes | Yes | | Connection-aware search | Yes | No | | Effective state filtering | Yes | No or partial | | Facts and entities in search | Yes | No or partial | | Full retrieval in one call | Yes | No |

Connection-aware search finds what similar-word search misses. For agents building understanding across a growing memory base, the difference shows up quickly.

What's Next

The next step is making relevant context available before you ask for it — surfacing the right memories at the moment they're needed, without requiring a search query. The connections are already there. The next layer uses them to anticipate what your agent needs next.

Try It Now

These improvements are live now. Update and run a broad query:

mx update
mx memories search --query "what connects to [your system]"

Try --include-superseded true to compare current results against historical ones. Run mx memories get <id> to see the full picture of any memory in a single call. Run mx memories digest --query "your project" to get a summary that includes specific facts and named systems.

The connections between your memories were already there. Search now knows how to use them.

Graph-aware search is available now in MemNexus Core API v1.47+ and CLI v1.7.50+. Update with mx update or npm install -g @memnexus-ai/cli@latest.

Ready to give your AI tools persistent memory? Get started free — setup takes under five minutes.

Correction (2026-08-05)

This post originally included several figures we could not trace to a documented measurement, and we've removed them:

A recall improvement from roughly 60% to roughly 90% on broad queries
A drop in stale search results from 15-20% down to roughly 0%
A token-cost reduction from roughly 8,000 to roughly 3,000 tokens per memory retrieval
An increase in facts extracted per memory from roughly 2 to roughly 17
An increase in precise entity extraction from roughly 12 up from a noisier 20
A claim that retrieving the full picture of one memory previously took 3-5 separate API calls

The "By the Numbers" table has been replaced with two claims you can verify yourself by running the commands in this post: retrieval now returns everything in one call instead of chaining separate lookups, and superseded memories are excluded from results by default.

One more correction, on substance rather than sourcing: earlier language in this post read as though graph traversal — following connections between memories — was the reason search results improved. It's one of several retrieval paths search now uses alongside keyword and semantic matching, and we don't have an isolated measurement of what any single path contributes. We've reworded those sections to describe what the paths do, not to credit one of them for an outcome we can't attribute.

The features described above are real and shipped as described — connection-aware search, default superseded-result filtering, and single-call retrieval all work as documented. What wasn't real was the specific numbers, and one causal claim, attached to them. We're leaving this note here rather than editing history quietly, because if we publish a claim, we want you to be able to trust it.

Your Agent Now Finds What It Missed Before