DEV Community

Andrew
Andrew

Posted on • Originally published at andrew.ooo

Cognee Review: Open-Source AI Memory for Agents

Originally published on andrew.ooo — visit the original for any updates, code snippets that aged out, or follow-up posts.

TL;DR

Cognee is an open-source AI memory platform that gives agents persistent long-term memory across sessions. Instead of stuffing everything into a vector store and hoping semantic search finds it, Cognee builds a self-hosted knowledge graph — extracting entities and relationships from your data so agents can connect facts, not just retrieve nearby ones. It's crossed 28,000 GitHub stars, has 190+ contributors and 127 releases, and shipped v1.4.0 on July 17, 2026. Highlights:

  • ECL pipeline — Extract → Cognify → Load. Documents become a graph of entities and relationships, persisted to Neo4j, Kuzu, or PGVector, then exposed through a tiny memory API.
  • Four-verb APIremember, recall, forget, improve. That's the whole surface for storing, querying, deleting, and refining memory.
  • Runs locally — pip/uv install or Docker Compose, self-hosted graph + vector storage, works with any LLM through a Python SDK or OpenAI-compatible API.
  • Session + permanent memory — a fast session cache that syncs into the permanent graph in the background.
  • MCP server + plugins — first-class Model Context Protocol server, plus Claude Code and OpenClaw plugins for drop-in agent memory.
  • Cognitive-science ontology — relationships are grounded in a generated ontology, not just raw co-occurrence, which is what separates it from plain RAG.

If you're building agents that need to learn over time — remember a user's preferences, track how a codebase's bug patterns evolve, or connect facts across hundreds of documents — Cognee is one of the most serious open-source options in the space. If you just need "find the closest chunk," a plain vector DB is simpler. This review covers what Cognee actually does, real code, the honest limitations, and how it compares to pure vector RAG.

Quick Reference

What it is Open-source AI memory platform (knowledge graph + vectors)
Language Python 3.10–3.14
Install uv pip install cognee or Docker Compose
Storage Kuzu / Neo4j (graph) + PGVector / LanceDB (vectors)
API remember, recall, forget, improve
Interfaces Python SDK, CLI, REST API, MCP server, web UI
License Apache 2.0 (self-hosted free)
Cloud Optional, from ~$5/workspace/mo
Stars ~28,000
Repo github.com/topoteretes/cognee

The Problem Cognee Solves

Every stateless agent has the same amnesia. A code-review assistant that spent a month learning 14 recurring bug patterns in your repo starts its next review knowing nothing. A support agent that learned a customer's account quirks forgets them the moment the session ends. The industry's default answer — retrieval-augmented generation over a vector store — helps, but it has a structural ceiling: vector search finds text that's semantically near your query, but it doesn't know how facts relate.

Ask a vector store "which of our customers were affected by the outage that the billing bug caused?" and it will happily return chunks mentioning "outage," "billing," and "customers" — without ever connecting this bug to that outage to those customers. Relationship reasoning is exactly where pure similarity retrieval falls down, and it's the gap Cognee targets.

Cognee's bet is that long-context, multi-hop questions need a graph. Graphs are slower, more complex, and more expensive than vectors — the Cognee team knows this and picked the graph anyway, because relationship reasoning is a hard requirement they don't think embeddings alone can satisfy.

How Cognee Works: The ECL Pipeline

Where a normal RAG stack is "chunk → embed → retrieve," Cognee runs an ECL pipeline:

  1. Extract — ingest data in any format (docs, chats, code, APIs) and pull out entities and relationships.
  2. Cognify — structure those entities against a generated, cognitive-science-grounded ontology, so the graph has meaningful relationship types rather than raw co-occurrence.
  3. Load — persist the result to a graph database (embedded Kuzu by default, or Neo4j) plus a vector store for embeddings.

The payoff is that memory is both searchable by meaning and connected by relationships. Every ingestion step makes relationships explicit and increases retrieval granularity — which is precisely the extra work that gives agents temporal awareness, entity relationships, and feedback loops that pure vector retrieval can't provide. The approach is documented in the team's 2025 research paper, Optimizing the Interface Between Knowledge Graphs and LLMs for Complex Reasoning.

Getting Started

Cognee installs like any Python package:

uv pip install cognee
Enter fullscreen mode Exit fullscreen mode

Point it at an LLM (any provider works; OpenAI shown here):

import os
os.environ["LLM_API_KEY"] = "YOUR_OPENAI_API_KEY"
Enter fullscreen mode Exit fullscreen mode

Then the entire memory API is four verbs:

import cognee
import asyncio


async def main():
    # Store permanently in the knowledge graph (runs add + cognify + improve)
    await cognee.remember("Cognee turns documents into AI memory.")

    # Store in fast session memory (syncs to the graph in the background)
    await cognee.remember("User prefers detailed explanations.", session_id="chat_1")

    # Query with auto-routing (picks the best search strategy automatically)
    results = await cognee.recall("What does Cognee do?")
    for result in results:
        print(result)

    # Query session memory first, fall through to the graph if needed
    results = await cognee.recall("What does the user prefer?", session_id="chat_1")
    for result in results:
        print(result)

    # Delete when done
    await cognee.forget(dataset="main_dataset")


if __name__ == "__main__":
    asyncio.run(main())
Enter fullscreen mode Exit fullscreen mode

That session_id split is the clever bit: remember(..., session_id=...) writes to a fast cache for the current conversation, then syncs into the permanent graph in the background. recall(..., session_id=...) checks the session first and falls through to the graph — so live chat stays fast while long-term memory keeps building.

There's a CLI for the same operations:

cognee-cli remember "Cognee turns documents into AI memory."
cognee-cli recall "What does Cognee do?"
cognee-cli forget --all
cognee-cli -ui        # open the local web UI to browse the graph
Enter fullscreen mode Exit fullscreen mode

Running It Self-Hosted with Docker

For anything beyond a script, run the server. Cognee publishes prebuilt images on every push to main, so you don't even need to clone:

# Minimal .env in the current directory
echo 'LLM_API_KEY="YOUR_OPENAI_API_KEY"' > .env

# API server on http://localhost:8000
docker run --env-file ./.env -p 8000:8000 --rm -it cognee/cognee:main
Enter fullscreen mode Exit fullscreen mode

Or build from source with Compose and opt into the pieces you want:

cp .env.template .env    # then set LLM_API_KEY

docker compose up                     # API server (http://localhost:8000)
docker compose --profile ui up        # + frontend on :3000
docker compose --profile mcp up       # + MCP server on :8001
docker compose --profile postgres up  # + Postgres/PGVector
docker compose --profile neo4j up     # + Neo4j
Enter fullscreen mode Exit fullscreen mode

The profile system is the self-hoster's friend here: start with the embedded Kuzu graph and no external services, then graduate to Postgres/PGVector and Neo4j only when you need production persistence — all in the same compose file.

Wiring Cognee into Agents

Cognee's real audience is agent builders, and it ships integrations rather than making you glue everything yourself.

Model Context Protocol. There's a dedicated cognee/cognee-mcp image so any MCP-capable client can read and write memory:

docker run -e TRANSPORT_MODE=http --env-file ./.env -p 8000:8000 \
  --rm -it cognee/cognee-mcp:main
Enter fullscreen mode Exit fullscreen mode

Claude Code. A memory plugin installs straight from the marketplace and hooks into Claude Code's lifecycle — capturing prompts and tool traces, injecting dataset-scoped context on every prompt, preserving memory across context compaction, and syncing to the permanent graph when a session ends:

claude plugin marketplace add topoteretes/cognee-integrations
claude plugin install cognee-memory@cognee
export LLM_API_KEY="sk-..."   # local mode auto-mints a Cognee key
claude
Enter fullscreen mode Exit fullscreen mode

In local mode the plugin bootstraps a Cognee API at http://localhost:8011 automatically; for a remote instance you set COGNEE_BASE_URL and COGNEE_API_KEY instead. There are also OpenClaw, TypeScript, and Rust clients, so the same memory layer is reachable from whatever stack your agent lives in.

Community Reactions

Cognee sits in the fast-growing "agent memory" category alongside Graphiti, Mem0, and Zep, and the community sentiment is genuinely split — which is a healthy sign for a real tool.

The bull case: developers who've hit RAG's relationship ceiling like that Cognee makes the graph a first-class citizen. FalkorDB's own docs describe Cognee as focused on "flexible hybrid storage combining graph and vector databases with multiple search types (graph completion, similarity, insights)" — praise from an adjacent graph vendor. The v1.4.0 release (dataset-level overview index, faster ingestion for large files, improved search ranking) landed as evidence the project is iterating on exactly the pain points heavy users report.

The skeptic case is worth taking seriously. A widely shared r/AI_Agents post — "I reverse-engineered the three biggest agent-memory tools. Then I went back to markdown files and LLM wikis over Obsidian" — argued that you can approximate a knowledge-graph experience with plain .md files, and that the operational weight of a graph stack isn't always worth it. The author adapted ideas from Cognee, Graphiti, and Neo4j but rebuilt a lighter version with MongoDB + an embedding model + a small LLM. That's the honest tension: graphs are powerful, but they're not free.

Honest Limitations

  • Graphs cost more than vectors — full stop. The Cognee team says it themselves: the graph is slower, more complex, and more expensive than pure vector retrieval. You're paying that overhead on every ingestion. If your questions are simple "find the nearest chunk" lookups, the ECL pipeline is more machinery than you need.
  • LLM calls during ingestion. Extracting entities and building the ontology means LLM inference at write time, not just read time. On large corpora that's real token spend and real latency — plan for it.
  • Operational surface area. A production deployment can mean a graph DB (Neo4j), a vector DB (PGVector), Postgres, and the API/MCP servers. The Docker profiles make this manageable, but it's still more moving parts than a single hosted vector store.
  • The "just use markdown" critique lands sometimes. For small, mostly-flat knowledge bases, a lighter approach genuinely can match a graph at a fraction of the complexity. Cognee earns its keep on large, interconnected, multi-hop data — pick it for the problem it's built for.
  • Ecosystem still maturing. The MCP server, plugins, and multi-language clients are moving fast, which is great, but APIs and defaults are still evolving release to release (127 releases and counting). Pin versions in production.

None of these are dealbreakers. They're the honest cost of choosing relationship reasoning over raw similarity — a trade that pays off precisely when your data is too connected for vectors alone.

Cognee vs. Pure Vector RAG

Cognee (graph memory) Pure vector RAG
Retrieval model Entities + relationships + vectors Nearest-neighbor embeddings
Multi-hop reasoning ✅ Traverses the graph ❌ Similarity only
Temporal awareness ✅ Relationships evolve over time ⚠️ Limited
Setup complexity ⚠️ Higher (graph + vector stores) ✅ Single vector store
Ingestion cost ⚠️ LLM calls to build the graph ✅ Embed-only
Best for Connected, multi-hop, evolving knowledge Simple "find similar text" lookups
Self-hosted ✅ Yes ✅ Yes

The honest summary: pure vector RAG is the simpler, cheaper default for straightforward retrieval. Cognee is what you reach for when relationships matter — when the answer requires connecting facts across documents, tracking how knowledge changes, or giving an agent memory that genuinely compounds over sessions.

FAQ

Is Cognee free and open source?
Yes. Cognee is open source (Apache 2.0) and fully self-hostable at no cost — you pay only for whatever LLM provider you plug in. There's an optional Cognee Cloud from around $5/workspace/month if you don't want to run the infrastructure yourself.

How is Cognee different from a vector database?
A vector database retrieves text that's semantically similar to your query. Cognee also builds a knowledge graph of entities and relationships via its ECL (Extract → Cognify → Load) pipeline, so agents can do multi-hop reasoning — connecting facts across documents — not just similarity lookups. It uses both graph and vector storage together.

What databases does Cognee use?
By default it runs an embedded Kuzu graph so you can start with zero external services. For production it supports Neo4j for the graph and PGVector/Postgres (and other vector stores like LanceDB) for embeddings, all selectable via Docker Compose profiles.

Does Cognee work with Claude Code and MCP?
Yes. Cognee ships a Model Context Protocol server (the cognee/cognee-mcp image) plus a Claude Code memory plugin that hooks into the session lifecycle to capture context and sync it into the permanent graph. There are also OpenClaw, TypeScript, and Rust clients.

Can I use Cognee with any LLM?
Yes. Cognee integrates with any LLM through its Python SDK and an OpenAI-compatible API. You set LLM_API_KEY (or configure another provider) — OpenAI, local models, and others are all supported.

When should I NOT use Cognee?
If your use case is simple nearest-neighbor retrieval over a small, mostly-flat corpus, a plain vector store is cheaper and simpler. Cognee's graph adds ingestion-time LLM cost and operational overhead that only pays off when your data is large, interconnected, or requires multi-hop reasoning.

Verdict

Cognee is one of the most serious open-source answers to agent amnesia in 2026. By making a self-hosted knowledge graph a first-class citizen — not a bolt-on to a vector store — it gives agents something plain RAG structurally can't: the ability to connect facts, reason across multiple hops, and let memory evolve over time. The four-verb API (remember, recall, forget, improve) keeps the developer surface tiny, the Docker profiles make self-hosting approachable, and the MCP server plus Claude Code and OpenClaw plugins mean you can wire it into real agents today.

The cost is honest and real: graphs are slower, pricier, and heavier to operate than vectors, and for small flat datasets a lighter approach can match them. But if you're building agents that need to learn — remembering users, tracking a codebase, or connecting knowledge across hundreds of documents — Cognee's 28,000 stars are well earned. Pick it for the problem it's built for, and it's hard to beat in open source.

Sources

Top comments (0)