diff --git a/apps/docs/docs.json b/apps/docs/docs.json index 5f1b20f0..467d2cd0 100644 --- a/apps/docs/docs.json +++ b/apps/docs/docs.json @@ -131,7 +131,7 @@ "patterns/agent-task-memory", "patterns/company-brain", "patterns/ingestion", - "overview/use-cases" + "use-cases" ] }, { @@ -749,6 +749,10 @@ { "source": "/intro", "destination": "/overview" + }, + { + "source": "/overview/use-cases", + "destination": "/use-cases" } ], "styling": { diff --git a/apps/docs/overview.mdx b/apps/docs/overview.mdx index 9bea4f8a..e5ccf348 100644 --- a/apps/docs/overview.mdx +++ b/apps/docs/overview.mdx @@ -1,21 +1,18 @@ --- -title: "What is supermemory?" +title: "supermemory docs" sidebarTitle: "Overview" -description: "Supermemory is a context engine: you feed it everything, it derives memories, a knowledge graph, and live profiles — and serves the right context back in ~300ms." +description: "The context engine for AI apps — memories, a knowledge graph, and live profiles from everything you feed it." +mode: "center" icon: "book-open" --- -Supermemory is a context engine. You feed it everything — chat sessions, files, URLs, connector data — and it derives memories, a knowledge graph, and live profiles. When your app needs context, supermemory serves the right slice back in ~300ms. +Supermemory is a context engine. You feed it everything — chat sessions, files, URLs, connector data — and it derives memories, a knowledge graph, and live profiles. When your app needs context, supermemory serves the right slice back in ~300ms. -Here's the whole loop in two calls: +The whole loop is two calls: ```typescript TypeScript -import Supermemory from "supermemory"; - -const client = new Supermemory({ apiKey: process.env.SUPERMEMORY_API_KEY }); - await client.add({ content: "Sarah's being promoted to VP of Product", containerTag: "user_4f8a", @@ -28,10 +25,6 @@ const results = await client.search.memories({ ``` ```python Python -from supermemory import Supermemory - -client = Supermemory() - client.add( content="Sarah's being promoted to VP of Product", container_tag="user_4f8a", @@ -43,160 +36,65 @@ results = client.search.memories( ) ``` -```bash cURL -# add — POST /v3/documents -curl -X POST "https://api.supermemory.ai/v3/documents" \ - -H "Authorization: Bearer $SUPERMEMORY_API_KEY" \ - -H "Content-Type: application/json" \ - -d '{"content": "Sarah'\''s being promoted to VP of Product", "containerTag": "user_4f8a"}' - -# search — POST /v4/search -curl -X POST "https://api.supermemory.ai/v4/search" \ - -H "Authorization: Bearer $SUPERMEMORY_API_KEY" \ - -H "Content-Type: application/json" \ - -d '{"q": "who'\''s getting promoted?", "containerTag": "user_4f8a"}' -``` - -You didn't chunk anything, embed anything, or write a schema. That's the point: supermemory decides what's worth remembering, how facts connect, and which of them are still true. +## Start here -## How it thinks about your data - -You ingest **documents** — any content, from a one-line chat message to a 200-page PDF. The ingestion pipeline (a custom fine-tuned memory model, not an off-the-shelf embedder) derives **memories**: individual facts with provenance and time attached. Memories interconnect into a **graph** of entities and relations. And for each entity, supermemory maintains a **profile** — its current derived understanding, ready to drop into a system prompt. You recall all of it through **hybrid search**: semantic, keyword, and graph combined. - -```mermaid -flowchart LR - A["Documents
chats · files · URLs · connectors"] --> B["Ingestion pipeline
fine-tuned memory model"] - B --> C["Memories
facts with provenance + time"] - C --> D["Graph
entities · relations"] - C --> E["Profiles
current understanding per entity"] - D --> E - C -.-> F["Hybrid search"] - D -.-> F - E -.-> F - F --> G["Your app"] -``` - -Isolation comes from **container tags** (you may see "space" as a synonym — same thing): one tag per user, tenant, or project, and nothing crosses the boundary. **Metadata** slices *within* a boundary — agent role, channel, stage. [Scoped API keys](/concepts/permissioning) enforce the boundary at the key level, so a leaked key can't read another tenant. - -## What makes it different - -Most memory layers are a vector store that retrieves the nearest chunk. Supermemory is built differently, and each difference shows up in what you can ship: - -- **A full context engine.** A custom memory model plus a custom data engine handle extraction, deduplication, and consolidation — you send raw content and get structured understanding back. See [Architecture](/concepts/architecture). -- **Memory that handles time.** Facts carry temporal validity; new statements supersede old ones, and explicit time-bound intent ("remind me for a week from now") creates expiring memories. See [Graph Memory](/concepts/graph-memory). -- **User profiles.** Each container tag gets a live profile of static and dynamic facts — derived, not hand-written, and sized to a ~1k-token budget so it's prompt-cache-friendly. See [User Profiles](/concepts/user-profiles). -- **Hybrid search you can tune.** Semantic + keyword + graph in one query, with `rewriteQuery`, `rerank`, and `threshold` knobs when defaults aren't enough. See [Hybrid Search](/concepts/hybrid-search). -- **Real permissioning.** Container tags for hard isolation, metadata filters for dimensions inside it, scoped keys to enforce both. See [Permissioning](/concepts/permissioning). - -## Why retrieval alone isn't memory - -Say a user talks to your agent over six weeks: - -```text -Day 1: "I love my Adidas sneakers" -Day 30: "My Adidas broke after a month, terrible quality" -Day 31: "I'm switching to Puma" -Day 45: "What sneakers should I buy?" -``` - -A vector store answers day 45 by finding the most similar text. "I love my Adidas sneakers" is the closest match to a sneaker question — so your agent recommends Adidas to someone who quit the brand two weeks earlier. - -Supermemory tracks the progression instead: the day-1 preference was invalidated by day 30, and the day-31 statement is what's true now. Ask it: - - - -```typescript TypeScript -const results = await client.search.memories({ - q: "what sneakers does this user like?", - containerTag: "user_4f8a", -}); -``` - -```python Python -results = client.search.memories( - q="what sneakers does this user like?", - container_tag="user_4f8a", -) -``` - -```bash cURL -# POST /v4/search -curl -X POST "https://api.supermemory.ai/v4/search" \ - -H "Authorization: Bearer $SUPERMEMORY_API_KEY" \ - -H "Content-Type: application/json" \ - -d '{"q": "what sneakers does this user like?", "containerTag": "user_4f8a"}' -``` - - - -And you get back what's true now: - -```json -{ - "results": [ - { - "memory": "Switched from Adidas to Puma after quality issues", - "similarity": 0.89, - "updatedAt": "2026-06-30T…" - }, - … - ] -} -``` - -The outdated Adidas preference is **not** returned as if it were still true — it's been superseded. If you want the history anyway (superseded facts are useful for "why" questions), pass `include: { forgottenMemories: true }` and you'll get them back, marked as forgotten. - -RAG answers "what do I know?". Memory answers "what's true about this user *right now*?". Supermemory does both — the same search endpoint reaches document chunks when you need raw retrieval. The full comparison is in [Memory vs RAG](/concepts/memory-vs-rag). - -## One engine, many doors - -The API and SDKs, MCP, plugins and hooks, the SMFS filesystem mount, connectors, and Company Brain are all doors into the same engine — one store of memories, one graph, one set of profiles. Anything ingested through any door is retrievable through every other door. - -```mermaid -flowchart TD - A["API & SDKs"] --> G - B["MCP"] --> G - C["Plugins & hooks"] --> G - D["SMFS
filesystem mount"] --> G - E["Connectors"] --> G - F["Company Brain"] --> G - G[("One engine
memories · graph · profiles")] -``` - -- **[API & SDKs](/quickstart)** — TypeScript, Python, and REST. The primitives everything else is built on. -- **[MCP](/supermemory-mcp/setup)** — give Claude, Cursor, or any MCP client persistent memory. -- **[Plugins & hooks](/integrations/ai-sdk)** — `withSupermemory` wraps your model so memory happens automatically per request. -- **[SMFS](/smfs/overview)** — mount memory as a filesystem for coding agents; each mount is scoped to one container tag. -- **[Connectors](/connectors/overview)** — sync Google Drive, Notion, OneDrive, and more on a schedule. -- **[Company Brain](/patterns/company-brain)** — team knowledge across all of the above, no code required. - -So there's no "which product am I using?" decision. A memory added through MCP shows up in an API search. A document synced from Notion is on your team's Company Brain. Pick doors by workflow, not by feature. - -## Does it actually work? - -- **Benchmarks:** supermemory is [state of the art](https://supermemory.ai/research) on LongMemEval and LoCoMo. -- **Latency:** profile reads ~100ms; search P50 ~300ms, P99 ~400ms. -- **Don't take our word for it:** [MemoryBench](/memorybench/quickstart) is our open benchmarking harness — run it against your own workload and reproduce the results yourself. - - -Search doesn't add to your bill — you're charged on ingestion, and recall is essentially free. The billing model is covered in [Usage and Billing](/trust/usage-and-billing). - + + + Add four scattered memories, then watch supermemory connect them into an answer you never stated. + + + The custom memory model, the graph, and where the milliseconds go. + + ## Pick your door - - - Add your first memory, search it, and wire context into your app. +Every surface below is a door into the same engine — one store of memories, one graph, one set of profiles. Anything that goes in through one door comes out through all of them. + + + + Full control from your own backend. TypeScript, Python, REST. - - Connect Claude, Cursor, or any MCP client — or drop in the [AI SDK plugin](/integrations/ai-sdk). + + Give Claude, Cursor, and ChatGPT your memory. No code. - - Company Brain: shared memory across your docs, drives, and conversations. + + Auto-inject memory into Claude Code, Codex, and OpenClaw. - - Self-host supermemory on your own infrastructure. + + Notion, Google Drive, Gmail, OneDrive, S3 — content flows in on its own. + + + Mount memory as a filesystem for agents that think in files. + + + From a free local binary to air-gapped enterprise deploys. + +## Go deep + + + + Multi-tenant SaaS memory, AI companions, multi-agent systems, company brains — full patterns with code. + + + Every endpoint, parameter, and response shape. + + + Container tags, metadata, scoped keys — real isolation, designed in. + + + Why retrieval alone recommends Adidas to someone who switched to Puma two weeks ago. + + + +## Why supermemory + +Most "memory layers" are a vector store that retrieves the nearest chunk. Supermemory understands what it stores: facts carry time, entities connect across sessions, contradictions resolve to what's true *now*, and irrelevant details fade. + +- **State of the art** on LongMemEval and LoCoMo — and [MemoryBench](/memorybench/overview) lets you reproduce the numbers yourself. +- **Fast enough for the hot path**: profile reads ~100ms, search P50 ~300ms. +- **Yours to run**: the same engine powers the cloud API, a free local binary, and on-prem enterprise deploys. diff --git a/apps/docs/overview/use-cases.mdx b/apps/docs/use-cases.mdx similarity index 100% rename from apps/docs/overview/use-cases.mdx rename to apps/docs/use-cases.mdx