SurrealDB is a Rust multi-model database and context layer for AI agents: documents, graphs, vectors, time-series, and relations are native in one ACID engine, no stitched stores. Query with SurrealQL, connect via MCP, WebSocket, and SDKs, with GraphQL generated from your schema. Built-in auth, permissions, HTTP APIs, and live queries reduce separate backend glue. Runs embedded, at the edge, or as a highly-scalable cluster in the cloud. Same engine, everywhere.
This is the 2nd launch from SurrealDB. View more
Spectron
Launching today
Spectron is agent memory built on one ACID substrate. Graph, vectors, documents, and structured rows commit in one transaction. Every fact carries provenance. Corrections supersede, never overwrite. Hybrid retrieval fuses vectors, graph, BM25, and keywords. Traces feed back into ranking. Tri-temporal facts, multi-tenant scopes, and MCP support. No stitched stores. No sync pipelines.
Payment Required
Launch Team
"Corrections supersede, never overwrite" and tri-temporal facts, this is the part agent memory systems usually
get badly wrong. Most just rewrite the latest version and lose the trail of why the change happened.
In Priowise I keep wanting a memory layer that lets me ask "why did the score for this decision change between
v1 and v2 of the analysis", and getting nothing useful from the storage layer. Spectron's provenance + supersession model looks like the missing piece.
Going to look at this more carefully. Congrats on the launch.
SurrealDB
Yep, exactly. Rewriting the latest value loses the useful part.
For this to work properly, corrections need to be stored as new facts that supersede earlier ones, not overwrite them. Then you can query the chain and see what changed, when it changed, and which source or event caused the change.
This is a great example of the kind of thing Spectron should make much easier to model.
SurrealDB
This is the exact shape of problem we built for, @erginmurat , and your v1-vs-v2 score example is the perfect test of it.
The reason most storage layers can't answer "why did the score change" is that the v1 score and the v2 score are the same field overwritten, so the v1 state and the reason it moved are both already gone by the time you ask. In Spectron the v1 belief is still there with its validity bounded in time, the v2 belief supersedes it, and the two are linked in a chain you can walk. So "what was the score at v1, what is it at v2" is a temporal query, not an archaeological search.
The part I think you're really reaching for is the "why," and that's where the trace graph comes in: the decision that produced the new score is itself a stored node, linked to the facts it superseded and the source or event that triggered it. So you don't just see that the score changed between v1 and v2; you can walk from the new value back to the prior one, to the decision that changed it, to the input that caused the decision, and perhaps to previous responses given to a similar question asked previously. That is the bit that's usually missing.
Would genuinely love to hear how it maps onto Priowise in due course. That decision-provenance use case is right in the centre of what we care about.
@tobiemh This is exactly the architecture I've been hand-rolling in Priowise. The pipeline produces strategic analysis through several stages, and downstream stages depend on outputs of upstream ones. When a single stage produces revised output (different framing, different scoring rationale, different competitor analysis), I lose the trail of WHY the revision happened, was it new input,
a different prompt, a re-ranking, or just stochastic variance? Right now I store the latest version and let
the prior one disappear.
The chain-walk you're describing — value → decision → input → prior responses, is what I keep trying to reconstruct from logs after the fact, I believe. The tri-temporal piece especially: founders using Priowise will eventually need to ask "the system recommended X direction last quarter, what changed in the inputs that made it recommend Y now?" That's a temporal provenance query, not an archaeological one. Pretending otherwise has been my main source of weekend rebuilds.
Would love to talk about how Spectron handles the case where the upstream input itself was an AI output (so the "event that caused the decision" is itself a probabilistic node, not a deterministic one). That's the part of agent memory I haven't found a clean answer for.
Will DM you when launch dust settles.
SurrealDB
@erginmurat this is the most interesting part because it's where "memory" stops being storage and starts being epistemics.
The short version: an AI output as an upstream input isn't an edge case in Spectron, it's a first-class source kind. Facts minted by a model (reflection, elaboration, consolidation) are stored with their own provenance, a derived_from link to the inputs they were synthesised from, and a deliberately lower trust prior than a human turn or an authoritative document. So a probabilistic node is recorded as probabilistic; it never gets laundered into looking like ground truth just because it became an input downstream.
Two things follow from that. First, the chain-walk is recursive, not flat: derived_from is a graph edge, so when you walk back to "the event that caused this decision" and that event is itself a model output, you keep walking, into the inputs and the model call that produced it, each node carrying its own trust and confidence. The probabilistic origin is visible at every hop rather than collapsing into a single deterministic "an input happened".
Second, this is exactly what lets you answer your earlier new-input vs re-ranking vs stochastic-variance question. Every trace records both the model (and provider, version) and the retrieval candidate set it was given. So to diff two revisions you compare the inputs each decision actually saw: if the considered facts changed, the inputs moved; if the inputs are identical and only the generation differs, that's the model wandering, not the data. "Did the recommendation change because the inputs changed or because the model rolled differently" becomes a query over two trace nodes, not a guess.
And confidence is tracked separately from trust, so a low-confidence model output doesn't get to silently supersede a higher-confidence belief; below the floor it surfaces as explicit uncertainty instead. That keeps a probabilistic upstream from quietly corrupting the chain it feeds.
Please do DM when the dust settles. The "input is itself a probabilistic node" problem is right at the centre of what we think agent memory has to get right, and I'd love to go deeper on how it maps onto the Priowise pipeline.
AISA AI Skills Test
the provenance piece is what makes this interesting to me. most agent memory solutions treat it like a cache — store the output, retrieve it later. but if corrections supersede instead of overwriting, you actually get an audit trail of what the agent "believed" at each point. thats a much harder problem than just fast retrieval, and its the part most teams skip until something breaks in production.
SurrealDB
@ozandag Fast retrieval is only useful if you can trust what comes back.
That's one of Spectron's core advantages. Memory should not just persist outputs, it should preserve what changed, what was superseded, and why, so you can inspect the state of knowledge at any point instead of only seeing the latest version.
That audit trail becomes pretty important once agents move beyond demos and into production, all thanks to Surreal's temporal capabilities.
SurrealDB
Absolutely @ozandag ! The "what did the agent believe at each point" framing is exactly it. A cache can only ever tell you what it answered; it can't tell you what it knew at the time or why. Once corrections supersede instead of overwrite, "what did it believe on the 3rd, and what changed by the 10th" becomes a query rather than a forensic reconstruction from logs. And you're right that it's the unglamorous part teams skip, precisely because it costs nothing until the day it costs everything. Thanks @ozandag , this is a great take on it.
Congrats on the launch! The "trust" framing is exactly the right angle for agent memory — most solutions focus on recall accuracy but ignore the harder problem: when should the agent forget or deprioritize stale context?
Curious how Spectron handles the case where a user's preference changes over time. For example, if I told my agent to "always use formal tone" 3 months ago but now prefer casual — does the memory layer surface the conflict, override silently, or let the agent decide?
That edge case tends to determine whether power users stick long-term.
SurrealDB
Great question, @grace_lee26, and you've put your finger on the part that matters: not recall, but knowing when something is stale.
The short version for your formal-to-casual example: the new preference doesn't silently overwrite the old one, and it doesn't get left for the agent to untangle at runtime. It supersedes. The "always formal" instruction stays in the substrate with its validity bounded in time, the "prefer casual" instruction becomes the current one, and the two sit in a chain you can walk. So the agent behaves casually now, but you can still ask "what was my tone preference in March, and when did it change" and get a real answer.
The reason we lean on supersession rather than a silent overwrite is exactly your stick-long-term point: a preference that flips and erases its own history is impossible to debug or trust later. Keeping the chain means the change is visible and auditable, while the agent still only ever acts on what's current.
The one place it becomes an explicit, surfaced conflict rather than a clean supersession is when sources of different kinds disagree, say an uploaded document asserting one thing and your own words asserting another. Two statements from you over time are read as you changing your mind, which is a supersession, not a contradiction to flag.
SurrealDB
That's exactly the part we think is actually the hard problem too, @zaid_mallik1. Retrieval is the table stakes; deciding what to demote and what to drop is where memory systems live or die.
On your specific example: an updated preference is treated as a replacement of state, not just another memory thrown into the ranking pool. When the new preference supersedes the old one, the prior belief gets its validity bounded in time and the new one becomes current. So "what is the preference now" has one unambiguous answer (you don't get two competing preferences fighting it out at rank time), but the old preference isn't deleted; it stays queryable as history, so you can still ask what it was last month and when it changed. That's the bit pure-overwrite systems lose and pure-append systems turn into a ranking guess.
The "what should stop being remembered" question is handled separately, and deliberately so. Every memory carries an importance that decays on a schedule tuned per category: ephemeral context fades fast, learned knowledge fades slowly, core identity doesn't decay at all. Crucially, decay isn't blind: when a memory actually gets used in a retrieval it gets reinforced, its importance bumped back up. So the things that keep proving useful stay sharp and the things nothing ever touches quietly fade out of the active set, without being destroyed. On top of that, explicit forget exists for the cases where something genuinely needs to be gone.
So three different mechanisms for three different questions: supersession for "this replaced that," decay-with-reinforcement for "this stopped being relevant," and forget for "this should not exist." Conflating them into one delete is, I think, exactly why this tends to go wrong elsewhere.
@tobiemh That distinction between supersession, decay, and explicit forgetting resonates a lot.
One thing we've been debating is whether those mechanisms should be owned by the memory system itself or emerge from the agent workflows sitting on top of it.
For example, should the memory layer decide that a preference has been superseded, or should that come from higher-level signals generated by the agent's actions and outcomes?
My intuition is that a lot of "memory" problems are actually state-management problems disguised as retrieval problems.
SurrealDB
@zaid_mallik1 your last line is the whole thesis: most "memory" problems are state-management problems wearing a retrieval costume. The industry reached for vector search because it was the available hammer, but embedding-and-ranking is how you find things, not how you keep a correct current view of the world as it changes.
On the ownership question, I'd actually push back on the either/or, and the way I'd argue it is from how humans do it. We don't hold everything purely in our heads and then forget it, and we don't shove everything into documents and stop remembering. We do both. I remember that we decided the system should look a certain way, and that decision also lives in a design doc, a brief, a config file. The internal memory and the external artefact reinforce each other: the doc is the durable, sharable record, and my memory is the living, revising model that knows why it says what it says. When they drift apart, that gap is itself information.
So memory should live in both places, and the job of the layer is to keep them coherent rather than to pick one. In Spectron the agent's lived experience (what it did, what worked, what got corrected) feeds in as experiential memory and as trace signals, while design docs, configs, and briefs ingest as authoritative sources, and both flow through the same reconciler. The mechanism and the guarantees (supersession, the confidence floor, decay, the chain you can walk) are owned by the memory system, because the moment each workflow hand-rolls its own "is this superseded" logic you get N inconsistent copies that collide the instant two agents share state. But the signals that drive those mechanisms come from the agent's actions and outcomes, exactly as you'd want.
And this is where it really matters for organisations: when a memory affects reasoning, knowledge, understanding, or the response an agent gives, it cannot live only in one agent's head or one person's local notes. It has to sit in a central, shared place, or every agent and person ends up carrying their own slightly-wrong copy and the org slowly disagrees with itself. That is the entire reason a memory layer exists rather than just better per-agent context: the shared, reconciled, queryable recollection is the product - and it's why we made collective memory in Spectron a primary part of the design.
There's a deliberate seam for your underlying worry too. When the system genuinely cannot decide (a cross-provenance contradiction, a change below the confidence floor) it does not silently pick; it records explicit uncertainty and surfaces it for the agent or a higher-level policy to resolve. So it's never "the memory layer unilaterally overruled you." It owns the bookkeeping and the guarantees; the workflow owns the judgement calls the bookkeeping can't make alone. Same as you and your design docs.
@tobiemh That framing around shared, reconciled memory versus per-agent context is probably the part that resonates most.
The "when they drift apart, that gap is information" point is especially interesting because most systems seem designed to hide those inconsistencies rather than surface them.
Makes sense why you ended up treating memory as a first-class system rather than another retrieval layer.
We've been exploring similar problems while building agent workflows and keep running into the same retrieval vs state-management distinction.
Sounds amazing, I was already in the process of designing a similar memory layer on top of SurrealDB for my project where I need agents to remember same as humans do but then saw this was getting out soon. I am eagerly awaiting access so I can start testing implementation with Spectron.
Watching the promo video and reading through the docs I see that's exactly I was trying to achieve, structured memory data, all timestamped so agents do reason through time which is highly important for my product.
SurrealDB has already been my go-to database for all my projects for quite some time, love the experience using it and been making lots of projects on top of it, amazing work what this team has accomplished.
SurrealDB
This is one of my favourite kinds of comment to get, @msanchezdev, thank you. The fact that you were already building this on SurrealDB yourself tells me we were thinking about it the same way: agents should remember the way humans do, and that means structured, timestamped memory you can actually reason through over time rather than a flat log.
That "reason through time" point is exactly the part we obsessed over, so it's great to hear it's landing with someone who needs it for a real product. Hopefully Spectron saves you building the layer yourself, and you can spend that effort elsewhere.
And genuinely, thank you for being a long-time SurrealDB user; that loyalty means a lot to the whole team 💜. Get yourself on the waitlist and we'll make sure you're in early. Would love to hear how it holds up against what you had in mind 🎉.
SurrealDB
Spectron is our memory and knowledge layer for AI agents, built on top of SurrealDB. The idea is to give agents reliable, shared memory that can work across your stack, tools, and applications, rather than having context scattered across separate systems.
It comes with integrations and SDKs for TypeScript, JavaScript, Python, Swift, Kotlin, LangChain, LangGraph, n8n, and a growing set of MCP server integrations that work with tools like Claude, Codex, Cursor, and more out of the box.
What makes Spectron especially powerful is its focus on authoritative knowledge. It is designed to help agents understand what they know, where that knowledge came from, how it has changed over time, and whether an answer is grounded in the underlying data.
So whether you are building internal agents, customer-facing AI apps, or developer tooling, Spectron gives you a trusted memory layer that can grow with your ecosystem.
SurrealDB
Well put, @at_chiru 🙌
The line I'd underline for anyone skimming is "whether an answer is grounded in the underlying data". That's the part most memory layers quietly skip; they'll happily hand an agent a fact with no notion of where it came from or how confident to be in it.
Spectron treats provenance and grounding as first-class: every fact carries its source down to the byte span it came from, knows when it was true and when we learned it, and is honest when the answer is uncertain rather than confidently wrong. For anything customer-facing or high-stakes, that difference between "the model said so" and "here is the data this is grounded in, and here is how sure we are" is the whole ballgame.
A trusted memory layer that grows with your ecosystem is exactly the right way to put it; trust is the feature, and everything else is in service of it 🎉.