Spectron - Agent memory you can trust

@tobiemh Interesting positioning, especially with vectors, graphs, documents, and relations all living in the same engine. For teams building AI agents today, what's been the most common reason they've chosen SurrealDB over combining multiple specialized databases?

Good question, @ansari_adin, and you've described the common pattern accurately; a lot of "multi-model" systems are separate engines behind a shared query planner, where cross-model atomicity is exactly where the bodies are buried.

SurrealDB is the inverse of that. There aren't separate storage engines per model; there's a single transactional key-value core, and documents, graph edges, and index entries are all just different key encodings over the same keyspace. A graph relation is a record, a vector or full-text index entry is a key maintained in the same write path, and so on. Because of that, a transaction spanning a document write, the edges it touches, and the index updates is one transaction over one keyspace under MVCC, not a coordinated commit across independent stores. There's no second consistency boundary hiding underneath to leak edge cases under concurrent writes. And every transaction has snapshot isolation consistency.

The interesting concurrency questions move to the layer you'd expect, which is the isolation and conflict-resolution semantics of that transactional core (and how that behaves on the distributed backend), not to "did the graph and the vector index disagree because they're really two databases." Happy to go deeper on the isolation model if you want to keep digging; the transactional core underneath is the part that makes all of it possible.

@ansari_adin The difference with SurrealDB is that all the data models, documents, graphs, vectors, time-series, run as native primitives inside a single Rust-based engine, not separate storage engines bolted together with a query layer on top. So when you're doing a cross-model operation, you're working within one transactional snapshot, not coordinating across subsystems. That's what makes the ACID guarantee real rather than approximate. 3.0 also overhauled concurrent writes on vector indexes specifically, and 3.1 added DiskANN as a second index type for larger-than-memory vector workloads if you want to dig into the details on either.

@tina_chhabra Exactly, memory without provenance is risky because the agent can be wrong with confidence. That’s why provenance is such a big part of Spectron. You need to know where a fact came from, when it changed, and whether it has been replaced. That is what makes agent memory usable in production.

This is exactly the failure mode we built around, @tina_chhabra 🎉 !

The subtle part is that a correction getting "lost" is usually a deletion in disguise; most systems overwrite the old fact and hope the new one propagates everywhere it needs to. Spectron never deletes a superseded fact; it bounds when the old one was valid and makes the new one current, so the agent answers with today's truth but can still tell you what it believed last quarter and why it changed. Provenance on every fact, down to the source it came from, is what makes that traceable rather than a leap of faith.

Honestly, the whole design goal was to get as close to human memory as we could: memory that revises itself, holds onto its own history, and knows how it came to believe something. The twist is making that a collective memory, so a whole organisation or team shares one trusted recollection instead of every agent and person carrying their own slightly-wrong copy. That is when it stops being a database and starts feeling like the team actually remembers.

Long-running agent sessions shouldn't depend on remembering to compact at the right moment. The important context should persist, consolidate, and carry forward naturally between conversations.

Really excited for you to try it Lay and looking forward to your feedback, especially since you're already using SurrealDB and a part of our Ambassador Programme.

This use case is right in the bullseye, @cloaky233. The thing worth calling out: compaction on its own is lossy by nature; you're squashing a session into a summary and quietly throwing away the detail you didn't know you'd need later. Spectron does compact, summarise, and "dream" too, but the difference is we never discard the original; the important facts get promoted into durable, queryable memory, and the full data and context stay in the knowledge graph underneath. So nothing has to be "remembered to be saved," and three sessions later you can still pull the specific thing instead of whatever survived the summary.

And because you already live in SurrealDB, that memory is sitting right next to the rest of your data on one substrate. Genuinely can't wait to hear how it holds up against your Opus sessions; that's exactly the kind of workload we want pushing on it.

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 🎉.

Spot on @mithridates, you've put your finger on exactly the part we obsessed over most. 🙌

The tri-temporal model is the thing people underestimate until they hit it in the wild: "when it was true," "when we found out," and "when the system recorded it" are three genuinely different questions, and almost every memory system collapses them into one timestamp and quietly loses information. Keeping them separate is what lets an agent reason about what it knew and when - not just what's true now.

And yeah, the supersession point is the heart of it: we never destroy the past, we just bound its validity. Your firefighter→pilot example is perfect; ask "what do they do?" and you get pilot; ask "what did they do in 2019?" and the old fact is still right there, intact.

The "I don't know" piece is the one I'd love more people to push on. Confidently-wrong agents are the real failure mode, so modelling uncertainty as a first-class citizen mattered more to us than squeezing out another point of benchmark accuracy.

The fun part is what these three unlock together: querying memory as of any point in the past, watching beliefs get revised over time, replaying how the agent's understanding evolved. That's where it starts feeling like actual memory.

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.

why did this score change

This is a great example of the kind of thing Spectron should make much easier to model.

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.

Good question @jn263, this is one of the parts spent a considerable amount of time designing.

Provenance is a stored field, not a best-effort annotation. Every fact-bearing row carries where it came from, pinned down to the byte span in the originating turn or document chunk, plus a trust prior for that source. When multiple sources independently support the same fact, that isn't flattened into one record; each assertion stays its own row with its own provenance, and corroboration is tracked explicitly (proof counts, and promotion that points back at the originals). So "three sources said this" is something you can actually see and walk, not a single averaged-out fact.

When sources disagree, we deliberately don't silently pick a winner. A cross-provenance contradiction (say a conversation says one thing and a document says another) emits an explicit uncertainty row, and both facts stay valid until it's resolved, rather than one quietly overwriting the other. Same-source updates supersede normally, and even then nothing is deleted: the prior belief stays with its validity bounded in time, so the correction is a chain you can replay.

Underneath that, sit three clocks: when a fact was true in the world, when we first learned it, and when the system recorded it. So the audit trail answers "what did we believe, on what basis, and when did that change".

On retrieval: by default you get the current view with sources attached, traceable back to the bytes. But you can also ask "as of" a past point in time and get what the system would have answered then, with the provenance that applied at that moment. A correction shows up as a transition in the history, not a gap.

Really great question @anand_thakkar1! The short answer: explicit conflict, not last-write-wins.

When a new fact contradicts an existing one across provenance (say two agents writing from different source types), the reconciler doesn't pick a winner. It emits an explicit uncertainty record and keeps both facts valid until the conflict is resolved, rather than letting one quietly overwrite the other. Even in the simpler same-source case, a correction supersedes by bounding the old fact's validity in time rather than deleting it, and a low-confidence write is refused rather than allowed to clobber a high-confidence one. Nothing is lost, and the contradiction is visible instead of silent.

On the truly-simultaneous case specifically: every write is one ACID transaction on a single substrate, so there's no cross-store propagation lag of the kind that produces the stale answers you're describing. The conflict is recorded in the same place the facts live, not reconciled after the fact by a background job. Happy to go deeper on the isolation semantics if you want to get into the concurrent-writer edge cases!

@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.

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.