The Memory Database for AI Agents | ThinkingMemory v3

We rebuilt ThinkingMemory around one idea: the query an agent actually needs isn't "find similar vectors", it's "give me the right context for what I'm doing." That query is recall.

When we first launched ThinkingMemory, it was a memory API: four layers, working, episodic, semantic, procedural, each its own table and set of endpoints, with embeddings supplied by the caller. It worked. But using it well meant stitching four stores together in app code and deciding, per call, which one to query.

Agents don't think in layers. An agent mid-task needs the useful context for what it's doing right now, fused from everything it knows, ranked, and small enough to fit the prompt. So we rebuilt ThinkingMemory into a purpose-built memory database whose single query primitive is recall.

One substrate, one primitive

The four layers collapsed into a single Memory object. The "layer" is now just a tag (mtype) on a row, so one query spans all of an agent's memory instead of four separate stores. Every read is one call:

# intent in → packed, cited context out
POST /v1/recall
{
  "agent_id": "a1",
  "intent": "what is the API rate limit?",
  "token_budget": 2000
}

# →
{
  "context": "[1] API rate limit is 1000 rpm per tenant.",
  "items":  [{ "id": 42, "why": ["vector","keyword","rerank"] }],
  "tokens_used": 16,
  "tokens_saved_vs_dump": 1840
}

You send an intent; you get back a ready-to-use context string with [n] citations, packed to your token budget, not a pile of rows. And you never touch a vector: embeddings are generated server-side by a local model, so there's no API key and no per-call cost.

Why a database, not a vector store

Generic Postgres + pgvector is bad at exactly the things agents need. The value lives in primitives a stitched-together setup can't easily match:

Hybrid retrieval. Candidates from vector similarity, Postgres full-text, recency, and entity-graph hops are fused with Reciprocal Rank Fusion, weighted by salience, then optionally reranked by a cross-encoder.
Token-budget packing. Recall assembles a deduped context window that fits your budget and reports how many tokens it saved versus dumping everything.
An in-engine lifecycle. The part that makes recall improve over time.

On our bundled benchmark, hybrid recall returns the gold memory 100% of the time (recall@5) versus 0% for a naive "show the latest" baseline, in about 68% fewer tokens than dumping the whole corpus.

The lifecycle is the moat

A vector store is static: what you put in is what you get out. A memory database has a metabolism. Background workers run a "sleep" cycle that keeps memory healthy:

Decay & reinforcement, salience fades over time, but every recall boosts what it surfaced. Useful memories rise; stale ones sink.
Extraction, durable facts are pulled out of raw episodic memories into clean semantic ones, linked back to their source.
Consolidation, clusters of related memories are summarized into a single durable memory.
Supersession & contradiction resolution, duplicates collapse, and conflicting facts are detected so the older belief is retired.
Forgetting, low-value, long-idle memories are soft-closed (recoverable), then pruned.

The result: the same agent gets sharper as it runs, no retraining, just better recall.

Belief over time, and proof

Every memory records when it was true in the world and when we learned it. That makes the database bitemporal: you can recall against the past (as_of), reconstruct what an agent believed at any moment (/v1/timeline), trace why it knows a fact down to its sources (/v1/trace), and review an append-only operation log (/v1/audit). For multi-tenant deployments, isolation is enforced at the database itself with per-tenant row-level security, and the store is hash-partitioned by tenant.

MCP-native

It ships an MCP server, so any MCP-capable agent uses memory as native tools, remember, recall, link, forget, with zero glue. Plus a plain REST /v1 API for everything else. Any framework, any LLM, self-hosted or managed.

# point any MCP client at it
{ "mcpServers": { "thinkingmemory": { "command": "thinkingmemory-mcp" } } }

Point your agent at recall

ThinkingMemory is open-source under the Apache-2.0 license and runs on Postgres with a local embedding model, no API key required. Read the overview, or clone the repo and run your first recall in minutes.

▸ explore thinkingmemory ▸ github

Where this goes

The thesis is simple: retrieval quality is the whole product, and the metric, tokens saved, recalls served, is also the bill. We measure recall with an eval harness on every change, because a beautiful dashboard over recency-based retrieval is just a nicer vector wrapper. From here: smarter rerankers, richer graph recall, and LLM-grade extraction when you bring a key.

If you're building agents that should get better the longer they run, point them at one endpoint and let them recall.

- the memory database agents recall from ✎

← back to blog