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 extracted facts — 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 costs five API 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). 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 facts 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. Search recall on broad queries went from roughly 60% to roughly 90%.

Each result tells you why it appeared:

mx memories search --query "rate limiting" --explain
# Result: "Redis configuration (session store)"
# Matched via: entity connection (Redis), extracted fact (100 req/min per key)

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.

# 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

The share of stale results in a typical search dropped from 15-20% to effectively zero. For agents working through large memory sets, that's a meaningful reduction in reasoning overhead.

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. That pattern consumed roughly 8,000 tokens of context before your agent could do anything useful with the information.

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. Context per retrieval dropped from roughly 8,000 tokens to roughly 3,000 tokens. For agents working through a list of relevant memories, that difference compounds quickly.

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 Mean Better Search

The quality of connection-aware search depends on the quality of connections. Before shipping the search improvements, we deepened the extraction pipeline substantially.

In our tests, facts extracted per memory went from roughly 2 to roughly 17. Entities are cleaner: roughly 12 precise extractions instead of 20 noisy ones. The connections that search now traverses are more numerous and more accurate than before.

The practical result: more things in your memory store are linked to more other things. Broader queries surface more relevant results because there's more to find.

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 extracted fact content. The results from all passes are merged and ranked together into a single list.

This is why a search for "authentication" finds the JWT signing key memory stored 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 to five independent signals, adding entity connections, topic co-occurrence, and extracted fact matching. All five run in parallel and merge server-side. Search response times stay in the 50-70ms range — adding three new signals added no meaningful latency.

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.

By the Numbers

| What changed | Before | After | |---|---|---| | API calls to get the full picture of one memory | 3-5 | 1 | | Search recall on broad queries | ~60% | ~90% | | Stale results in a typical search | 15-20% | ~0% | | Context tokens per memory retrieval | ~8,000 | ~3,000 | | Facts extracted per memory | ~2 | ~17 |

How MemNexus Compares

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

| Capability | MemNexus | Mem0 | Zep | LangMem | |---|---|---|---|---| | Semantic search | Yes | Yes | Yes | Yes | | Connection-aware search | Yes | No | No | No | | Effective state filtering | Yes | No | Partial | No | | Facts and entities in search | Yes | No | Partial | No | | Full retrieval in one call | Yes | No | No | 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.

Your Agent Now Finds What It Missed Before