Cognee

Cognee builds a graph and vector knowledge layer from documents, code, and conversation history, its backends can be distributed across relational, graph, and vector stores, and local development has embedded defaults.

The original technical sharing did not mention performance on large workspaces, how permission boundaries are handled, or incremental strategies for graph updates.

After Notion workspace content changes, re-running the loading flow syncs the incremental information into the graph.

After Notion documents are converted into a knowledge graph, the agent can reason along entity relations and form answers with context.

Cognee's two-stage design, which separates add() from cognify(), allows documents to be collected in batches and then graphified once, avoiding repeated expensive graph computation each time a piece of text is added.

The cognee.cognify() process typically involves calling a large language model for information extraction, so it is computationally expensive.

Cognee builds a knowledge graph as an external memory layer for AI agents.

cognee.cognify() is the core method in the Cognee framework that triggers knowledge graph construction, performing entity recognition, relation extraction, and graph writing.

What Mem0, Honcho and Cognee have in common is that their memory capabilities are built on general-purpose storage, shielding underlying differences through an abstraction layer.

Cognee is closer to a knowledge graph construction tool, emphasizing the organization of documents and entities with graph structures and providing hybrid graph plus vector retrieval.

Cognee, on its improve page, states its gates: guidance is eligible only when it has not been marked harmful and its confidence passes the distillation gate; proposed lessons are handed to the writer/rejecter to check their relationship with existing lessons and graph entities.

Cognee ingests content and builds a knowledge graph, enabling retrieval to traverse along relationship chains rather than returning isolated text chunks

To install the Cognee plugin use the command pip install cognee-integration-hermes-agent, and upgrading requires adding the -U parameter.

Switching models is fully decoupled from the memory layer, and Cognee treats different models such as Gemini and Opus the same at the underlying level.

The Cognee plugin adopts a no-silent-fallback design: if COGNEE_BASE_URL is set but connection fails or the local server fails to start, initialization directly throws an error rather than switching to another mode.

Cognee's local storage (SQLite, Kuzu/Ladybug, LanceDB) is single-writer, and multi-process access leads to database lock errors and eventually data corruption, so the official default adopts a local server as the single owner to serialize access.

Cognee integration supports three connection modes: local-server (default), remote (set COGNEE_BASE_URL), and embedded (COGNEE_EMBEDDED=true).

The Cognee local server runs in agent mode and automatically retires within 60 seconds after the last agent deregisters

The Cognee plugin, after each conversation turn completes, only writes the content to cheap session memory and does not build a graph; graph construction (chunking, LLM extraction of entities and relationships, embedding, and committing edges) is concentrated at the end of the session and performed in a separate process via cognee.improve()

Hermes discovers memory providers by scanning folders under $HERMES_HOME/plugins/ that contain plugin.yaml and a Python implementation; the folder name is the provider's identity