Cognee / Supermemory: When Memory Becomes a Platform Boundary

Inside one agent, memory can sound like a narrow task: save what the user said and search it next time. A deployed product makes the boundary heavier. Content arrives from chats, files, web pages, drives, code repositories, and SaaS connectors. Processing may be queued. Results need user, project, or tenant scoping. Deletion has to be operational. Cognee and Supermemory are useful because they make those platform duties visible.

Scenario: a team knowledge assistant needs long-term memory

Inputs are no longer only chat:
  meeting notes, design docs, web pages, Google Drive, GitHub issues, support history

Callers are no longer only one agent:
  chat agent, search page, ticket assistant, coding assistant, background sync worker

The platform must answer:
  Who owns this content?
  Which processing stage is it in?
  Should retrieval return a profile, evidence snippets, or graph relations?
  When the user withdraws data, what exactly must be deleted?

That is why Cognee and Supermemory should not be read as merely bigger RAG systems. They expose memory platform contracts: how data enters, how it is processed, how retrieval stays scoped, and how several callers can reuse the same memory layer safely.

A single document makes the contrast easier: a “customer escalation policy.” In Cognee, the question is how that document becomes reusable knowledge. In Supermemory, the question is how a product gets profile, search, and connector context through an API. The lifecycle table below lines up the two routes before the chapter studies them separately.

1. Why The Last Chapter Is About Platforms

1.1 The Earlier Layers Reappear At Platform Scale

Cognee and Supermemory are easier to read after the lower layers are clear. Otherwise both can be mistaken for larger RAG products. In this series order, they answer the next question: after write policies, state ownership, temporal graphs, execution paths, and context offload are known, what happens when memory becomes a shared service?

At platform scale, memory is no longer a capability of one agent. A product may ingest chats, documents, webpages, email, code repositories, and third-party apps. The same object may belong to a user, team, project, dataset, or tenant. A query may need a user profile, similar snippets, related files, graph relations, and permission-filtered evidence. Cognee and Supermemory therefore ask how long-term memory becomes infrastructure that several users, data sources, and callers can rely on.

1.2 The Hard Part Is Boundary Ownership, Not Recall Alone

A memory platform has at least four public duties. Scope: user, project, dataset, and tenant boundaries. Process: extraction, chunking, embedding, graphing, indexing, or profile generation. Retrieve: returning graph context, user profiles, related documents, or model-ready context instead of only text chunks. Delete: giving callers a boundary they can remove when content, projects, or users are withdrawn.

Those duties map directly to common failures. If scope is unclear, one user's material can leak into another user's context. If process state is unclear, callers cannot tell whether content is queued, extracted, chunked, embedded, or indexed. If retrieval contracts are unclear, profile facts, evidence, and document snippets blur into one list. If deletion boundaries are unclear, disconnected connectors can keep influencing the model. The platform value is moving those responsibilities out of ad hoc application prompts.

2. Cognee: Turn Data Into A Reusable Knowledge Layer

Cognee presents itself as an open-source AI memory platform: ingest data in any format, build a self-hosted knowledge graph, and let agents recall and act with context. Its README also names vector embeddings, graph reasoning, and ontology generation. That positions Cognee as more than a vector index wrapper; it is trying to turn raw material into a connected intermediate layer. See the README overview.

2.1 The User API Is Simple; The Platform Pipeline Is Not

The current quickstart gives users four verbs: remember, recall, forget, and improve. remember() can store permanently in the knowledge graph, or store in a fast session memory when a session_id is supplied. recall() then routes a natural language query. The public shape is intentionally light; the pipeline under it is where the work happens.

The source makes that layering explicit. The remember() docstring splits permanent memory from session memory. Permanent memory runs add() plus cognify(); session memory stores in a session cache and, by default, bridges into the permanent graph through self-improvement. The permanent path's internal _run() calls add(...), then cognify(...), then optionally improve(...).

async def remember(data, dataset_name="main_dataset", session_id=None, self_improvement=True):
    if session_id:
        # session memory: fast cache, then optional bridge into permanent graph
        ...

    async def _run():
        await add(data=data, dataset_name=dataset_name, ...)
        cognify_result = await cognify(datasets=[dataset_name], ...)

        if self_improvement:
            await improve(dataset=dataset_name, user=user)

This makes the public API easier to reason about. remember() is the facade. add() owns ingestion, cognify() turns material into graph and vector-searchable structure, and improve() enriches it later. The caller sees one verb; the platform keeps explicit stages.

2.2 add And cognify Are The Real Boundary

add() accepts strings, files, URLs, binary streams, and datasets. Its documented workflow resolves data, extracts content, stores it in a dataset, tracks metadata, and assigns permissions. Cognee therefore begins before retrieval: it first makes ingestion a platform concern.

cognify() is the transformation step. Its docstring describes document classification, text chunking, entity extraction, relationship detection, graph construction, and content summarization. The point is not that a graph is always better than vectors. The point is that raw content becomes a reusable knowledge layer that several agents and search strategies can share.

Retrieval then exposes that layer. search() takes query type, datasets, node filters, neighborhood controls, references, and ranking parameters. Its documentation names GRAPH_COMPLETION, RAG_COMPLETION, CHUNKS, CYPHER, and lexical chunk search. The caller is not only asking for similar text; it is choosing how to interrogate the knowledge layer.

await add(data, dataset_name="company_docs")

await cognify(
    datasets=["company_docs"],
    graph_model=KnowledgeGraph,
    chunker=TextChunker,
)

results = await search(
    query_text="How should we handle customer escalation?",
    query_type=SearchType.GRAPH_COMPLETION,
    datasets=["company_docs"],
    include_references=True,
)

Shape-level example: one document moving through Cognee

add / remember:
  source = "Customer escalation policy..."
  dataset = "company_docs"

cognify:
  the dataset is chunked, entities and relationships are extracted,
  and graph / vector retrieval layers are built

search:
  query = "Who should receive a customer escalation?"
  results come from the processed knowledge layer and can include references

Read through this chain and Cognee stops looking like "upload a file and vector-search it." add places material into a dataset; cognify performs classification, chunking, entity and relation extraction, and graph construction; search lets the caller choose graph answer, RAG answer, chunk search, Cypher, or lexical retrieval.

2.3 Cognee Fits Domain Knowledge That Must Be Reused

Cognee fits cases where an organization has documents, code, customer history, or expert patterns that should not be pasted into prompts turn by turn. The material should first be processed, connected, scoped, and made reusable. That is why its README examples lean toward company brain, customer support, and expert knowledge distillation scenarios.

The cost follows from the same design. A heavier knowledge layer brings processing latency, dataset permissions, graph schema choices, ontology questions, search modes, and deployment responsibilities. For a small user preference, this may be too much. For shared domain knowledge that many agents need to revisit, the Cognee route is natural.

2.4 Cognee Is A Knowledge Processing Layer, Not Lightweight Preference Storage

A useful test is whether the material deserves to become an intermediate knowledge layer. The answer is usually yes when the material will be reused by several agents or workflows, when relationships and provenance matter more than a single text span, and when self-hosting or governance of the processing chain matters. If those signals are weak, datasets, cognify, graph search, and ontology choices may be unnecessary weight.

When those signals are strong, Cognee's benefit is not merely another search mode. It moves source material out of temporary prompts and into a reusable knowledge layer that can be improved, searched again, scoped by dataset, and shared by different agents working over the same organizational knowledge.

3. Supermemory: Package Memory As A Context API

Supermemory's README describes a memory and context layer for AI, with memory, user profiles, hybrid search, connectors, and multi-modal extractors in one stack. It also pitches a single API for AI products. That shifts the center of gravity from designing your own graph pipeline to consuming a productized context surface. See the README opening and developer quickstart.

3.1 add Starts Memory Extraction, Not Just Storage

The docs tell callers to send raw content: conversations, documents, files, and URLs. Supermemory extracts memories automatically. The Add context docs recommend customId for conversation or document identity, so updates and deduplication have a stable key. The parameter table also gives containerTag, metadata, entityContext, and the dreaming processing mode.

The public schema exposes the same lifecycle. MemorySchema includes content, metadata, source, status, summary, title, type, URL, containerTags, and chunkCount. The platform is not only accepting text; it is returning an object with source, status, grouping, and processing shape.

const MemorySchema = z.object({
  customId: z.string().nullable().optional(),
  content: z.string().nullable().optional(),
  metadata: MetadataSchema.nullable().optional(),
  source: z.string().nullable().optional(),
  status: DocumentSchema.shape.status,
  summary: z.string().nullable().optional(),
  containerTags: z.array(z.string()).optional(),
  chunkCount: z.number().default(0),
});

This schema shows that add is not just storing a text span. customId connects a memory back to the application's document or conversation identity. containerTags enforce user, project, or workspace scope. status and chunkCount tell the caller whether background processing has finished.

The processing pipeline is documented as validation, storage and queueing, content extraction, chunking into searchable memories, embedding, and indexing. That public sequence appears in Processing Pipeline. In product terms, memory becomes a background workflow with observable status, not an in-prompt list.

Supermemory add pipeline:
  validate request
  -> store document and queue processing
  -> extract content (OCR / transcription / web scraping)
  -> chunk into searchable memories
  -> embed
  -> index

Progress:
  GET /v3/documents/{id} -> queued | processing | done

Shape-level example: one document moving through Supermemory

add:
  content = "Customer escalation policy..."
  containerTag = "support-team"
  status = "queued"

worker:
  status = "processing"
  derived searchable artifacts are being generated

later search:
  status = "done"
  profile / search can return background and evidence for the current question

3.2 Profiles Give The Model A Foundation; Search Gives It Evidence

Supermemory makes a useful product distinction by separating user profiles from ordinary search. The User Profiles docs split profiles into static long-term facts and dynamic recent context. That keeps a model from having to run several narrow searches just to reconstruct who the user is.

The README examples follow the same shape. client.add({ content, containerTag }) stores a conversation; client.profile({ containerTag, q }) can return profile.static, profile.dynamic, and relevant searchResults together. The broad background and the query-specific evidence are separate outputs, which gives the caller a cleaner prompt assembly boundary.

await client.add({
  content: conversation,
  customId: "conv_123",
  containerTag: "user_123",
});

const { profile, searchResults } = await client.profile({
  containerTag: "user_123",
  q: "programming style",
});

// profile.static  -> stable long-term facts
// profile.dynamic -> recent context
// searchResults   -> evidence related to this turn

3.3 Search And Connectors Push The Boundary Into Product Infrastructure

On retrieval, Searchv4RequestSchema exposes containerTag, threshold, filters, include flags, limit, query, rerank, and query rewrite. Its MemorySearchResult can carry memory text, similarity, version, parent and child context, and associated documents. The response is a context object, not just a chunk list.

const Searchv4RequestSchema = z.object({
  containerTag: z.string().optional(),
  threshold: z.number().default(0.6),
  filters: SearchFiltersSchema.optional(),
  include: z.object({
    documents: z.boolean().default(false),
    summaries: z.boolean().default(false),
    relatedMemories: z.boolean().default(false),
  }),
  limit: z.number().default(10),
  q: z.string().min(1),
  rerank: z.boolean().default(false),
  rewriteQuery: z.boolean().default(false),
});

const MemorySearchResult = z.object({
  memory: z.string(),
  similarity: z.number(),
  version: z.number().nullable().optional(),
  context: z.object({ parents: z.array(...), children: z.array(...) }).optional(),
  documents: z.array(MemorySearchDocumentSchema).optional(),
});

Supermemory's retrieval contract therefore has two layers. On the request side, containerTag, filters, and threshold control scope and recall breadth. On the response side, similarity, version, parents / children, and documents explain why this memory is relevant. That is closer to a product API than a plain vector-store top-k response.

Connectors push the platform edge further outward. The docs list Google Drive, Gmail, Notion, OneDrive, GitHub, Granola, and Web Crawler as external sources that can sync into Supermemory. The connector workflow includes connection creation, user authorization, automatic setup, and continuous sync through webhooks or schedules. Once memory owns connectors, it also inherits OAuth, webhooks, file versions, sync status, and user-space boundaries.

3.4 Supermemory Is A Product Context API, Not Only An Agent Library

Supermemory's strength is reducing integration work to API and connector surfaces. A product can send conversations, documents, URLs, or files to the platform, then ask profile and search for usable context. The tradeoff is that some internals remain hosted-service behavior: public materials show request parameters, response shapes, and processing states, but not every extraction, consolidation, or reranking policy.

That makes it natural for teams that want to add long-term context to a product quickly. Teams that need full control over each knowledge-graph processing step may prefer a self-hosted knowledge layer such as Cognee. The distinction is not “which one has memory,” but where the team wants control: pipeline internals or product integration surface.

4. Choosing The Route

4.1 First Identify The System Stage

Cognee and Supermemory both make memory more platform-like, but they start from different questions. Cognee asks how raw material becomes a reusable knowledge layer. Supermemory asks how a product gets memory, profiles, search, connectors, and file processing through one context surface.

The reusable lesson is to classify history before choosing infrastructure. Is this record evidence, a profile fact, a relationship, workflow state, a knowledge-layer artifact, or context for this turn only? Cognee and Supermemory push that question to platform scale, where the hard part is often not finding content, but making data sources, processing responsibility, retrieval contracts, and deletion boundaries explicit.

Sources

• topoteretes/cognee
• cognee.api.v1.remember.remember
• cognee.api.v1.cognify.cognify
• cognee.api.v1.search.search
• supermemoryai/supermemory
• Supermemory Add context docs
• Supermemory User Profiles docs
• Supermemory Connectors docs