Hebbian memory for AI agents: what it is, and why it is not just vector search

TL;DR

• Most "agent memory" is retrieval: a vector database stores embeddings and returns the nearest matches, the same way every time. It does not learn from outcomes on its own (/api/overview).
• Hebbian memory adds an association layer on top of that retrieval: concepts recalled together strengthen their link, so a later query can expand to related concepts — "timeout" to "retry" and "backoff" (/api/getting-started).
• Feedback closes the loop. Reporting whether a result helped updates the memory's valence and strengthens associations, so use changes future use (/api/getting-started).
• Evaluation is reported on LoCoMo and LongMemEval, with live numbers on the benchmarks page rather than fixed here (/technology/benchmarks).

When an agent retrieves a memory, acts on it, and fails, a plain vector database is unchanged. The next time the agent meets the same context, it retrieves the same memory and tends to repeat the same failure. Storage remembered the text; nothing learned from the outcome.

That gap is what "Hebbian memory" addresses. Hebbian memory is an engineering approach to agent memory where concepts recalled together strengthen their association, so future reads can surface related concepts and feedback can tune what gets recalled next. In Mnemoverse's published API, that learning layer sits on top of retrieval rather than replacing it. The overview states the core model directly: Hebbian associations that strengthen when concepts are recalled together, plus a prediction-error update on outcome feedback — a delta rule in the spirit of Rescorla-Wagner — not a system defined only by vector embeddings and cosine similarity (/api/overview).

The distinction matters because retrieval is only the first step. As the overview puts it, a vector database does static similarity retrieval "the same way every time," and Mnemoverse "adds a learning layer on top of retrieval." Retrieval is the floor, not the whole system (/api/overview).

What Hebbian memory means in practice

The short version of the Hebbian idea goes back to Donald Hebb (1949): when two units are repeatedly co-active, the connection between them strengthens — later summarized as "neurons that fire together wire together." Here that is an engineering rule, not a claim of biological fidelity. When two concepts are recalled in the same context, the edge between them strengthens; later, recalling one helps surface the other (/api/overview).

That makes agent memory behave differently from a static nearest-neighbor lookup. A query is no longer limited to the exact words, or the closest embedding neighborhood, that happened to be stored earlier. It can also follow learned concept links. The published docs describe these associations as a three-factor Hebbian graph — the third factor being the outcome signal from feedback, which gates how much an edge strengthens — and the practical implication is simple: query expansion can happen automatically through learned associations, instead of requiring manual synonym lists or custom retrieval logic (/api/overview).

The association layer stays separate from the embedding space. Retrieval still begins with vector similarity; the results are then re-ranked and expanded according to learned connections.

Hebbian memory vs vector database retrieval

A vector database is a retrieval system that stores embeddings and returns items by similarity, usually cosine similarity. In the framing published in the overview, that retrieval is static unless another system around it changes the behavior.

The difference is clearest side by side (/api/overview):

Capability	Hebbian memory	Vector database
Core model	Hebbian associations + prediction-error feedback (Rescorla-Wagner-style)	Vector embeddings (cosine)
Learns from outcomes	Yes — feedback updates valence	No — static retrieval
Concept associations	Three-factor Hebbian graph	None or manual
Query expansion	Automatic via learned associations	Manual or none
Adaptation over time	Edges and valence change with use	Unchanged
Retrieval role	The floor, not the whole system	The entire system

This is why "agent memory" can be a misleading label. A vector index may be part of the stack, but if the system never strengthens connections, never adjusts ranking by outcome, and never expands queries through learned associations, it is still retrieval-first and learning-light. That does not make vector search useless — it is the baseline capability, the floor.

How Hebbian query expansion works

Query expansion is broadening a query with related concepts so recall is not limited to the exact phrasing of the request.

In the published examples, a query about "timeout" expands to related concepts such as "retry" and "backoff," and those terms appear in expanded_concepts (/api/getting-started). That matters because the useful memory is often adjacent to the words in the prompt, not identical to them. An operator may ask how to handle timeouts; the memory that helps may be about exponential backoff or a related failure pattern. Static similarity can miss some of that, and learned associations give the read path another route. The SDK describes read concisely as semantic search plus Hebbian expansion (/api/python-sdk).

How feedback changes memory

Feedback is the step where the system learns whether a recalled memory actually helped. In the API, memory_feedback changes three things: it updates the memory's valence (the outcome polarity that raises or lowers future ranking); it strengthens Hebbian edges between concepts, so "timeout" and "retry" become more associated; and it creates co-activation links between the concepts in the query and the concepts in the result. Over time, that is how the system learns which memories tend to be useful for which queries (/api/getting-started).

This is the behavioral break from plain retrieval. In a vector database, a successful outcome does not by itself alter the conceptual structure of memory. In a Hebbian memory loop, use changes future use. Part of that state is observable: memory stats expose a hebbian_edges count, a visible signal that associations grow with use (/api/getting-started).

The write, read, feedback, consolidate lifecycle

The shipped lifecycle has four stages (/api/overview):

1. Write — an importance gate filters noise, then the memory is stored with an embedding.
2. Read — Hebbian expansion broadens the query, valence influences ranking, and results are returned.
3. Feedback — the reported outcome updates valence and strengthens associations.
4. Consolidate — HDBSCAN, a density-based clustering algorithm, groups similar memories into prototypes plus singletons, so the store does not accumulate forever.

That cycle is a better mental model than "store and search." It explains why the system can improve with use, and it keeps the claim bounded: retrieval remains part of the design, with learning on top. The loop is shipped today; no planned feature is required to use it.

Here is the published Python example (/api/getting-started):

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

# Store a memory, with the concepts it should associate
client.write(
    "Retry with exponential backoff fixed the timeout issue",
    concepts=["retry", "backoff", "timeout"],
)

# Query — Hebbian associations expand "timeout" → "backoff", "retry"
memories = client.read("how to handle timeouts?")

# Report the outcome — the system learns what works
client.feedback(
    atom_ids=[item.atom_id for item in memories.items],
    outcome=1.0,  # -1.0 (failure) to +1.0 (success)
    query_concepts=memories.query_concepts,
)

The example is small, but it captures the loop. You write a memory, read against it, then report whether the result helped. The system does not just return data; it updates what future recall should prefer.

Benchmarks: where the current numbers live

Mnemoverse reports evaluation on LoCoMo (1,986 questions) and LongMemEval — external benchmarks for long-conversation and long-term agent memory. Current scores are maintained on the benchmarks page rather than fixed in this article, because benchmark results are configuration-dependent and change with re-runs and methodology updates (/technology/benchmarks). For engineering context on operating memory at scale, see building memory that scales.

Common questions

What is Hebbian memory for an AI agent?

Hebbian memory for an AI agent is an association-based layer on top of retrieval: concepts recalled together strengthen their connection, so later queries can surface related concepts instead of relying only on static similarity search.

How is Hebbian memory different from a vector database?

A vector database does static similarity retrieval with embeddings and cosine similarity, returning results the same way each time. Hebbian memory adds a learning layer: automatic query expansion through learned associations and feedback that changes future ranking.

How does query expansion work in Hebbian memory?

On read, learned associations automatically expand the query to related concepts. In the published examples, a query about "timeout" can expand to include "retry" and "backoff" through expanded_concepts.

What does feedback change in Hebbian memory?

Feedback updates a memory's valence, strengthens Hebbian edges between concepts, and creates co-activation links between query and result concepts. Over time that changes which memories surface for which queries.

How do you use Hebbian memory in the API?

The loop is write, read, feedback: store a memory, query it, then report whether the result helped. The getting-started flow uses write, read, and feedback to show the system learning from use.

Which benchmarks evaluate Hebbian agent memory?

Mnemoverse reports evaluation on LoCoMo (1,986 questions) and LongMemEval. Current results are published on the benchmarks page, because they are configuration-dependent and change with re-runs.

The distinguishing question for an agent memory system is not whether retrieval exists. It is whether the memory changes after use. In Mnemoverse's published model, Hebbian associations, valence updates, and feedback-driven recall are the mechanisms that make memory adaptive rather than static.

Related

• Memory that learns and forgets — the core model
• Getting started — the write / read / feedback walkthrough
• Python SDK — read as semantic search plus Hebbian expansion
• Benchmarks — LoCoMo and LongMemEval results
• Hopfield associative memory — the associative-memory science lineage
• Building memory that scales — scale framing

— Edward Izgorodin · Last updated 2026-06-18