An agent without durable memory cannot build on prior conversations. Every new session starts cold: the agent cannot personalise responses, cannot build on prior decisions, and cannot recognise that it has been asked the same question before. This page explains why memory matters, and why the most common shortcuts are insufficient.
The bar: how people remember
People rarely "search their transcript". Instead, we generally use the following to learn and remember:
Association (seeing the word "cat" pulls up pets, lions, teams, stories)
Beliefs are given timestamps and scope ("I have one now", "I saw one yesterday", "I used to years ago, but no longer").
General facts are derived from experience ("they weigh about four kilos in general")
SurrealDB Agent Memory is built to that shape: a graph of entities and relations for association, six experiential categories for what kind of thing was learnt, and tri-temporal fields so present, past, and general facts do not collapse into one undated chunk. The implementation is precise - provenance, scopes, reconcilers - but the aim is simple: memory an engineer can explain, and an agent can query.
What happens without memory
Context loss across sessions
Each conversation turn exists in isolation. The moment a session ends, everything learnt is discarded. If someone told the agent their preferred time zone last Tuesday, the agent asks again on Wednesday. If a support agent resolved a billing issue in March, the agent in April has no record of it.
Within a session the context window compounds the problem. As conversations grow, earlier turns are truncated or summarised to fit the model's token limit, so even intra-session memory fades.
No personalisation
Personalisation requires knowing things about the person: their role, their preferences, their history with the product, their current project. Without persistent memory, every response must be generic. The agent cannot adapt tone, skip explanations the user has already heard, or surface information relevant to their specific situation.
No learning from past interactions
When an agent makes a mistake - misunderstands a user's intent, applies the wrong policy, gives outdated information - there is no durable record of the correction, so the same failure can recur in the next session.
For agentic workflows that run autonomously over long periods, this is especially costly. An agent executing a multi-step research task cannot resume where it left off if the session is interrupted. An agent coordinating with other agents cannot rely on a shared understanding of what has already been done.
Why a vector store is not enough
A common response is to embed past interactions and retrieve similar chunks at query time. While better than nothing, it has structural limitations that prevent it from serving as a genuine memory layer.
No structure, no verifiability
With vector stores alone, memory is text chunks. Retrieval returns the chunks most similar to the query. There is no entity model - no concept of "user", "project", or "preference". There is no way to ask "what is Christian's current role?" and get a direct answer; instead, you get chunks that mention Christian and hope the right one surfaces.
There is also no way to inspect what the system "knows" in any meaningful sense. As the store is an opaque cloud of embeddings, checking correctness means re-running queries and reading the outputs.
No provenance
Which conversation produced a given chunk? When was it captured? Has the underlying fact since been corrected? A vector store has no answers. Retrieved context may be outdated, contradictory, or sourced from an unreliable turn, and there is no field that says so.
No correction tracking
When someone corrects the agent ("actually, I switched roles in January") the store cannot reconcile this with prior data. Both the old and new statements exist as equal-weight chunks. Future retrieval may return either one, or both, and the model has to guess which is current. There is no supersession, no temporal ordering of facts, and no way to mark old information as invalid.
No temporal validity
Facts have no reliable lifespan in storage. A current project is not the same as the project six months ago. A pricing policy changes. An employee changes teams. Without valid_from and valid_until on stored facts, stale data sits next to current data, and retrieval cannot tell them apart.
Retrieval is a guess
Semantic similarity is not the same as relevance. A chunk retrieved because it is textually similar to a query may not be factually relevant. High-similarity matches can be coincidental; low-similarity matches may be the ones you need. Ranking by cosine distance alone is a weak strategy for factual queries.
What structured memory provides
SurrealDB Agent Memory addresses each of these gaps:
| Problem | SurrealDB Agent Memory's approach |
|---|---|
| No structure | Extracted entities, attributes, and relations stored as a queryable graph in SurrealDB |
| No provenance | Every record carries a source object (kind, ref, spans, trust, derivation); see Provenance and traceability |
| No correction tracking | Supersession chains plus explicit uncertainty for cross-provenance clashes |
| No temporal validity | Tri-temporal model (system, known, and valid time) |
| No verifiability | Traces (retrieval_trace, decision_trace, response_trace) as substrate nodes, not disposable logs |
| Unreliable retrieval | Hybrid structural retrieval plus tiered resolution |
The result is a memory layer you can trust: correctness can be demonstrated, not just assumed. See The accuracy promise for how that works in practice.
Agent memory should not be a cache
Many "memory" products are really caches: store an output, retrieve something similar later. A cache can tell you what was returned last time, but cannot reliably tell you what the agent believed at the time, why that belief changed, or which source contradicted which.
SurrealDB Agent Memory is built as state management first and retrieval second. Embedding-and-ranking finds candidates; supersession, provenance, and traces keep a current view of the world as it changes.
Long sessions and context limits
Even within a single session, context windows force truncation or compaction. If durable memory only lives in the transcript, anything not carried forward in the summary is gone when the session ends.
SurrealDB Agent Memory extracts and reconciles important facts into structured memory as turns arrive, runs consolidation and elaboration between interactions, and keeps the full episodic record citeable via provenance - so you are not betting everything on one compaction at the right moment. See Supersession, decay, and forget.