Every team I talk to is building the same trap without noticing it.
They pick an agent framework, a chat platform, a productivity suite with a built-in assistant. Knowledge starts accumulating inside that choice: customer details the assistant learned, decisions from last quarter's meetings, the operational facts people typed into chat instead of a wiki. It works — until the platform changes. A new agent vendor, a migration to a different suite, a compliance requirement to move data. And then everyone discovers the knowledge wasn't theirs. It was formatted for, indexed by, and stuck inside the tool.
Model providers already went through this. "Don't lock your inference to one vendor" is now standard advice, and most serious setups can swap models with an environment variable. But almost nobody applies the same logic one layer down: the memory your agents depend on is just as lock-in-prone as the models — and usually less portable.
That's the layer we built SPM-Polaris to be: an auditable, receipt-backed memory foundation that stays independent of any single agent, platform, or model. This post is about what that actually means in production behavior, not in adjectives.
What a memory foundation is (and is not)
A memory foundation is the governed long-term memory layer underneath your applications. Every write, recall, refusal, and deletion passes the same gates and leaves the same evidence, no matter which application produced it.
Three clarifications, because the category is muddy:
- Not a data warehouse. Transactional records and analytics stay in your ERP and databases. This layer holds governed knowledge and decisions.
- Not an agent builder. Your agents, frameworks, and collaboration tools remain yours. The foundation is the memory they share.
- Not a foundation model. Your models stay on your own provider accounts, billed by your provider directly. There is no inference resale or markup.
Six behaviors, not six slogans
Isolated memory per end user. One API key with the memory:partition scope serves many end users; each memory space is fenced across writes, recall, evidence reads, and read tokens. A whole organization — or your entire customer base — can share one memory plane without sharing memories.
Source-ranked recall. Not all information deserves equal weight. The lane_policy parameter separates deliberate saves from passive captures: explicit_first (default) ranks confirmed records ahead of passive proxy captures, blended keeps one shared pool, observed_only answers from captures alone. One honest caveat: the parameter is accepted today, and server-side lane ordering activates after a paired evaluation gate — we'd rather tell you that than let you find out.
Change recorded, not overwritten. When a preference, configuration, or decision changes, the system records the current state and keeps the earlier state as history. The shipping date moved from the 15th to the 22nd? The record shows "22nd (previously: 15th)". For operations teams, the difference between "current value" and "current value with lineage" is the difference between a system and a rumor.
UNKNOWN instead of invention. When memory cannot support an answer, the evidence gate returns UNKNOWN with a gate reason and injects nothing. This sounds like a limitation until the first time a confident, wrong answer would have gone to a customer. Then it reads as the feature.
Auditable operations. Requests carry signed receipts. Deep evidence review reports its rounds, selector tokens, and latency on every response. Compression is deterministic code — zero LLM calls in compression; when deep review examines evidence it uses SPM-operated models, and only the answer-generation call ever appears as provider tokens on your receipt.
Erasure you can present. Every successful purge returns an HMAC-SHA256 signed receipt stored with the purge record — counters, scope, key id. Deleted identifiers are never reused within the same memory generation, so a stale receipt cannot resurrect purged content. When a user exercises a GDPR-style erasure right, "we deleted it" becomes something you can demonstrate, not declare.
Where it plugs in
A few scenario framings — explicitly not measured outcomes; validate on your own workload:
- Support copilots: each customer's device history and prior tickets in an isolated partition; agents stop re-asking, answers arrive with evidence, off-policy questions get UNKNOWN.
- Community & market intelligence: agents extract recurring issues into shared memory once, and "what was already reported" is remembered instead of re-sent.
- Operations knowledge: schedules and logistics change constantly; the foundation keeps the current state and the previous one.
- Cross-platform agents: any MCP-capable agent, or the compatible APIs, reads and writes the same governed memory — whichever collaboration platform or model provider it runs on.
The boundaries we'd rather state up front
The memory plane is hosted. Credential custody is your choice across three integration paths: Hosted Provider Proxy (SPM holds the credential), Local Proxy (the credential never leaves your machine), and MCP (your app owns inference and calls memory as explicit tools). Data-residency and deployment questions deserve a conversation, not a landing page — contact@spmos.ai.
And a discipline note: every number we publish is a bounded first-party observation with a named scope and date. If you're evaluating us, hold us to that standard — and hold everyone else to it too.
Evaluate it in an afternoon
- Self-serve in the console — the free plan covers real small-scale usage; recall depth, capture switches, compression, and budgets are adjustable in Settings.
- Verify against the docs — integration boundaries, architecture, benchmarks, and security pages are the canonical references; every claim above traces there.
- Talk to us — enterprise deployments, partition design, data residency: contact@spmos.ai.
SPM-Polaris is the current production SPMOS product, developed by Veridical Tech, Inc. Links: Enterprise memory foundation · Documentation · Changelog
Top comments (0)