Dense-Mem

Self-hosted memory for AI agents that preserves evidence, detects conflicts, and never silently rewrites facts.

Create a temporary isolated team and test Dense-Mem before self-hosting.

Dense-Mem gives MCP clients a durable memory layer with provenance, typed claims
and facts, verification gates, server-side embeddings, recall, team isolation,
REST/OpenAPI, and a token-protected control portal. The host LLM owns
conversation and judgment; Dense-Mem owns durable memory state and returns
structured outcomes the host can explain to users.

Under the hood, Dense-Mem is a standalone HTTP MCP memory server. HTTP MCP is
the v1 supported MCP transport and is served at /mcp from the main HTTP
process.

Dense-Mem is part of the research preprint
Governed Enterprise AI Memory Beyond RAG: From Vector Retrieval to Permissioned
Knowledge Graphs.

Try the Hosted Demo

Create a temporary isolated team at
https://demo-dense-mem.markhuang.ai and
test Dense-Mem before self-hosting.

Cartoon architecture illustration: AI clients send evidence into a secure Dense-Mem vault where claims become facts, conflicts become clarification questions, and durable storage sits behind the service.

Why Dense-Mem?

AI agents need memory that can be trusted later, not only text that can be
retrieved later.

Evidence is first-class. Memories start as source fragments before they become
claims or facts.
Facts pass through typed claims, verification, and promotion gates.
Comparable conflicts become clarifications[]; Dense-Mem does not silently
overwrite active facts.
The host LLM stays responsible for extracting candidates and asking the user
questions. Dense-Mem stays responsible for durable state, gates, audit
metadata, and recall.
Operators keep control of storage, team/profile isolation, API keys, and data
egress boundaries.

60-Second Quickstart

Download the base local-only compose example and env template, set the required
secrets, and start Dense-Mem:

mkdir dense-mem-local
cd dense-mem-local

curl -fsSLo docker-compose.yml \
  https://raw.githubusercontent.com/markhuangai/dense-mem/main/examples/docker-compose.base.yml
curl -fsSLo .env.example \
  https://raw.githubusercontent.com/markhuangai/dense-mem/main/examples/.env.example

cp .env.example .env
# Fill in POSTGRES_PASSWORD, NEO4J_PASSWORD, CONTROL_PORTAL_TOKEN, and AI_API_KEY.
${EDITOR:-vi} .env

docker compose up -d
docker compose exec server /app/provision-team --name "primary-memory"

The base compose example provisions Postgres, neo4j:5.26-community with the
Neo4j Graph Data Science plugin, and the Dense-Mem server. It exposes only local
host ports:

MCP/API:        http://127.0.0.1:8080/mcp
User portal:    http://127.0.0.1:8080/ui
Control portal: http://127.0.0.1:8090/

Cold image pulls can take longer than 60 seconds. Redis and public HTTPS are
intentionally omitted from the base example; use the expert example when you
need those deployment options.

The server requires a complete embedding configuration at startup:
AI_API_URL, AI_API_KEY, AI_API_EMBEDDING_MODEL, and
AI_API_EMBEDDING_DIMENSIONS. The compose examples provide OpenAI defaults for
the URL, model, and dimensions (https://api.openai.com/v1,
text-embedding-3-small, 1536), so the minimal local setup only needs you to
fill in AI_API_KEY. Override those values together when using a different
embedding provider or model.

Compare

Capability	Dense-Mem	File memory	Vector DB	Generic MCP memory
Evidence provenance	Source fragments are stored before claims or facts	Usually absent or informal	Stores chunks, not truth history	Varies by implementation
Fact changes	Verification gates and promotion rules	Manual edits	Similarity updates can obscure history	Often tool-specific
Conflict handling	Comparable conflicts return clarification tasks	Caller must notice	Similar vectors do not mean contradiction	Usually caller-managed
Recall	Facts, claims, fragments, contradictions, and clarifications	Text search	Vector similarity	Varies
Agent boundary	Host LLM judges; Dense-Mem stores and enforces	Blurred	Retrieval only	Often blurred
Operations	Teams, profiles, API keys, audit metadata, REST, OpenAPI, MCP	Minimal	Database operations	Varies

Redis is optional for single-node deployments and required for multi-instance
deployments.

Documentation

The README is the product overview. The full user documentation lives in the
Dense-Mem wiki:

Goal	Wiki page
Run Dense-Mem locally	Quick Start
Use memory day to day	Using Dense-Mem
Configure providers, Redis, and Traefik	Configuration
Understand the system design	Architecture
Review API and operations details	Technical Reference

Responsibility Boundary

Area	Dense-Mem owns	Host LLM owns
Memory writes	Evidence fragments, typed claims, verification, gates, promotion	Extracting candidate memories from chat text
Embeddings	Fragment embeddings and recall-query embeddings through the configured provider	No vectors for normal writes or recall
Retrieval	Facts, validated claims, fragments, contradictions, clarification tasks	Choosing what to ask or cite in the conversation
Truth changes	Comparable-conflict detection, confirmation-driven supersession	Asking the user which uncertain memory is correct
Operations	Teams, named profiles, API keys, audit metadata, control portal	Client-side MCP configuration

Dense-Mem is not an agent brain, planner, or external truth arbiter. It stores
memory, applies explicit gates, and returns structured outcomes.

Memory Workflow

Tool	Purpose
`remember`	Normal chat-session memory insertion. Saves evidence, creates typed claims, verifies, promotes when gates pass, and returns structured outcomes.
`import_memories`	Ingests summarized historical conversations. By default it records evidence and validated claims without auto-promotion.
`recall_memory`	Retrieves facts, validated claims, fragments, and `clarifications[]` for the authenticated team.
`reflect_memories`	Reviews active facts, candidate or disputed claims, contradictions, stale memories, and clarification needs.
`confirm_memory`	Applies the user's answer to a clarification task, either accepting a claim and superseding comparable active facts or keeping/rejecting it.

Low-level tools remain available for advanced callers: save_memory,
post_claim, verify_claim, promote_claim, search tools, graph query tools,
community tools, and retraction tools.

Memory moves through this path:

source fragment -> typed claim -> verification -> promotion gate -> active fact
                                                   |
                                                   v
                                            clarification task

Comparable conflicts are not resolved silently. Dense-Mem returns
clarifications[], and the host LLM asks the user which memory is correct. After
the user answers, the host calls confirm_memory.

Data Egress

Dense-Mem forwards fragment text and recall queries to the configured embedding
provider. Claim verification can send candidate claims and supporting evidence to
the configured verifier provider. Self-hosted providers keep that traffic inside
your boundary; hosted providers do not. See the wiki
Configuration and
Technical Reference
for provider settings and egress details.

Embedding Model Consistency

Dense-Mem owns embeddings for normal writes and recall. It checks the stored
embedding model and dimension on startup so vectors from incompatible models are
not mixed silently. Rotation requires re-embedding or rebuilding vector indexes;
the step-by-step process belongs in the wiki
Configuration.

Tool Discoverability

Dense-Mem exposes three discoverability surfaces backed by one registry:

Surface	Path	Purpose
Tool catalog	`GET /api/v1/tools`	Runtime tool discovery
Runtime OpenAPI	`GET /api/v1/openapi.json`	Agents, codegen, integrations
MCP Streamable HTTP	`POST /mcp`, `GET /mcp`	MCP clients over the main HTTP service

The full route list and client examples live in the wiki
Technical Reference
and Quick Start.

Design Notes

License

Apache-2.0