Feature Guide Template
Use this when you introduce or deepen a single Mem0 capability (Graph Memory, Advanced Retrieval, etc.). Aim for crisp problem framing, a walkthrough of how the feature works, and practical configuration guidance with clear exits.Reader Promise
- Understand the pain the feature solves and when to reach for it.
- See how to enable, configure, and observe the feature in action.
- Know the next conceptual deep dive and a hands-on example to try.
Start → Middle → End Pattern
1. Start – Why this feature exists
- Frontmatter stays outcome-driven:
title,description,icon, optionalbadge(e.g., “Advanced”). - Opening paragraph = two sentences: problem, then payoff. Keep energy high right from the start.
- Include an
<Info>block titled “You’ll use this when…” with 3 bullets (user persona, workload, expected benefit). - When reshaping legacy feature docs, carry over existing diagrams, tables, and gotchas—organize them under these headings rather than replacing them unless the product has changed.
- If there’s a known caveat (pricing, performance), surface it early in a
<Warning>so readers don’t get surprised later. - Optional but encouraged: add a Mermaid diagram right after the intro to show how components connect; delete it if the story is obvious without visuals.
- Add a
## Configure accesssnippet (even if it’s “Confirm your Mem0 API key is already configured”) so contributors never forget to mention the baseline setup.
2. Middle – How it works
- Create three predictable sections:
- Feature anatomy – Diagram or bullet list of moving parts. Use a table if you need to compare modes (platform vs OSS).
- Configure it – Step-by-step enabling instructions with
<CodeGroup>or JSON/YAML snippets. Follow each code block with a short explanation of why it matters. - See it in action – End-to-end example (often reusing operation snippets). Pair code with
<Info icon="check">for expected results and<Tip>for optimization hints.
- Insert
<Note>blocks for cross-links (e.g., “Also available via REST endpoint/v1/...”). - Keep the tone instructive but light—no long manifestos.
3. End – Evaluate and go deeper
- Add an
## Verify the feature is workingsection with bullets (metrics, logs, dashboards). - Follow with
## Best practicesor## Tuning tips(3–4 bullets max). - Close with the standard two-card CTA pair: left card = related concept or architecture page, right card = cookbook/application. Keep the comment reminder to double-check links.
- If providers differ meaningfully, summarize them in a final accordion (
<AccordionGroup>with one<Accordion>per provider) so readers can expand what they need without scrolling walls of configuration.
Markdown Skeleton
Feature anatomy
- Outline the moving parts (retriever, reranker, filters).
- Add a table comparing default vs advanced behavior.
Configure it
rerank_top_k, criteria, filters).
OSS users can mirror this by enabling the reranker in
config.yaml. Link to the integration guide if relevant.See it in action
Walk through a real request/response. Include sample payloads and highlight notable fields.Expect the top memory to match the user persona you set earlier. If not, revisit your filters.
Provider setup
[Provider name]
[Provider name]
Outline configuration or link to provider docs here.
Verify the feature is working
- Watch the dashboard analytics for retrieval latency changes.
- Check logs for
reranker_applied: true.
Best practices
- Keep criteria minimal—overfiltering hurts recall.
- Pair with Memory Filters v2 for hybrid scoring.
Dive Into Memory Scoring
Understand how Mem0 ranks memories under the hood.
Build a Research Copilot
See advanced retrieval driving a full knowledge assistant.