Comparison
Supermemory finds context. ContextDB checks evidence before actions.
Supermemory bundles memory, document RAG, user profiles, extractors, and connectors into one API. ContextDB does one narrower thing: decide what an agent may rely on when it acts, and record why. Claims about Supermemory below come from their public documentation as of August 2026.
Different jobs
Context breadth and pre-action evidence checks solve different problems.
Supermemory's documented strengths
- One API spanning memory, document RAG, profiles, extractors, and connectors (Notion, Drive, Gmail, GitHub)
- Hybrid search across extracted memories and document chunks in a single query, with reranking and query rewriting
- Auto-maintained user profiles built from interaction history
- Multimodal ingestion: PDFs, images, video, code, processed into memories automatically
- Memory Review for low-confidence inferred memories, with approve, decline, and undo actions
ContextDB's pre-action controls
- Mandatory provenance on every write. A fact without a source does not exist here
recall_for_actionevaluates policy-trusted evidence and returns an advisory act, ask, or abstain outcome- Confirmation records authenticated project-credential context for API or MCP, or operator context for Console, against one scoped memory. The customer host owns end-user authentication and attestation. The record does not prove objective truth.
- A decision log and signed webhooks carrying outcomes and evidence IDs, never memory content
Relevance versus permission
Better retrieval can still surface the wrong customer detail.
Supermemory's documented surface is a broad context pipeline: more sources, hybrid search, and user profiles. That helps conversations. Its Memory Review queue also lets a person approve, decline, or undo low-confidence inferred memories. When an agent is about to move money or change an account, a separate question remains: "which evidence does policy trust for this action?"
Memory review changes a memory's review state and ranking. ContextDB's action gate evaluates provenance and other policy signals, then records an act, ask, or abstain outcome with evidence IDs. Supermemory's public docs reviewed in August 2026 do not describe Memory Review as an evidence-linked decision at action time.
ContextDB returns and records an advisory decision. The customer host
must enforce ask and abstain by withholding the
tool call, and it must keep its own authorization checks. ContextDB does
not run, block, or structurally constrain code in the customer host.
# context stack: rank everything relevant search("customer plan change", rerank=true) → 1. "asked about annual discount" 0.91 2. "confirmed upgrade to Pro" 0.88 # ranking cannot say which one authorizes billing # contextdb: permission, not just relevance recall_for_action("change billing plan") → outcome = "act" evidence = "confirmed upgrade to Pro" (user_stated · confirmed · decision recorded) the customer host authorizes and executes the change
Supermemory and ContextDB
Supermemory and ContextDB, compared by the job.
The Supermemory column reflects its public docs and repository as of August 2026. Verify current details against its documentation. The ContextDB column reflects the shipped Cloud and the statuses in the changelog.
| Dimension | Supermemory | ContextDB |
|---|---|---|
| Core job | Full context stack: memory, RAG, profiles, connectors | Decision-safe memory for agents that take action |
| Ingestion | Automatic: conversations, documents, connectors, multimodal | Explicit writes with mandatory source and confidence |
| Retrieval | Hybrid memory + document search, reranking, rewriting | Scoped recall for grounding. Gated recall for action. |
| Trust semantics | Relevance, recency, inferred-memory state, and review status | Source, confidence, confirmation status, policy outcome |
| Pre-action gate | No documented evidence-linked act, ask, or abstain decision at tool-call time | recall_for_action: act, ask, or abstain |
| Human-in-the-loop | Memory Review: approve, decline, or undo inferred memories | Pending confirmations with project-credential or Console operator context. API and MCP do not identify the end user. |
| Audit | API request and response logs. Public docs reviewed in August 2026 do not document an evidence-linked action decision record | Decision records with evidence IDs on every gated call |
| Scoping | Container tags are authorization boundaries with scoped API keys and member restrictions | Org, project, and user partitions enforced at the store, with isolation tests |
| Knowledge-base RAG | Includes document chunks in results | Out of scope. Keep your RAG and add the gate. |
| License and hosting | Hosted platform. Self-host option per their docs. | Apache-2.0 SDK plus hosted Cloud |
Which one fits
Choose the context layer by the action risk.
Choose Supermemory when
- The job is knowing the user and the documents deeply, across many sources, with minimal assembly
- Your agent's output is words a human reviews, not mutations it executes
- Connector coverage and multimodal ingestion are the binding constraint
Choose ContextDB when
- The agent executes bookings, refunds, credits, or account changes without a human in the loop
- You must answer "why did the agent do that?" with evidence, after the fact
- Your host will enforce ask and abstain before tools run while retaining its own authorization checks
Combined stack
How Supermemory and ContextDB can fit in one stack.
Can ContextDB sit behind a Supermemory-powered agent?
Yes. Keep Supermemory for grounding and document context, and put
recall_for_action in front of the tools that mutate
state. The customer host must honor ask and abstain. ContextDB cannot
structurally enforce the host's code. The gate does not care what
produced the conversation.
Isn't ContextDB just doing less?
Deliberately, yes. The hosted surface is intentionally narrow, and capabilities ship only after their isolation proofs land. If you need connectors and document pipelines, use a product built for them. The ContextDB surface this comparison centers on is the permission layer, which is where action-taking agents need a separate policy decision.
Do both handle forgetting and updates?
Supermemory documents update and forgetting flows for memories. ContextDB Hosted Alpha supports request-driven deletion of one scoped memory or stable slot, plus verified user-partition erasure with typed confirmation and immediate residue checks. Scheduled retention and large asynchronous erasure remain planned, so customers must enforce schedules externally. See the trust model for current limits.
Put policy in front of one consequential tool.
Run one tool request and inspect the recorded evidence and outcome.