Agentic AI Atlasby a5c.ai
OverviewWikiGraphFor AgentsEdgesSearchWorkspace
/
GitHubDocsDiscord
iiRecord
Agentic AI Atlas · Supermemory Deep Research
page:docs-supermemory-researcha5c.ai
Search record views/
Record · tabs

Available views

II.Record viewspp. 1 - 1
overviewarticlejsongraph
II.
Page JSON

page:docs-supermemory-research

Structured · live

Supermemory Deep Research json

Inspect the normalized record payload exactly as the atlas UI reads it.

File · wiki/docs/supermemory-research.mdCluster · wiki
Record JSON
{
  "id": "page:docs-supermemory-research",
  "_kind": "Page",
  "_file": "wiki/docs/supermemory-research.md",
  "_cluster": "wiki",
  "attributes": {
    "nodeKind": "Page",
    "sourcePath": "docs/supermemory-research/README.md",
    "sourceKind": "repo-docs",
    "title": "Supermemory Deep Research",
    "displayName": "Supermemory Deep Research",
    "slug": "docs/supermemory-research",
    "articlePath": "wiki/docs/supermemory-research/README.md",
    "article": "\n# Supermemory Deep Research\n\n## Executive Summary\n\nSupermemory is a cloud memory engine and context layer for AI agents, ranking #1\non all three major AI memory benchmarks (LongMemEval, LoCoMo, ConvoMem). It\nprovides automatic memory extraction, a knowledge graph with relationship tracking,\nuser profile synthesis, hybrid search (RAG + semantic memory), and multi-modal\ncontent processing. Its most distinctive feature is SMFS (Semantic Memory File\nSystem), which exposes memory containers as mountable directories where `grep`\nbecomes semantic search and `cat profile.md` returns a live-synthesized digest.\n\nSupermemory addresses critical gaps in our current genty memory stack: we have\nno semantic search, no contradiction resolution, no knowledge graph relationships,\nno multi-modal extraction, and no user profile synthesis. Our memory pipeline\n(`memoryExtraction.ts` + `memoryConsolidation.ts`) uses Jaccard word-set\nsimilarity for deduplication and filter-based retrieval -- effective for small\nmemory stores but fundamentally limited compared to Supermemory's approach.\n\n**Recommendation**: Integrate Supermemory as the memory backend for genty agent\nruns via SMFS (filesystem mount for local, virtual bash tool for serverless).\nThis provides semantic memory transparently without requiring agents to learn\nnew tools.\n\n## Architecture Comparison\n\n### Our Memory Stack\n\n```\n                    genty memory architecture\n                    -------------------------\n\n  Session Messages\n        |\n        v\n  extractMemoriesFromSession()     -- LLM extracts MemoryEntry objects\n        |                             (category, confidence, tags)\n        v\n  persistMemories()                -- Append to long-term-memory.json\n        |                             (max 500 entries, dedup by ID)\n        v\n  consolidateMemories()            -- Jaccard similarity dedup (0.4 threshold)\n        |                             Rank by confidence + recency\n        v                             Prune to 200 entries\n  queryMemories()                  -- Filter by category / tags / limit\n        |\n        v\n  crossRunState.ts                 -- Key-value JSON store for orchestration state\n```\n\n**Strengths**: Fully local, instant latency, offline-capable, simple model.\n\n**Weaknesses**: No semantic search, no contradiction handling, no relationship\ntracking, no multi-modal support, filter-only retrieval, manual extraction,\nstatic deduplication heuristic.\n\n### Supermemory Architecture\n\n```\n                    supermemory architecture\n                    -----------------------\n\n  Content (text/files/URLs/images/video)\n        |\n        v\n  POST /v3/documents               -- Ingest with containerTag + metadata\n        |\n        v\n  Processing Pipeline              -- Queued -> Extracting -> Chunking\n        |                             -> Embedding -> Indexing -> Done\n        v\n  Knowledge Graph                  -- Update (supersedes)\n        |                             Extend (enriches)\n        |                             Derive (infers)\n        v\n  Three Retrieval Paths:\n    1. Memory API                  -- Evolved user facts, temporal awareness\n    2. User Profiles               -- Static + dynamic digest (~50ms)\n    3. RAG Search                  -- Semantic + metadata filtering\n        |\n        v\n  SMFS Interface                   -- Mount as directory\n        |                             grep = semantic search\n        |                             cat profile.md = live digest\n        v\n  MCP Server                      -- addMemory, search, getProjects, whoAmI\n```\n\n**Strengths**: Semantic search, knowledge graph, contradiction resolution,\ntemporal decay, multi-modal, user profiles, benchmark-proven accuracy.\n\n**Weaknesses**: Requires network, cloud dependency, latency overhead (~50ms\nminimum), cost per query.\n\n## Feature Parity Matrix\n\n| Feature                          | Genty (Current)               | Supermemory                    | Status        |\n|----------------------------------|-------------------------------|--------------------------------|---------------|\n| Memory extraction                | LLM-extracted MemoryEntry     | Automatic from any content     | Partial       |\n| Memory storage                   | Local JSON file               | Cloud knowledge graph          | Different     |\n| Semantic search                  | None                          | Core feature                   | Gap           |\n| Keyword/filter retrieval         | Category + tags               | Metadata filtering             | Parity        |\n| Contradiction resolution         | None                          | Automatic via Update relations | Gap           |\n| Temporal decay                   | Manual prune by count         | Brain-inspired decay curves    | Gap           |\n| Knowledge relationships          | None                          | Update / Extend / Derive       | Gap           |\n| Multi-modal extraction           | None                          | PDF, image (OCR), video, code  | Gap           |\n| User profile synthesis           | None                          | Static + dynamic digest        | Gap           |\n| Cross-run state                  | Key-value JSON store          | Container persistence          | Parity        |\n| Deduplication                    | Jaccard similarity (0.4)      | Knowledge graph dedup          | Partial       |\n| Offline operation                | Full                          | None (cloud-only)              | Our advantage |\n| Retrieval latency                | ~0ms (local JSON)             | ~50ms (cloud API)              | Our advantage |\n| Max memory entries               | 200-500                       | Billions                       | Gap           |\n| MCP integration                  | Client (consumer)             | Server (provider)              | Complementary |\n| Filesystem interface             | None                          | SMFS (NFS/FUSE mount)          | Gap           |\n| Connectors                       | None                          | 7 (GitHub, Gmail, Drive, etc.) | Gap           |\n| Framework integrations           | Internal only                 | 15+ (LangChain, CrewAI, etc.) | Gap           |\n| Benchmarking                     | None                          | MemoryBench framework          | Gap           |\n| Cost                             | Free (local compute)          | API pricing                    | Our advantage |\n\n## Integration Strategy\n\n### Preferred: SMFS as Transparent Memory Backend\n\nThe recommended integration path is SMFS, which provides semantic memory\nthrough standard filesystem operations. This requires no changes to agent\nprompts or tool definitions -- agents already know how to `ls`, `cat`, `grep`,\nand `echo >`.\n\n**For local runs** (development, CI): Mount SMFS at run start.\n```bash\nsmfs mount \"babysitter-${userId}-${projectId}\" \\\n  --memory-paths \"/decisions/,/findings/,/patterns/,/architecture/\"\n```\n\n**For serverless runs** (Kradle, Lambda): Use the virtual bash tool.\n```typescript\nimport { createBash } from \"@supermemory/bash\";\nconst { bash } = await createBash({\n  apiKey: process.env.SUPERMEMORY_API_KEY,\n  containerTag: `run-${userId}-${projectId}`,\n});\n```\n\n### Complementary: REST API for Orchestrator\n\nThe orchestrator (genty-platform) uses the REST API for structured operations:\n- **Run start**: `client.profile()` to inject cross-run context into system prompt\n- **Run end**: `client.add()` to persist run outcomes as memories\n- **Search**: `client.search.memories()` for targeted retrieval with metadata filters\n\n### Not Replaced: crossRunState.ts\n\nThe cross-run state store handles structured orchestration state (checkpoints,\nphases, counters). This is a state machine concern, not a memory concern.\nSupermemory does not replace it.\n\n### Not Replaced: Local-Only Mode\n\nFor air-gapped or offline deployments, the existing `memoryExtraction.ts` +\n`memoryConsolidation.ts` pipeline remains available as the local-only memory\nbackend. The integration should be additive, not a replacement.\n\n## Related Files\n\n- Raw documentation: `docs/supermemory-research/raw/`\n- Layer analysis: `docs/supermemory-research/layer-analysis.md`\n- Integration plan: `docs/supermemory-research/integration-plan.md`\n- Atlas graph nodes: `packages/atlas/graph/agent-stack/supermemory/`\n",
    "documents": []
  },
  "outgoingEdges": [
    {
      "from": "page:docs-supermemory-research",
      "to": "page:docs-supermemory-research-integration-plan",
      "kind": "contains_page"
    },
    {
      "from": "page:docs-supermemory-research",
      "to": "page:docs-supermemory-research-layer-analysis",
      "kind": "contains_page"
    },
    {
      "from": "page:docs-supermemory-research",
      "to": "page:docs-supermemory-research-raw-01-docs-index",
      "kind": "contains_page"
    },
    {
      "from": "page:docs-supermemory-research",
      "to": "page:docs-supermemory-research-raw-02-smfs-overview",
      "kind": "contains_page"
    },
    {
      "from": "page:docs-supermemory-research",
      "to": "page:docs-supermemory-research-raw-03-smfs-github",
      "kind": "contains_page"
    },
    {
      "from": "page:docs-supermemory-research",
      "to": "page:docs-supermemory-research-raw-04-introduction",
      "kind": "contains_page"
    },
    {
      "from": "page:docs-supermemory-research",
      "to": "page:docs-supermemory-research-raw-05-api-reference",
      "kind": "contains_page"
    },
    {
      "from": "page:docs-supermemory-research",
      "to": "page:docs-supermemory-research-raw-06-concepts",
      "kind": "contains_page"
    },
    {
      "from": "page:docs-supermemory-research",
      "to": "page:docs-supermemory-research-raw-07-mcp-server",
      "kind": "contains_page"
    },
    {
      "from": "page:docs-supermemory-research",
      "to": "page:docs-supermemory-research-raw-08-quickstart",
      "kind": "contains_page"
    },
    {
      "from": "page:docs-supermemory-research",
      "to": "page:docs-supermemory-research-raw-09-github-readme",
      "kind": "contains_page"
    },
    {
      "from": "page:docs-supermemory-research",
      "to": "page:docs-supermemory-research-raw-10-memory-engine-architecture",
      "kind": "contains_page"
    },
    {
      "from": "page:docs-supermemory-research",
      "to": "page:docs-supermemory-research-raw-11-smfs-benchmarks",
      "kind": "contains_page"
    },
    {
      "from": "page:docs-supermemory-research",
      "to": "page:docs-supermemory-research-raw-12-memorybench",
      "kind": "contains_page"
    },
    {
      "from": "page:docs-supermemory-research",
      "to": "page:docs-supermemory-research-raw-13-crewai-integration",
      "kind": "contains_page"
    }
  ],
  "incomingEdges": [
    {
      "from": "page:docs",
      "to": "page:docs-supermemory-research",
      "kind": "contains_page"
    }
  ]
}

Shortcuts

Back to overview
Open graph tab