Remem

Most agent frameworks treat memory as a black box. You embed a pile of text, run a similarity search, and hope the right thing comes back. When it does not, there is very little to debug: you cannot see why one memory outranked another, whether recency mattered, or whether a near-duplicate crowded out the entry you actually needed. Remem is built around fixing that opacity. It is a persistent memory layer for AI agents that stores, scores and retrieves memories through an API, and — critically — returns a score breakdown alongside every result. Retrieval uses hybrid scoring rather than raw vector similarity alone. Three signals combine: semantic relevance to the current query, recency so that newer context is not buried under stale entries, and an importance weight so that facts you have marked as durable stay reachable long after they were written. The score_detail field exposes each of those components per memory, which turns retrieval tuning from guesswork into something you can inspect in a log. If an agent recalled the wrong thing, you can see whether it was a relevance miss, a recency bias, or an importance value that needs adjusting. That single design decision is what separates Remem from the memory modules bundled into most agent stacks. The rest of the system is built for control. Duplicate detection stops the same fact being written a dozen times across a long-running session, which is the usual cause of retrieval degradation in agents that run for weeks. You decide what gets stored, what gets retrieved, and what gets deleted — there is no implicit accumulation you cannot audit. For teams with data residency or compliance requirements, BYOD support lets you point Remem at your own Supabase instance so memories live in infrastructure you already own and can query directly with SQL. Remem is framework agnostic. It works alongside LangGraph, AutoGen and CrewAI rather than requiring you to adopt a particular orchestration model, so it can be added to an existing agent without rewriting the control flow. In practice you call the API to write memories as an agent observes things, and query it at the start of a turn to pull back the relevant context window. The honest limitations: this is infrastructure, not a finished product, and it assumes you are comfortable working at the API level and reasoning about retrieval quality yourself. The transparency is only useful if someone on the team actually looks at the score breakdowns — a plug-and-play memory drop-in that nobody tunes will perform much like any other. Importance weighting also requires a policy: if everything is marked important, the signal disappears. And as a developer-facing service in active development, teams evaluating it for production should check the current state of the hosted offering against their uptime needs, or lean on the BYOD path. Remem makes the most sense for developers building long-running or multi-session agents where memory quality determines output quality, and who have been frustrated by retrieval they cannot inspect.