mirror of
https://github.com/supermemoryai/supermemory.git
synced 2026-09-05 08:06:19 +00:00
docs: reposition nav around capabilities, demote delivery surfaces
Reorder the Developer Platform sidebar so readers see what Supermemory DOES before how they access it (Diátaxis / progressive-disclosure): - Promote core features (add/search/profiles/manage) to right after Getting Started, renamed "Core Features" - Demote Self-Hosting, Command Line (CLI), and SMFS to the bottom as discoverable sections rather than top-of-sidebar groups Rework the Overview page to actually sell and to be the discovery point for secondary surfaces: a capabilities card grid up top, a "Start building" row, and a "Ways to use Supermemory" row (SDKs, CLI, filesystem, self-host) so they're a delightful find, not prime real estate. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Dhravya Shah
parent
d62d9cc5ac
commit
914191d13b
2 changed files with 101 additions and 80 deletions
|
|
@ -72,17 +72,17 @@
|
|||
"pages": ["intro", "quickstart", "vibe-coding"]
|
||||
},
|
||||
{
|
||||
"group": "Command Line (CLI)",
|
||||
"icon": "square-terminal",
|
||||
"pages": ["cli/overview", "cli/commands", "cli/local"]
|
||||
},
|
||||
{
|
||||
"group": "Self-Hosting",
|
||||
"group": "Core Features",
|
||||
"pages": [
|
||||
"self-hosting/overview",
|
||||
"self-hosting/quickstart",
|
||||
"self-hosting/configuration",
|
||||
"self-hosting/local-vs-enterprise"
|
||||
"add-memories",
|
||||
"search",
|
||||
"user-profiles",
|
||||
{
|
||||
"group": "Manage Content",
|
||||
"icon": "folder-cog",
|
||||
"pages": ["document-operations", "memory-operations"]
|
||||
},
|
||||
"overview/use-cases"
|
||||
]
|
||||
},
|
||||
{
|
||||
|
|
@ -100,20 +100,6 @@
|
|||
"authentication"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Using supermemory",
|
||||
"pages": [
|
||||
"add-memories",
|
||||
"search",
|
||||
"user-profiles",
|
||||
{
|
||||
"group": "Manage Content",
|
||||
"icon": "folder-cog",
|
||||
"pages": ["document-operations", "memory-operations"]
|
||||
},
|
||||
"overview/use-cases"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Connectors and sync",
|
||||
"pages": [
|
||||
|
|
@ -136,6 +122,30 @@
|
|||
"memory-api/connectors/managing-resources"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Migration Guides",
|
||||
"pages": [
|
||||
{
|
||||
"group": "From another provider",
|
||||
"icon": "truck",
|
||||
"pages": ["migration/from-mem0", "migration/from-zep"]
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Self-Hosting",
|
||||
"pages": [
|
||||
"self-hosting/overview",
|
||||
"self-hosting/quickstart",
|
||||
"self-hosting/configuration",
|
||||
"self-hosting/local-vs-enterprise"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Command Line (CLI)",
|
||||
"icon": "square-terminal",
|
||||
"pages": ["cli/overview", "cli/commands", "cli/local"]
|
||||
},
|
||||
{
|
||||
"group": "SMFS (Memory Filesystem)",
|
||||
"icon": "database",
|
||||
|
|
@ -157,16 +167,6 @@
|
|||
},
|
||||
"smfs/examples"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Migration Guides",
|
||||
"pages": [
|
||||
{
|
||||
"group": "From another provider",
|
||||
"icon": "truck",
|
||||
"pages": ["migration/from-mem0", "migration/from-zep"]
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
|
|
|
|||
|
|
@ -4,15 +4,34 @@ sidebarTitle: "Overview"
|
|||
icon: "book-open"
|
||||
---
|
||||
|
||||
Supermemory is the long-term and short-term memory and context infrastructure for AI agents. It is the [state of the art](https://supermemory.ai/research) across multiple different benchmarks, like LongMemEval and LoCoMo.
|
||||
Supermemory is the long-term and short-term memory and context infrastructure for AI agents. It is the [state of the art](https://supermemory.ai/research) across multiple benchmarks, including LongMemEval and LoCoMo.
|
||||
|
||||
With supermemory, developers can provide perfect recall about their users to build AI agents that are more intelligent, more personalized, and more consistent. Additionally, *supermemory* has all the pieces of the context stack built in:
|
||||
- [Agent memory](/concepts/graph-memory)
|
||||
- [Content extraction](/concepts/content-types)
|
||||
- [Connectors and syncing](/connectors/overview)
|
||||
- [Managed RAG platform](/concepts/super-rag)
|
||||
With supermemory, you give your agents perfect recall about their users — so they're more intelligent, more personalized, and more consistent. Every piece of the context stack is built in, behind one API.
|
||||
|
||||
All this, coming together, makes supermemory the best abstraction to provide to agents.
|
||||
## What you can build with it
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Agent memory" icon="brain" href="/concepts/graph-memory">
|
||||
Extract and evolve facts about each user over time — knowledge updates, temporal changes, automatic forgetting.
|
||||
</Card>
|
||||
<Card title="User profiles" icon="user-round" href="/concepts/user-profiles">
|
||||
A live blend of static and dynamic context your agent should always know, built automatically from memory.
|
||||
</Card>
|
||||
<Card title="Hybrid search (RAG)" icon="search" href="/search">
|
||||
Semantic search with metadata filtering, contextual chunking, and reranking — over memories and raw documents in one query.
|
||||
</Card>
|
||||
<Card title="Content extraction" icon="file-text" href="/concepts/content-types">
|
||||
Ingest text, conversations, PDFs, images, and even video — all turned into searchable, structured context.
|
||||
</Card>
|
||||
<Card title="Connectors and sync" icon="plug" href="/connectors/overview">
|
||||
Continuously pull from Google Drive, Notion, Gmail, OneDrive, and more, with no pipeline to maintain.
|
||||
</Card>
|
||||
<Card title="Managed RAG platform" icon="layers" href="/concepts/super-rag">
|
||||
Production-grade retrieval as a service, tuned to work alongside the memory engine.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
All of it shares the **same context pool** for a given user (`containerTag`), so memory and search reinforce each other instead of living in separate silos.
|
||||
|
||||
## How does it work? (at a glance)
|
||||
|
||||
|
|
@ -22,68 +41,70 @@ All this, coming together, makes supermemory the best abstraction to provide to
|
|||
- Supermemory [intelligently indexes them](/concepts/how-it-works) and builds a semantic understanding graph on top of an entity (e.g., a user, a document, a project, an organization).
|
||||
- At query time, we fetch only the most relevant context and pass it to your models.
|
||||
|
||||
## Supermemory is context engineering.
|
||||
## Supermemory is context engineering
|
||||
|
||||
#### Ingestion and Extraction
|
||||
We offer three ways to add context to your LLMs — mix and match them as your use case needs.
|
||||
|
||||
Supermemory handles all the extraction, for [any data type that you have](/concepts/content-types).
|
||||
- Text
|
||||
- Conversations
|
||||
- Files (PDF, Images, Docs)
|
||||
- Even videos!
|
||||
|
||||
... and then,
|
||||
|
||||
We offer three ways to add context to your LLMs:
|
||||
|
||||
#### Memory API — Learned user context
|
||||
#### Memory API — learned user context
|
||||
|
||||
|
||||
|
||||
Supermemory learns and builds the memory for the user. These are extracted facts about the user, that:
|
||||
Supermemory learns and builds memory for each user. These are extracted facts that:
|
||||
- [Evolve on top of existing context about the user](/concepts/graph-memory), **in real time**
|
||||
- Handle **knowledge updates, temporal changes, forgetfulness**
|
||||
- Creates a **user profile** as the default context provider for the LLM.
|
||||
- Handle **knowledge updates, temporal changes, and forgetfulness**
|
||||
- Power a **user profile** that acts as the default context provider for the LLM
|
||||
|
||||
_This can then be provided to the LLM, to give more contextual, personalized responses._
|
||||
_Provide this to your LLM for more contextual, personalized responses._
|
||||
|
||||
#### User profiles
|
||||
|
||||
Having the latest, evolving context about the user allows us to also create a [**User Profile**](/concepts/user-profiles). This is a combination of static and dynamic facts about the user, that the agent should **always know**
|
||||
Developers can configure supermemory with what static and dynamic contents are, depending on their use case.
|
||||
The latest, evolving context about a user also produces a [**User Profile**](/concepts/user-profiles) — static and dynamic facts the agent should **always** know:
|
||||
|
||||
- Static: Information that the agent should **always** know.
|
||||
- Dynamic: **Episodic** information, about last few conversations etc.
|
||||
- **Static:** information the agent should **always** know.
|
||||
- **Dynamic:** **episodic** information about the last few conversations.
|
||||
|
||||
This leads to a much better retrieval system, and extremely personalized responses.
|
||||
Configure what counts as static vs. dynamic for your use case for extremely personalized retrieval.
|
||||
|
||||
#### RAG - Advanced semantic search
|
||||
#### RAG — advanced semantic search
|
||||
|
||||
Along with the user context, developers can also choose to do a search on the raw context. We provide full RAG-as-a-service, along with
|
||||
- Full advanced metadata filtering
|
||||
Alongside user context, run search over the raw content. Full RAG-as-a-service, with:
|
||||
- Advanced metadata filtering
|
||||
- Contextual chunking
|
||||
- Works well with the memory engine
|
||||
|
||||
<Info>
|
||||
See the full API Reference tab for detailed endpoint documentation.
|
||||
</Info>
|
||||
|
||||
- Tight integration with the memory engine
|
||||
|
||||
<Note>
|
||||
All three approaches share the **same context pool** when using the same user ID (`containerTag`). You can mix and match based on your needs.
|
||||
All three approaches share the **same context pool** when using the same user ID (`containerTag`). Mix and match based on your needs.
|
||||
</Note>
|
||||
|
||||
## Next steps
|
||||
## Start building
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<CardGroup cols={3}>
|
||||
<Card title="Quickstart" icon="play" href="/quickstart">
|
||||
Make your first API call in minutes
|
||||
Make your first API call in minutes.
|
||||
</Card>
|
||||
<Card title="How it Works" icon="cpu" href="/concepts/how-it-works">
|
||||
Understand the knowledge graph architecture
|
||||
<Card title="Add your first memory" icon="plus" href="/add-memories">
|
||||
Ingest text, files, and conversations into a container.
|
||||
</Card>
|
||||
<Card title="Self-host it" icon="server" href="/self-hosting/overview">
|
||||
Run Supermemory on your own machine — one binary, zero config, fully offline
|
||||
<Card title="Search it" icon="search" href="/search">
|
||||
Retrieve the most relevant context with hybrid semantic search.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## Ways to use Supermemory
|
||||
|
||||
The API is the core — but you don't have to talk to it directly. Reach Supermemory however fits your workflow:
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="SDKs" icon="code" href="/integrations/supermemory-sdk">
|
||||
Official TypeScript and Python SDKs, plus drop-in plugins for the AI SDK, OpenAI, LangChain, and more.
|
||||
</Card>
|
||||
<Card title="Command line (CLI)" icon="square-terminal" href="/cli/overview">
|
||||
Manage memories, search, and scripting from your terminal — it's all `npx supermemory`.
|
||||
</Card>
|
||||
<Card title="Memory filesystem (SMFS)" icon="database" href="/smfs/overview">
|
||||
Mount a container as a real directory your agent can `ls`, `cat`, and semantically `grep`.
|
||||
</Card>
|
||||
<Card title="Self-host it" icon="server" href="/self-hosting/overview">
|
||||
Run the full memory engine on your own machine — one binary, zero config, fully offline.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue