Suprflo

Memory Layer for AI Agents, Persistent Memory

Visit Website
August 7, 2026 How we built suprflo

Every agent we built ran into the same wall. To remember anything, it had to carry its whole history in the prompt, and that history only grew. Each turn got slower and cost more, and after a few weeks of real use it stopped fitting at all. A bigger prompt didn't even buy a better memory. The model still had to work out what mattered on every single call. We were paying more to remember less.

That was the thing that got us started. Memory shouldn't live in the prompt. It should live in a database.

Once we looked at it that way, most decisions made themselves. We keep every fact in Postgres. No special vector service, no lock-in, just Postgres 17 with pgvector, because a memory system needs durability, transactions, and plain SQL, and teams already run those in production. Then we made the store bi-temporal: every fact records when it was true and when we learned it. We never overwrite. When someone's preference changes, the old fact isn't deleted. It gets closed off with a validity window while a new one takes over. So you can ask what the agent knows now, or what it knew last Tuesday, and both answers are right. If you ever have to explain what an agent did, that history is what you reach for.

Storage turned out to be the easy part. Recall is the hard part: finding the handful of facts a query needs inside thousands. We combine three signals, semantic similarity, keyword match, and a boost for named entities, then rerank the top candidates with a cross-encoder that reads the query and each memory together. The agent pulls a small, relevant slice instead of dragging its entire past along. That is where most of the cost savings come from. We also keep semantic, episodic, and procedural memories apart, since you retrieve and reason about each of them differently.

Memory that only grows turns into noise, so we let it fade on purpose. A decay model based on the Ebbinghaus forgetting curve quietly lowers the weight of old facts that never get reinforced, and a background process folds raw conversation turns into cleaner, higher-level memories over time. Isolation had to be there from the start too, because most deployments are multi-tenant. Every row is scoped by org, project, user, and agent, enforced right in the SQL where clause and checked by a test suite that tries to leak data across tenants and can't.

None of this would count for much if we couldn't back it up. We ran the open benchmarks with the same answerer and judge models everyone else uses, and then we did the slower thing: we went through every failure and figured out why it happened instead of quoting one number and moving on. That is why we say 92.1% on LoCoMo, or 93.0% once we audited each miss against the source conversations, and 75.8% on BEAM. You can run them yourself.

Suprflo is still pre-launch, and a lot of it is rough. The managed platform is early, and there's framework coverage we haven't finished. But the bet we opened with, that memory belongs in a database and not a prompt, has held up every time we've measured it. So we're keeping at it.

1 Comment

  1. 1

    You’ve clearly put a lot of work into proving the technical side of the memory problem.

    Now that you’re pre-launch, what are you actually most uncertain about on the commercial side?

About

Suprflo exists because every AI system we built faced the same challenge: agents could reason well but couldn't remember. We repeatedly built custom memory infrastructure to extract, store, and retrieve facts.