Spectron

Spectron feels like it tackles the messy reality of agent memory head-on. Curious, what’s the most painful memory bug you’ve seen in production, and how did the team patch it?

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.

We've found that one of the hardest parts of agent memory isn't retrieval, it's deciding what should stop being remembered.How are you handling state changes over time? For example if an agent learns one preference and later learns an updated preference, does Spectron treat that as a replacement of state or simply another memory to rank during retrieval?

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.

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.

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

The tri-temporal model stands out. Most systems use a single timestamp and silently lose information they didn't know they'd need later. We've seen agents produce stale answers because correction propagation was eventually consistent rather than atomic. When two agents simultaneously try to supersede the same fact with conflicting data, does Spectron record that as an explicit conflict or does last write win?

How does provenance work in practice? If a fact originates from multiple sources and is later corrected, what does the audit trail and retrieval experience look like?

Haven't actually gotten to try it yet since it's still early preview, but I already know the use case I want to throw at it. I run long Opus sessions, usually right up against the 1M context, and I almost always forget to compact them, so I either hit the wall or lose a pile of good context when the session ends. A memory layer that consolidates and carries the important stuff between conversations on its own is exactly the thing I keep wishing I had, because then forgetting to compact stops being a problem. The memory just persists.The reflection and consolidation between conversations is what sells it for me. And as someone who already lives in SurrealDB, having it all on one substrate in a single transaction is a big bonus. Can't wait to get off the waitlist.

the multi-model in one ACID transaction is the architectural claim worth pressure testing. most databases that support multiple data models achieve it through separate storage engines with a unified query layer, which means cross-model transactions have hidden consistency tradeoffs. curious whether the graph, vector, and document operations are truly atomic in a single engine or whether there's an abstraction layer underneath that introduces edge cases under concurrent writes

agents confidently answering with outdated info because a correction got lost somewhere in the memory layer is one of those problems you don't notice until it costs you. provenance on every fact so you can trace where an answer came from should be standard

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.

I've been watching and documenting Spectron for a good length of time now, and here are some of the most interesting parts I recommend keeping an eye on when first experimenting with it:Tri-temporal model (i.e. three types of time): there is time in the sense of when something was valid in the real world (Austria-Hungary was valid from 1867 to 1918), there's time in the sense of when you learned something ("We learned about Austria-Hungary in 1994 in school"), and there's system time (when facts were registered) Different types of knowledge: ranges from authoritative knowledge (facts you know are true and add as such) going down to more experiential and reflective knowledge, and finally to uncertainty so that an agent can actually say "I don't know" instead of trying its best to hack something togetherSupersession: this is where something that used to be true no longer is, but it doesn't mean that the old fact gets deleted. (e.g. you get a new job and are now a pilot instead of a fire fighter) The old info is just valid until a certain date, and the new info becomes the new state.And so on...it basically emulates memory the way we use it as humans.

Hi Product Hunt 👋I am Tobie, co-founder of SurrealDB. We are launching Spectron - the memory layer for AI agents, built on SurrealDB (open source; graph, vector, document, and structured records in one ACID transaction).Why we built itAgents kept looking great in demos and failing in week three: colliding embeddings with the same label, corrections losing to the next high-scoring vector, cross-tenant bleed, confident answers with no lineage. Those are data-layer problems, not “retrieval only.” Spectron is the data-layer answer on the engine we already had.What it isOne substrate holding two kinds of memory, told apart by provenance rather than by separate stores:Authoritative knowledge - org documents, policies, and product data, with ingestion for PDFs, code, images, audio, and video.Conversational memory - the transcript itself, plus identity, knowledge, context, instructions, and unknowns the agent flags but cannot answer yet.How it behavesProvenance on every fact, down to the byte span in the originating turn or document chunk.Corrections kept across three clocks tracked separately: when the database wrote a fact, when we first believed it, and when it was true in the world - plus where it was captured, when location matters.Multi-tenancy and territory scoped in the engine, not patched on at the API.When sources disagree, the more authoritative one is favoured and the conflict is recorded as an explicit uncertainty, never silently overwritten.Memory evolves between interactions: background passes link previously-unrelated facts and crystallise beliefs from what the substrate has accumulated.What early access includesREST API, SDKs for Python, TypeScript, Kotlin, and Swift, MCP server (remember, recall, context, reflect, forget, upload, inspect).We are opening access in waves. We will email you the moment your invite is ready, with everything you need to start building.For this community: what is the worst memory failure you have seen ship to production, and what did the team do about it? The answers I trust are usually the unglamorous ones.