DEV Community: SPMOS.ai

Your agents will change. Make sure your memory doesn't have to.

SPMOS.ai — Wed, 16 Sep 2026 07:32:39 +0000

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

Agent Memory Is Not "Vector Search Pasted Back Into the Prompt"

SPMOS.ai — Tue, 25 Aug 2026 13:31:56 +0000

Agent Memory Is Not "Vector Search Pasted Back Into the Prompt"

Most agent-memory demos can be summarized in one line:

conversation → chunks → embeddings → top-k → prompt

That is useful, but it is not yet a reliable memory system.

We learned this while building SPM-Polaris, a provider-neutral memory and context layer. Once the system was placed inside real Chat/Responses/Messages request paths, the harder questions appeared after retrieval:

Is the retrieved text tied to a source?
Is it a user statement, an observed fact, or an assistant proposal?
Is it safe to use now, or has it been superseded?
Can an old exchange be removed without breaking a tool call or provider-managed state?
Does deletion remove vectors, candidates, and delayed jobs as well as the primary record?
Does an MCP integration actually invoke memory at the right time?

The result was a shift in our design vocabulary. We stopped treating "memory quality" as one retrieval number and started treating memory as a request and data lifecycle.

1. Long context did not eliminate the memory problem

Long windows are valuable, but they do not make all historical content equally useful. Research on long-context utilization and long-context RAG shows that information position and hard negatives can affect answer quality. A provider's stateful API may simplify lineage, but growing history can still carry token cost.

For a week-long coding task, replaying everything is often both expensive and counterproductive. The system needs a way to retain the latest task and protected protocol state, retrieve relevant evidence, and remove only history that can be safely represented by that evidence.

2. We separated "found" from "allowed to use"

SPM-Polaris has a candidate-retrieval stage and an evidence-admission stage. Similarity is not sufficient. A result must retain source boundaries and satisfy the gate before it can replace historical exchanges.

That separation changed how we report results. Evidence containment ("did the payload include the source material?") and answer accuracy ("did the downstream reader produce the right answer?") are different measurements, and quoting a containment figure as a memory score is misleading. We previously published internal numbers for both; we have since withdrawn them pending a reproducible manifest — including one result we invalidated ourselves after finding protocol drift — rather than let them circulate without their evidence pack.

When nothing qualifies at the gate, the system returns UNKNOWN and injects nothing, instead of guessing with plausible-looking context.

3. Compression is mainly a state-integrity problem

Deleting the oldest messages until a token budget is met is unsafe for a tool-using agent. A request can contain system/developer instructions, function-call identifiers, tool results, multimodal blocks, provider reasoning state, and conversation lineage.

Our rule is deliberately conservative: an old complete exchange is removable only when admitted evidence covers its precise source set and no protected provider state is damaged. When the proof is missing, the request passes through unchanged.

This creates a seemingly odd but important product behavior: sometimes the correct compression ratio is zero.

4. Proxy and MCP are different experimental paths

The Hosted or Local Proxy is inline. It can automatically recall memory, compile context, and record the result. MCP exposes tools, but the host or model decides whether to invoke them and where to insert the response.

The same memory backend therefore does not guarantee the same outcome. A proper comparison needs matched models, tool schemas, invocation policy, return size, placement, judge, and seeds. We now treat integration_path as part of the benchmark manifest.

5. What we can currently report

Single observations from our production path — each with its scope, none of them averages, SLOs, or third-party certification:

one eligible hosted Provider Proxy request: 66,265 original tokens → 365 forwarded + 279 recalled (a single request; ineligible histories may show no reduction at all);
one measured Starter rate-limit window: a 45-request burst against a 30-requests-per-minute window returned 30 successful requests and 15 HTTP 429 responses;
one production MCP remember/status round trip: ready in 8.23 seconds;
one production MCP remember-to-read round trip: stored and read text matched byte-for-byte;
one warm production MCP recall: about 4.93 seconds.

Every agentic request also emits an auditable receipt, including original and forwarded token counts for elided tool output, so removed history appears as real savings instead of a passthrough zero.

The limitations are just as important:

the raw request and receipt manifests for the observations above are still being prepared for public inspection;
we do not yet have public p99, sustained soak, or 100+ concurrency data;
production charging is disabled;
several moderation, abuse-protection, and reservation-recovery items remain open;
Proxy results do not automatically transfer to MCP.

6. The questions we think matter next

The next generation of agent-memory evaluation should measure more than retrieval:

write fidelity and source authority;
evidence admission under conflicts and hard negatives;
whether admitted evidence actually enters context;
provider-state integrity after compression;
updates, supersession, and abstention;
deletion completeness under delayed jobs and reindexing;
answer quality, token cost, latency, and task success by integration path.

Our current view is simple: an agent-memory system should be judged not by how much it stores, but by whether it can explain why a memory was used, what it safely replaced, and what happened when the evidence was not good enough.

Disclosure: I am affiliated with the team building SPM-Polaris at Veridical Tech. The figures above are single first-party engineering observations, not independent third-party certification. Documentation: https://docs.spmos.ai/