Mnemoverse Docs

Appearance

Edward Izgorodin·Published Jun 18, 2026

Is Mnemoverse a vector database, or a memory layer on top of retrieval? ​

TL;DR ​

  • No. A vector database does static similarity retrieval. Mnemoverse adds a learning layer on top of retrieval, as described in the public API overview.
  • Mnemoverse changes what comes back next time: it expands queries through Hebbian associations and updates memory valence from outcome feedback, so useful memories rank higher on later reads (overview, getting started, Python SDK).
  • It treats memory as a lifecycle, not a fixed store: write → read → feedback → consolidate — "memory that learns and forgets" (/api/overview).
  • The two are complementary, not rivals: Mnemoverse can sit on top of an embedding-based retriever. Retrieval is the floor; the question is whether your agent needs retrieval alone or memory that adapts after use.

A vector database is a system for static similarity retrieval: you store embeddings and get back the nearest matches, the same way every time for the same stored state. Mnemoverse is a memory layer on top of retrieval that learns from outcomes, expands recall to related concepts, grades recall by recency, and consolidates similar memories over time, per the public overview.

That difference matters because agents do more than search. They act, succeed, fail, and repeat. A retrieval system can return relevant text; a memory system should also change after the result is used.

What a vector database actually does ​

A vector database indexes high-dimensional embeddings and returns the items whose vectors are closest to a query vector, usually by cosine similarity. With respect to the stored embeddings and the distance function, the operation is deterministic: no state changes as a result of retrieval.

That design is a real and useful capability — it powers search, recommendation, and retrieval-augmented generation, where the goal is to surface relevant static content. What the retrieval layer does not do on its own is track whether the returned items helped or hurt, form new connections between concepts, or change importance based on recency or success.

Vector database vs Mnemoverse ​

The public API overview states the distinction directly: a vector database does static similarity retrieval, while Mnemoverse adds a learning layer on top of retrieval. The docs name two mechanisms in that layer — Hebbian associations that expand a query to related concepts, and a prediction-error feedback signal (described as Rescorla-Wagner-style) that updates each memory's valence so memories that led to good outcomes rank higher next time. The overview's own summary is the right one: retrieval is the floor, not the whole system.

This is not an argument against embeddings or semantic search — Mnemoverse still uses semantic similarity for first-pass recall. The claim is narrower and more useful: retrieval alone is not the same thing as memory.

MnemoverseVector database
Retrievalsemantic similarity (the floor)semantic similarity (the whole system)
Learns from outcomesyes — feedback updates valencenot inherent to retrieval; added externally if at all
Query expansionHebbian associations → related conceptsnot inherent (exact nearest neighbors)
Recency / forgettingrecall graded by recency; consolidationnot inherent (store stays as-is)

Adapted from the overview. "Not inherent" means the retrieval layer itself does not do this — you would bolt on a separate system. One layer retrieves; the other retrieves, then learns.

How repeated failure reveals the gap ​

The cleanest way to see the difference is a loop that fails. The public Hebbian article states it directly:

When an agent retrieves a memory, acts on it, and fails, a plain vector database is unchanged. The next time […] it retrieves the same memory and tends to repeat the same failure. Storage remembered the text; nothing learned from the outcome. — Hebbian memory for AI agents

A static store can preserve information; it cannot, on its own, learn that one memory keeps producing bad outcomes while another keeps helping. Mnemoverse records the outcome: the failed memory's valence drops, and the next read surfaces alternatives or expands to related concepts. The failure changes future behavior instead of repeating.

That is why Mnemoverse documents a full lifecycle in the overview: write → read → feedback → consolidate. Feedback is where memory updates; consolidate is where similar memories cluster and merge. The overview page is titled "Memory That Learns and Forgets." (For why retrieval alone becomes insufficient as systems grow, see building memory that scales.)

Mnemoverse learns from outcomes ​

The "not a vector database" claim rests on one concrete behavior: the system changes after use. The Python SDK and getting started guide show it in API terms — you read memories, then report what happened, and that feedback updates valence, which affects later ranking.

python
from mnemoverse import MnemoClient
client = MnemoClient(api_key="mk_live_YOUR_KEY")

# A vector DB returns the same nearest matches for the same stored state.
memories = client.read("how to handle timeouts?")

# Mnemoverse adds the step a vector DB has no place for: report what happened.
# A Rescorla-Wagner-style update nudges valence, so good memories rank higher next time.
client.feedback(
    atom_ids=[item.atom_id for item in memories.items],
    outcome=1.0,            # -1.0 (failure) … +1.0 (success)
    query_concepts=memories.query_concepts,
)

That extra step is not a cosmetic API wrapper — it is the memory behavior. The two mechanisms stay separate in the public docs, and each has its own deep-dive:

Observable evidence of the learning layer ​

When you read from Mnemoverse you get more than a ranked list. The documented response surfaces:

  • expanded_concepts — the related concepts the read broadened the query to (getting started)
  • hebbian_edges — the association links that grew with use, visible in memory stats (getting started)
  • avg_valence — the outcome-derived score visible in stats (getting started, Python SDK)

These fields are not native to standard nearest-neighbor retrieval semantics: plain similarity search has no concept of associations formed over time or valence updated from external outcomes. Their presence is a visible signal that a learning layer is active — observable state a static store does not carry.

Do you still need a vector database? ​

Sometimes, yes. Mnemoverse does not replace embedding-and-similarity infrastructure; it builds on it. The first-pass recall is still semantic similarity. For purely static lookup — "store embeddings, retrieve nearest matches" — a vector database is the right tool, and Mnemoverse's own docs call similarity the floor.

The better question is what happens after retrieval. If you do not need the system to change based on outcome, a vector database may be enough. If you do — learning from feedback, associative query expansion, recency-graded recall, consolidation over time — you need a memory layer, and that is where Mnemoverse sits. The value shows up on the second, third, and hundredth interaction with the same domain. "Just use a vector DB" and "use a memory API" are adjacent problems at different layers, not the same choice.

For public performance numbers, use the benchmarks page directly; this article stays with the architectural distinction.

Common questions ​

Is Mnemoverse a vector database? ​

No. A vector database does static similarity retrieval. Mnemoverse adds a learning layer on top of retrieval: Hebbian associations expand queries, outcome feedback updates memory valence, recall is graded by recency, and similar memories consolidate. Source: /api/overview.

What is the difference between Mnemoverse and a vector database? ​

Retrieval is the whole system in a vector database, but only the floor in Mnemoverse. Mnemoverse still uses semantic similarity for first-pass recall, then changes what ranks next time based on feedback and associations. Source: /api/overview.

Does Mnemoverse still use vector search or embeddings? ​

Yes. The public docs call semantic similarity the floor. The point is not to replace retrieval but to add a memory layer on top of it; Mnemoverse can sit on top of an embedding-based retriever. Source: /api/overview and /api/python-sdk.

Why is static similarity retrieval not enough for agent memory? ​

Because retrieval alone does not learn from outcomes. The Hebbian article gives the failure mode: an agent can retrieve a memory, act on it, fail, and then retrieve the same memory again because the store itself did not change. Source: /library/hebbian-memory-for-ai-agents.

How does Mnemoverse learn and forget? ​

Its public lifecycle is write → read → feedback → consolidate. Feedback updates valence and strengthens Hebbian links; recall fades by recency and similar memories consolidate. Source: /api/overview.

When should you choose a vector database instead? ​

When the job is repeatable nearest-neighbor lookup over static content. Choose a memory layer when the system must improve over repeated interactions through outcome feedback and consolidation.

Retrieval is still necessary — it just is not sufficient if you want memory that changes after experience. A vector database gives you search over stored representations; Mnemoverse adds the layer that lets an agent learn what helped, down-rank what failed, connect related concepts, and stop treating all stored text as equally alive forever.

— Edward Izgorodin · Mnemoverse Library · Last updated 2026-06-18