Cognee: The Open-Source Memory Layer That Finally Lets Agents Remember Across Sessions

Cognee: The Open-Source Memory Layer That Finally Lets Agents Remember Across Sessions

Cognee: The Open-Source Memory Layer That Finally Lets Agents Remember Across Sessions

"Every agent today forgets everything when the session ends. Cognee's bet is that memory — not a bigger context window — is the missing infrastructure layer for agents that actually accumulate expertise."
Ask any team running AI agents in production what breaks first, and the answer is rarely the model. It's memory. The agent re-discovers your codebase every session, repeats suggestions you already rejected, and has no way to learn from a teammate's past decisions. Cognee (GitHub: topoteretes/cognee) is an open-source answer to that gap: a memory layer that ingests your documents, chats, code, and APIs, then organizes them into a self-hosted knowledge graph that agents can query across sessions. By August 2026 it sat at roughly 30,000 GitHub stars, had crossed 1.0 in June 2026, and was backed by a $7.5M Berlin-based seed round. For a blog about running AI on your own hardware, Cognee is squarely on-theme: the default deployment runs embedded (SQLite + LanceDB + Kuzu) with zero external services, the core is Apache-2.0, and you can keep the whole graph on owned infrastructure. This is the honest breakdown — including where the "free" stops and the managed cloud begins. Cognee turns scattered data into a queryable graph

1. What Cognee Is (and Isn't)

Cognee is not a vector database, and it's not a chatbot. It's a memory layer — a pipeline that sits between your raw data and your agents, and gives those agents four operations: remember, recall, forget, and improve. That CRUD-for-memory framing is the whole point: memory is treated as managed state, not a side effect of a prompt. Technically, Cognee is a Python platform (with official Rust and TypeScript clients, a CLI, a Docker image, and an MCP server). You point it at data, it builds a graph + vector index, and agents query that graph for context. The graph captures entities, their relationships, and the semantic context of every interaction — so an agent can say "I remember we discussed this pattern last week" with actual recall, not a hallucinated one. The license is Apache-2.0 with a single, unambiguous LICENSE file. No split core/docs licensing, no Commons-Clause surprise. Commercial use, modification, and redistribution are all permitted with attribution.

2. Why Agent Memory Breaks (and Why Chunks Fail)

The standard RAG answer to "make the agent remember" is to stuff vectors into a database. It works for single-fact lookups. It falls over on multi-hop questions — "which of these three vendors reported an incident, and when?" — because chunk-based vector search loses the relationships between facts. Two chunks sitting next to each other in a vector store have no structural link; the model has to infer the connection from similarity alone. Cognee's argument is that relationships are first-class data. A knowledge graph preserves "Vendor A → reported → Incident → on → Date" as an explicit edge, so a multi-hop query traverses edges instead of hoping similarity does the work. Vector-only recall wins on raw simplicity and latency for single facts; graph recall wins on multi-hop correctness. Cognee does both — it's hybrid by design, auto-routing each query to vector, graph, or a fusion of the two.

3. The Dual-Memory Architecture

Cognee runs on a two-tier memory model:
  • Session memory — a fast cache holding the current conversation's context. Available instantly for recall, synced to the persistent graph in the background.
  • Knowledge-graph memory — a self-hosted graph database (Postgres-native or Neo4j) that stores entities, relationships, and embeddings permanently. It evolves through the "cognify" pipeline.
The split matters for latency: an agent answering "what did we decide about the auth flow?" can hit the session cache first, and only reach into the durable graph when the answer isn't in the current turn. The background sync means the durable store stays warm without blocking the agent. Session cache and durable graph

4. The Cognify Pipeline

Ingestion in Cognee isn't a one-shot embed. The cognify pipeline runs in four stages: 1. Ingest — text, documents, code, and structured data enter via the remember API. 30+ source connectors cover warehouses, vector stores, files, and APIs. 2. Cognify — an LLM-powered pass extracts entities, grounds them to an ontology, generates embeddings, and links related concepts. 3. Retrieve — queries via recall auto-route to the best strategy: vector similarity, graph traversal, or hybrid. 4. Improve — feedback loops and corrective inputs refine the graph over time, so memory gets better with use. The ontology grounding is the underrated step. Rather than dumping entities into a flat index, Cognee ties them to a typed schema, which is what makes multi-hop traversal meaningful instead of a fuzzy similarity hop.

5. Remember, Recall, Forget, Improve

The four operations are the public API surface, and they map cleanly to how memory should behave:
  • remember — add data to the graph.
  • recall — query it, with auto-routing between vector and graph search.
  • forget — remove stale or wrong nodes (critical for compliance and correctness).
  • improve — feed corrections back so the graph sharpens.
Most memory tools give you "add" and "search." The forget and improve operations are what make Cognee a managed memory layer rather than a write-only junk drawer. For regulated data, the ability to prove a node was deleted matters.

6. Self-Hosted, Embedded by Default

This is the part that matters for this blog. Out of the box, Cognee's defaults — SQLite + LanceDB + Kuzu — run embedded with minimal resources and no external services. You don't need to stand up Postgres or Neo4j to try it. The quickstart is three lines: ``python import cognee await cognee.add("your data here") await cognee.cognify() results = await cognee.search(query_text="your question") ` When you're ready to scale, you swap in Neo4j, Neptune, Qdrant, or pgvector as backends. The embedded default is the "AI you can run on your own machine" story in one sentence: pip install cognee, point it at a folder, and you have a private memory graph. Embedded defaults, swappable backends

7. Integrations: Where the Memory Gets Used

A memory layer is only useful if agents can read it. Cognee ships integrations with Claude Code, Cursor, LangGraph, and CrewAI, plus an MCP server so any MCP-capable agent can call
recall. There's an official Rust engine in the works for on-device memory, and the roadmap lists 30+ new data-source connectors across Q1/Q2. The Claude Code / Cursor integration is the headline: an agent working in your editor can pull project context from the graph instead of re-reading the whole repo every session. For a team, multiple agents reading and writing the same graph is the multi-agent memory story — and it's in the free/open-source tier from day one.

8. Cognee vs Mem0 (the Honest Comparison)

The obvious comparison is Mem0, the other widely-used agent-memory library. The split is clear:
  • Mem0 is built for single-agent, single-user memory (personalizing one user's chat history) and gates its knowledge-graph feature behind a paid tier.
  • Cognee is built for multi-agent memory — several agents reading and writing the same graph — and includes graph capability in the free/open-source tier from the start.
Third-party writeups (e.g. vectorize.io) generally agree with this framing: graph-based recall wins on multi-hop correctness; vector-only wins on simplicity and single-fact latency. If you're a solo dev personalizing one bot, Mem0's simplicity may win. If you're building team agents that share a brain, Cognee's graph-in-free stance is the differentiator.

9. The Honest Limitations

Cognee is real and active, but it has edges you should know before depending on it:
  • Ontology quality depends on the LLM. Entity extraction and grounding lean on model inference during cognify. Garbage prompts → garbage graph. You'll want to tune the extraction prompts.
  • Eventual consistency. Session cache syncs to the durable graph asynchronously. Design agent logic to tolerate that a just-added fact might not be instantly queryable everywhere.
  • Backend migration is undocumented. The docs warn you should pick Neo4j vs Postgres/PGVector early; migrating between graph backends later isn't documented. Choose before you have 10M nodes.
  • No SOC 2 / formal audit. The vendor's trust page claims GDPR-aligned processes but no SOC 2 or FedRAMP certification is documented. For strict-regulated use, threat-model first.
  • Benchmark claims are vendor-run. Cognee cites its own BEAM-benchmark results. Treat them as directional, not independent proof.
  • Young review base. As of mid-2026 it had effectively zero G2/Trustpilot reviews. Normal for a tool that hit 1.0 in June 2026, but means fewer real-world war stories to learn from.

10. What It Costs (Real Numbers)

Self-hosting the open-source engine is free indefinitely — you run it on your own infrastructure and pay only for the LLM/vector-store calls it makes during ingestion and recall. That's the number that matters: your cost is tokens, not seats. The managed Cognee Cloud has three published tiers (real numbers, not "contact us"):
  • Free — $0/month, 1M tokens included, 1 workspace, unlimited users and API calls.
  • Standard — $2.50 per 1M tokens processed, plus $5 per additional workspace; adds Slack/Notion/Google Drive connectors and in-app support.
  • Enterprise — custom pricing; adds a dedicated support engineer, bring-your-own-cloud, and SLAs.
At meaningful ingestion volume, model the Standard tier's usage-based pricing against your expected token throughput — not a flat fee. For a team doing heavy daily ingestion, the token bill (LLM + embeddings) is the real line item, whether you self-host or use cloud.

11. Where Your Data Lands (Data Sovereignty)

Cognee's data-sovereignty story is strong but has one unavoidable asterisk:
  • Self-hosted (default path). Your graph lives in your SQLite/Postgres/Neo4j on your hardware. Data never leaves your infrastructure. End-to-end private.
  • The cognify step needs an LLM. Entity extraction and embedding call an LLM. If you use a local model (Ollama) for both, the entire pipeline stays on-machine. If you use a hosted embedding/LLM, the text you're ingesting transits that provider — the same trade-off as every local-AI tool.
  • Cognee Cloud. The managed option processes data on their infrastructure; the trust page states GDPR-aligned handling and a DPA on request, but it's not air-gapped.
  • Three deployment options include a fully local mode ("your data never leaves your infrastructure").
Sovereignty verdict: self-host Cognee with a local model for both extraction and embeddings and it is end-to-end private. Use a hosted model in the pipeline and your ingested text leaves with it — decide per dataset sensitivity.

12. A Real Ingestion Walkthrough

Say you want a "company brain" over your team's Notion, past Slack threads, and a 200-page architecture doc: 1. Connect sources. Point Cognee's connectors at Notion, export Slack history to a file, and drop the PDF in a folder. 2.
remember all of it. Cognee ingests across formats — text, documents, code, structured data. 3. cognify. The LLM extracts entities ("Auth Service", "Incident #42", "Q3 migration"), grounds them to the ontology, generates embeddings, and links them. "Auth Service → caused → Incident #42 → on → 2026-03-14" becomes a traversable edge. 4. recall. An agent asks, "What incidents did the auth service cause last quarter, and what was the fix?" Cognee traverses the graph, returns the linked nodes with source citations, and the agent answers with traceable context instead of a guess. 5. improve. When a teammate corrects the agent ("that incident was actually the billing service"), the correction updates the graph so the next query is right. The payoff is cumulative: the second question is cheaper and more accurate than the first, because the graph already exists.

13. Production Hardening

  • Pick your backend early. Neo4j vs PGVector migration isn't documented — decide before scale.
  • Budget for embedding cost. Ingestion calls the LLM/embedder per item. Batch and schedule it; don't cognify on every chat turn.
  • Threat-model multi-tenant. The docs claim agentic user/tenant isolation, but review it before putting untrusted tenants in one graph.
  • Encrypt at rest. LLM API keys and the graph store need encryption; the project gives no hardening guide, so you own that.
  • Audit trails. OTEL collector integration is mentioned but not detailed — wire your own observability if you need compliance evidence.

14. FAQ

Is cognee really Apache-2.0? Yes — a single, unambiguous LICENSE file, OSI-approved, commercial use permitted. Can it run fully offline? The engine can. But the cognify step needs an LLM; use a local Ollama model for both extraction and embeddings to keep it air-gapped. Do my files leave my machine? Only if you choose a hosted model for ingestion/recall. Local model = on-prem. Is it production-ready? It hit 1.0 in June 2026 and is actively developed (pushes within 24h as of Aug 2026). For non-regulated use, yes with the caveats above. Graph or vector? Both — it auto-routes per query. You don't pick; the engine does. Who is it NOT for? Teams that want zero-ops SaaS with no self-hosting burden, or those needing SOC 2 / FedRAMP evidence out of the box.

15. The Ontology Layer Explained

The ontology is the quiet differentiator most memory tools skip. When Cognee cognifies data, it doesn't just embed text — it grounds extracted entities to a typed schema. "Auth Service" becomes a node of type Service; "Incident #42" becomes a node of type Incident; the relationship between them is typed as caused. This typing is what makes graph traversal meaningful: a query can ask for "incidents caused by services tagged payments" and the engine filters on the type, not on fuzzy similarity. The ontology is also where correctness is won or lost. If the extraction prompt mis-types an entity, the graph gains a wrong edge that future queries will trust. Cognee's
improve operation exists precisely to let you correct these — feeding a fix back so the graph sharpens. Treat ontology tuning as a first-class task, not a set-and-forget default.

16. Cognee in a Multi-Agent Team

The single-agent vs multi-agent distinction is where Cognee earns its keep versus simpler memory libraries. In a multi-agent setup, several agents read and write the same graph:
  • A research agent ingests new docs and extends the graph.
  • A coding agent queries the graph for project context instead of re-reading the repo.
  • A review agent checks proposed changes against remembered decisions ("we already rejected that auth approach").
Because the graph is shared and persistent, knowledge compounds across agents instead of being trapped in one chatbot's context window. Cognee's agentic user/tenant isolation is what keeps untrusted agents from reading each other's nodes — review that isolation before mixing tenants in one graph.

17. Troubleshooting Cognee

  • Graph feels empty after remember. You forgot to run cognify. Ingestion stores raw data; the graph is built in the cognify step.
  • Recall misses obvious facts. The LLM extraction may have mis-typed an entity, or the ontology needs tuning. Use improve to correct and re-cognify.
  • Slow ingestion at scale. Entity extraction calls the LLM per item. Batch, schedule off-peak, and consider a faster local model for extraction.
  • Backend choice regret. Neo4j-vs-PGVector migration isn't documented — decide before you have millions of nodes.
  • Eventual consistency surprises. A just-added fact may not be instantly queryable everywhere; the session cache syncs async. Design for it.

18. Roadmap and Community Signals

Cognee's momentum is healthy: pushed within 24 hours of an August 2026 check, ~30k stars, 760 commits in the prior four weeks, and a 1.0 milestone in June 2026. The product roadmap lists a Rust on-device engine, multi-database support, user database isolation, and 30+ new connectors across the next two quarters. The $7.5M seed (Pebblebed-led, Feb 2026) funds the commercial cloud while the core stays Apache-2.0. The thing to watch: whether the managed cloud's feature lead stays modest enough that self-hosters don't feel second-class. So far graph memory is in the free tier, which is the right call for adoption.

19. Who Should Use Cognee

Use it if you are: building agents that need to recall across sessions; running a team where multiple agents share one brain; working with messy multi-source data (docs, chats, code, APIs) that vanilla RAG mangles; able to self-host and tune an LLM extraction step. Skip it if you are: needing zero-ops SaaS with no self-hosting; requiring SOC 2 / FedRAMP evidence out of the box; working at billion-node scale with no benchmark data to lean on; wanting a tool that "just embeds and searches" without ontology work. For the first group, Cognee is the most complete open agent-memory platform of 2026 — and self-hosted with a local model, it's fully private.

20. Cognee vs a Plain Vector Store

It's fair to ask why not just embed into pgvector and call it a day. The honest answer: for single-fact lookups, a plain vector store is simpler and faster, and Cognee would be overkill. The gap shows up on three axes:
  • Multi-hop reasoning. "Which vendors reported an incident, and when?" needs relationships, not just similarity. A vector store returns nearest neighbors; Cognee traverses typed edges.
  • Correction and forgetting. Plain vector stores accumulate embeddings you can't easily un-embed. Cognee's forget and improve give you managed, auditable memory lifecycle.
  • Ontology-aware retrieval. Typed entities let queries filter by kind ("services tagged payments"), which similarity search can't express.
The right framing: Cognee is to a vector store what a relational DB is to a key-value store — more structure, more upfront modeling, better answers on connected questions. If your memory needs are "semantic search over a doc," skip it. If they're "an agent that learns and recalls relationships," it's the right tool.

21. Getting Started: A Minimal Local-Only Setup

The fastest path to a private memory graph is the embedded default plus a local model:
`bash pip install cognee ` Then, in Python, point the extraction and embedding steps at a local Ollama model (set COGNEE_EMBEDDING_PROVIDER and COGNEE_LLM_PROVIDER to your local endpoint), and run: `python import cognee await cognee.add("./my-docs") await cognee.cognify() results = await cognee.search(query_text="What did we decide about the auth flow?") `` No Postgres, no Neo4j, no cloud — SQLite + LanceDB + Kuzu run embedded. The entire pipeline stays on your machine because both the embedder and the LLM are local. Swap in a hosted model later only if you need better extraction quality and can accept the text leaving your network. This local-only path is the cleanest demonstration of Cognee's "AI on your own hardware" fit.

Related

Comments (0)

No comments yet. Be the first to comment!

Leave a Comment