SurrealDB Opens Waitlist for Auditable Agent Memory

SurrealDB has opened a waitlist for Agent Memory, a managed service designed to preserve what AI agents learn, where that information came from and how it changes. The company has published pricing, integration examples and benchmark results, though access remains limited to an early-access preview.

Agent Memory promises to retain each statement’s source, confidence, history and relationship to newer information, so developers can see whether it has been corrected. Those admitted to the service can evaluate that approach through MCP, a TypeScript SDK and a CLI.

The managed memory layer is closed source, and its production performance is not established by the preview. SurrealDB’s headline 77.2% BEAM score also comes from a company-run evaluation with non-default settings.

A Free Sandbox Still Requires Early Access

SurrealDB’s published plans provide a starting point for evaluating cost. They do not mean anyone can immediately provision the service.

The entry options listed on the product page are:

• Sandbox: Free, with no card required and a one-off allocation of 3 million tokens.
• Lite: $30 per month, including 1 million tokens each month.

Sandbox’s 3 million tokens are a trial allocation, not a recurring monthly allowance. Lite provides fewer included tokens at a time, with the allowance renewing monthly.

The advertised Sandbox includes the core memory capabilities: a knowledge graph with provenance, tri-temporal memory, hybrid vector/BM25/graph retrieval, an MCP server, the TypeScript SDK and the CLI. It is positioned as a way to evaluate the memory layer itself, rather than a stripped-down demonstration.

Developers can inspect the published interfaces, architecture and pricing while requesting access. Actual workload testing depends on admission to the waitlist-gated service. The token allowances alone do not establish an application’s running cost; that requires measuring consumption against its ingestion, retrieval and answer-generation workload.

Corrections Preserve History Instead of Overwriting It

The technical deep dive describes three basic fact types: attributes, relations and actions. These represent properties of an entity, links between entities and things an entity did.

Each fact carries provenance, including its source and confidence. A source reference can point back to a passage in a conversation or document, while an inferred fact can identify the information from which it was derived.

SurrealDB separates time into three dimensions:

• System time: When the underlying datastore changed.
• Known time: When Agent Memory learned a fact.
• Valid time: When the fact held in the world, where the source provides that information.

Learning today that someone changed employers last month is different from learning that they changed employers today. Treating both as a single timestamp loses information needed to answer historical questions.

According to SurrealDB, a correction closes the previous fact’s validity without deleting the old row. Each fact, its edges and its history are written in one transaction. Reconciliation decisions run in code, with no model making those decisions at that stage. Conflicting sources or insufficient confidence can produce explicit uncertainty records instead of silently replacing an existing value.

Repeatable reconciliation rules can still operate on incorrectly extracted facts. SurrealDB also discloses a specific limitation: entities are matched by name, so differently named references to the same entity are not automatically merged. Developers evaluating the service should test aliases and ambiguous names alongside clean examples of corrected job titles.

Seven MCP Tools Include Inspection and Forgetting

The published MCP interface exposes seven tools: remember, recall, context, reflect, forget, upload and inspect.

SurrealDB provides connection examples for Claude Desktop, Cursor and Claude Code, using an HTTP MCP endpoint with authentication and a context identifier. Developers can also use the TypeScript SDK, CLI or underlying REST surface. These interfaces offer several ways to connect an existing agent without adopting a new agent runtime.

Inspection gives developers a way to examine the product’s provenance claims. SurrealDB says writes produce decision traces, ranked reads produce retrieval traces, and chat and reflect answers produce response traces linked to the facts involved. The traces endpoint and inspect tool make those records queryable.

The company says traces live in the tenant’s database. Decision traces are retained indefinitely by default; retrieval and response traces are retained for 90 days. A separate audit-event stream can be exported through OpenTelemetry.

Those records could help developers distinguish a bad source from a reconciliation or retrieval failure. They also create information that needs its own retention policy.

The documented deletion controls distinguish between forget, which retires a fact, and purge, which removes its history as well. Forgetting alone is therefore not erasure. Developers building deletion workflows need to test the purge path instead of assuming that invoking the MCP forget tool removes historical data.

Retrieval Combines Seven Signals and Records Their Scores

SurrealDB lists seven retrieval ranking signals: vector, lexical, graph, section links, PageRank, geographic information and trace features reflecting what previously proved useful. Retrieval traces record each signal’s score, giving developers a way to inspect why an item ranked where it did.

The read path includes structured fact reads, a response cache, hybrid retrieval and an escalated fallback. Structured reads seed the ranking instead of serving as a terminal answer. When retrieval is thin or low-confidence, the fallback uses a query-rewriting approach called HyDE and doubles the candidate pool.

For repeated chat questions, SurrealDB says the system can reuse an answer while its supporting facts remain unchanged. Superseding or forgetting a cited fact invalidates that reuse.

That mechanism could reduce repeated work, though it does not demonstrate latency or cost savings for every application. An early evaluation should check whether corrections invalidate the right answers, whether retrieval finds the replacement facts and whether the resulting traces make failures understandable.

The 77.2% BEAM Score Needs Its Full Protocol

SurrealDB reports 77.2% on the full 700-question BEAM 1M set, covering 35 conversations and ten memory abilities. Its product page lists stronger results for instruction following, at 93.6%, and knowledge update, at 88.6%, alongside weaker temporal reasoning, at 65.7%, and event ordering, at 49.7%.

The company’s October 14 benchmark analysis supplies conditions that materially change how to read the headline.

The answering model was Gemini 3.8 Flash, while Gemini 3.5 Flash Lite acted as judge. SurrealDB says it used the official BEAM judge prompt, but not the judge model used in the benchmark authors’ reference code. The run gave the answering model the top 50 memories and enabled ten retrieval and chat settings that the product does not enable by default. The 77.2% score should therefore not be treated as the expected result of an untouched Sandbox configuration.

The score includes partial credit. SurrealDB separately reports a 57.1% strict score, defined as the share of questions for which every rubric item received full marks. This is a more demanding measure than the headline mean, not a conflicting result.

For event ordering, SurrealDB says it used Kendall tau to evaluate whether events appeared in the correct order. Scoring the same answers by rubric average would produce a 79.3% overall result instead of 77.2%. Merely mentioning the right events is easier than ordering them correctly.

The company says it publishes all 700 answers with their questions and rubrics, allowing others to inspect or rejudge the outputs. The harness commands, however, are not public yet. Readers can inspect more than an unexplained score, but the result remains vendor-run and has not been independently reproduced.

SurrealDB’s own analysis cautions against ranking competing systems whose published runs use different models, judges and retrieval budgets. That caution should apply to its result as well.

The Memory Layer Has Its Own Licensing Boundary

SurrealDB says the managed Agent Memory layer is closed source today. That is separate from the licensing of its underlying database and SDKs.

The company’s product information identifies the database as source-available under BSL 1.1, while SDKs use Apache 2.0 or MIT licenses. Access to database source code or permissively licensed clients does not make the managed memory implementation open source.

Developers have an opportunity to evaluate a gated managed service, not an openly available memory stack. They can assess whether its source tracking, correction rules, retrieval traces and deletion controls fit their applications, but should not infer implementation access from the database’s licensing.

The most consequential pilot would follow a fact through its entire lifecycle: ingest it, retrieve it, correct it, inspect the resulting answer, then retire and purge it. SurrealDB’s preview makes specific promises at each step. Whether those promises hold for messy application data is the question early access needs to answer.