Spectron - Agent memory you can trust
by•
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.
Replies
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
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.
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.
Second Brain for AI
The framing of "bolt-on vs built-in" clicked immediately. Most tools treat memory as an afterthought layered on top. You're making the case that it has to be foundational to actually work reliably.
Curious who the primary user is here. This feels more like infrastructure for teams building production AI products than something an individual developer would spin up. I've been building in the personal/self-hosted memory space and the two feel like they're diverging fast. Both worth solving, just for very different people.
SurrealDB
@rahilpirani The primary focus is enterprises and teams building production AI infrastructure, where memory needs to be reliable, shared, and queryable across agents, tools, and applications.
That said, Spectron is not only for large teams. It is available to individuals too, whether you are building self-hosted agents, personal AI workflows, or experimenting with long-running memory use cases.
Built a 7-agent system for B2B marketing where every agent reads a shared client intelligence file. The failure mode was never retrieval accuracy — it was agents confidently acting on stale facts after the client changed direction. Versioning memory and forcing a "last verified" timestamp on every fact cut those errors more than any embedding upgrade did. Retrieval is table stakes now; staleness and trust are where agent memory actually breaks in production.
SurrealDB
@thekrew This is a great real-world example.
Retrieval gets a lot of attention, but the harder problem is knowing whether the thing you retrieved is still valid. A stale fact can be worse than a missing one if an agent acts on it with confidence.
That’s why we think provenance, and verification timestamps need to be part of the memory layer itself, not something bolted on later.
Lancepilot
We recently ran into an interesting challenge in our project, which forced us to migrate everything from a vector database to PostgreSQL with vector support: we have over 1 million objects, each with a text description for vector search and a numerical popularity score used to determine how well-known the object is. We needed to perform searches based on both parameters, not just semantic similarity. As I understand it, your solution also addresses use cases like this, right?