Cognee combines session memory with a knowledge graph
Cognee gives an agent four top-level operations: remember, recall, forget, and improve. Permanent material goes through ingestion and graph construction, while session-scoped memories can enter a faster cache and sync to the graph later. Retrieval can use embeddings and graph relationships instead of treating every document as an isolated text chunk. This is useful when an agent must connect people, events, preferences, and documents across conversations.
The quick start requires Python 3.10 through 3.14 and an LLM API key. That key is part of the product design, since graph extraction and answers use a model provider. Auto-feedback is enabled by default and adds one LLM call after an answered query so memory can adjust from conversation signals. Turning it off reduces cost and delay. Disabling caching goes further and removes session memory, changing what is being evaluated.
The local default is lighter than the full deployment map
Local development can use SQLite, LanceDB, and KuzuDB without separate database servers. The repository also documents PostgreSQL, PGVector, Neo4j, Neptune, Redis, and community vector adapters. Docker profiles can add the UI, MCP server, PostgreSQL, or Neo4j. Those choices let Cognee meet different infrastructure rules, but they also make setup advice workload-specific. A successful notebook does not settle the production topology.
Multi-tenant isolation depends on the chosen backends. The README says both graph and vector stores must support isolation or datasets can fall back to shared databases. Neo4j's per-dataset database mode requires an edition with multi-database support. The single-Postgres graph implementation has another boundary: its open version is described as a demo, while production use is a licensed product. Check that distinction before designing around one database.
What happened when we ran it
Our sandbox installed 253 packages in 66 seconds and occupied 1,126 MB. The build then succeeded in 7 seconds. Pip-audit reported 2 known vulnerabilities. These results came from commit 690c0ec in an unprivileged Python 3.12 Debian container with 3 CPUs and 8 GB of RAM, without secrets. They measure repository setup, not graph quality, model cost, or retrieval latency.
The test command did not complete within the 900-second limit. Its final output showed a Python thread running an asyncio event loop, waiting in the selector's polling call. The timeout banner appeared, followed by F. That tail does not identify which external service, fixture, or code path was responsible, and it gives no completed test count. The defensible result is simple: the suite timed out in our stated environment.
The measured repository contained 3,150 files, about 375,420 lines of source, 51 CI workflow files, a Dockerfile, a Compose file, and a tests directory. Its 96.6 MB checkout became more than 1 GB after installation. This is a platform-sized dependency and code footprint. Teams embedding it in another service should isolate upgrades and scan the resolved environment rather than treating Cognee like a small utility package.
MCP and Claude Code make memory automatic and invasive
Cognee ships an MCP server and documents HTTP, SSE, and stdio transports. Its Claude Code plugin captures prompts, tool traces, and assistant responses, injects retrieved context when a prompt arrives, preserves memory before compaction, and syncs at session end. That lifecycle coverage can make memory feel automatic. It also means the service may receive a detailed record of developer activity, so dataset boundaries, retention, access, and deletion need deliberate policies.
Local Claude Code mode starts a Cognee API on port 8011 and requires an LLM key. Remote mode instead needs a Cognee base URL and API key. The UI launches its MCP server inside a container, so Docker Desktop, Colima, or another OCI runtime with a working Docker CLI is required. These are clear instructions, though they place more machinery behind what users experience as one plugin.
Release 1.5.3 is active while behavior is still moving
GitHub recorded the last push on August 26, 2026, and release 1.5.3 was published 3 days earlier. The repository had 30,271 stars and 350 combined open issues and pull requests when fetched. That is current development and a sizable review queue. The release notes focus on search relevance, resumable ingestion, file validation, and stability, all areas that affect whether an agent can trust memory over time.
Open reports show why version-specific evaluation matters. Issue 4632 says cognee.config.set_graph_model() stored a value that extraction never read in v1.5.2 and a then-current main revision; a pull request was open with regression coverage. Issue 4673 reports a Cognee Cloud tenant where add and search requests hung while health and other routes responded. Neither report proves your deployment will fail, but both describe core paths worth adding to acceptance tests.
Cognee earns a trial only with your own retrieval set
Feature count cannot tell whether the generated graph helps an agent answer better. Build a small evaluation set from real documents and conversations, including corrections, conflicting facts, deletions, and tenant boundaries. Measure retrieval quality, model spend, ingestion recovery, and the delay of first and repeated queries. Repeat the checks with auto-feedback both enabled and disabled so its extra call earns its place.
Cognee is appealing when a team wants one system to own document ingestion, session memory, graph structure, and agent-facing retrieval. Our 900-second timeout and 1,126 MB environment make a casual dependency hard to justify. If a simple vector database plus explicit user-profile fields answers the need, use that smaller design. Choose Cognee when relationships and evolving memory produce measurable gains that repay its operational surface.