Cognee Memory Platform
Persistent, self-hosted graph and vector memory for AI agents across sessions.
- Source repo
- topoteretes/cognee
- Stars
- ★ 33k
- Last updated
- 7d ago
- License
- Apache-2.0
- Primary language
- Python
- FA score
- 47/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformClaude Code · OpenAI API
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- A customer-support team needs an agent to resolve an unresolved billing issue using a customer's finance, support, and product history.
- Not a fit if
- Users wanting zero-config setup without LLM keys or storage choices
- Teams needing production-grade Postgres graph storage; it is demo-only
- Source review
- 47/100 · Major gaps 1 safety controls not found
What does this agent do, and when should you use it?
Cognee is an open-source memory platform for AI agents with a Python API, CLI, API server, MCP server, and local UI path. It ingests data in any format and builds a self-hosted knowledge graph that combines vector embeddings with evolving relationships. Its primary API consists of remember, recall, forget, and improve; session memory can act as a fast cache before background synchronization to the graph. Local development can use SQLite, LanceDB, and Kuzudb, while Postgres, Neo4j, Redis, and other backends are documented options. It fits teams adding a memory layer to Python agents, Claude Code workflows, or self-hosted services, provided they can configure LLM credentials and choose appropriate storage infrastructure.
Applications write content with await cognee.remember(...), optionally with a session_id; permanent writes run the add, cognify, and improve flow, while session writes enter a fast cache and synchronize to the graph in the background. await cognee.recall(query) automatically selects a search strategy, and a session_id makes it search session memory before falling back to the graph. await cognee.forget(dataset="main_dataset") removes a dataset; cognee-cli also exposes remember, recall, and forget --all commands. Docker Compose can run the API, UI, MCP server, Postgres, and Neo4j profiles, while cognee-cli -ui launches an MCP server inside a container. The Claude Code plugin injects relevant context, captures prompts and tool traces, preserves memory before compaction, and synchronizes permanent graph memory at session end.
- A customer-support team needs an agent to resolve an unresolved billing issue using a customer's finance, support, and product history.
- An analytics team wants junior analysts to reuse expert SQL queries, workflow patterns, schema structures, and successful implementations.
- A Python agent developer needs session_id-scoped preferences during a conversation and durable graph recall in later sessions.
- A Claude Code user wants project context captured and restored through SessionStart, PostToolUse, PreCompact, and SessionEnd hooks.
- A team already operating Postgres wants to demo relational metadata, pgvector, session caching, and graph state in one instance.
How do you install or deploy this agent?
Use Python 3.10 through 3.14. Install with: uv pip install cognee. Configure credentials with: export LLM_API_KEY="YOUR_OPENAI_API_KEY"; alternatively create a .env from .env.template and set LLM_API_KEY. For container deployment, clone the repository, copy .env.template to .env, set LLM_API_KEY, then run docker compose up; add the relevant --profile for UI, MCP, Postgres, or Neo4j. cognee-cli -ui requires Docker Desktop, Colima, or another OCI-compatible runtime with a working docker CLI.
How do you use this agent?
A minimal call sequence is: import cognee; await cognee.remember("Cognee turns documents into AI memory."); results = await cognee.recall("What does Cognee do?"). For session memory, call await cognee.remember("User prefers detailed explanations.", session_id="chat_1") and recall with the same session_id. From a shell, run cognee-cli remember "Cognee turns documents into AI memory." followed by cognee-cli recall "What does Cognee do?". To point the SDK at a managed or remote instance, call await cognee.serve(url="https://your-instance.cognee.ai", api_key="ck_...") and call await cognee.disconnect() when finished.
What are this agent's strengths and limitations?
- A compact asynchronous API unifies remember, recall, forget, and improve while the project also supplies CLI and Docker service paths.
- It combines vector embeddings, knowledge-graph relationships, and session caching; recall can auto-route search and prioritize a named session.
- Local development can use SQLite, LanceDB, and Kuzudb without first standing up external services, with documented paths to Postgres, Neo4j, and Redis when needed.
- The dedicated Claude Code integration explicitly covers context injection, tool-trace capture, pre-compaction preservation, and end-of-session graph synchronization.
- Getting started requires an LLM_API_KEY; remote or Cognee Cloud operation additionally requires COGNEE_BASE_URL and COGNEE_API_KEY.
- cognee-cli -ui depends on Docker or a compatible OCI runtime, adding a container-runtime requirement for that interface.
- The Postgres graph store is explicitly a demo feature rather than production-ready; production graph workloads should use a graph-native backend such as Kuzu or Neo4j.
- The reported BEAM results are described as a directional signal rather than a definitive performance measure, so retrieval quality needs validation on the adopter's own workload.
How does this agent compare with similar options?
Against a traditional memory stack that separately operates a graph database, vector database, Redis, and relational database, Cognee documents a demo configuration that places graph state, pgvector, session cache, and metadata in one Postgres instance. That reduces the number of services, but the Postgres graph backend is not presented as production-ready; graph-native backends such as Kuzu or Neo4j remain the documented production direction.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Cognee Memory Platform This agent | 47 · Major gaps | Library / SDKFree + model costs | ★ 33k | 7d ago | Python | Claude Code · OpenAI API |
| RepoBrain – Repo Intelligence Engine | 49 · Major gaps | Agent plugin / skillFree + model costs | ★ 1.4k | 22d ago | Python | Codex · Claude Code |
| MemPalace Memory | 74 · Some gaps | CLIFree + model costs | ★ 60k | 2d ago | Python | Codex · Claude Code |
| Caura | 70 · Some gaps | Self-hosted serviceFreemium | ★ 549 | today | Python | Codex · Claude Code · Claude.ai |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows: dependency security notes (e.g., GHSA for pydantic-settings), but no least-privilege design (e.g., sandboxing). User confirmation absent. Data flow transparency limited (mentions traceability and OTEL collector but no specifics). Sensitive data handling has encryption for OAuth credentials but not comprehensive. External effects include delete operations without confirmation. Rollback not explicit. Source attribution mentions traceability but not detailed. Deductions: lack of user confirmation, insufficient least-privilege evidence, incomplete data flow transparency.
Evidence shows: README and pyproject.toml consistent, dependency versions have clear ranges, but failure messages not detailed. Deductions: insufficient failure message handling, dependency availability not fully verified.
Evidence shows: targets developers, multiple use cases (customer support, SQL copilot), but capability boundaries unclear (Postgres graph store marked as demo). Trigger precision has parameter validation (e.g., validate_top_k) but not comprehensive. Environment fit good (multiple deployment platforms). Deductions: unclear capability boundaries, partial trigger precision.
Evidence shows: clear information architecture (README, docs, examples), detailed install notes, stable naming (cognee-cli), examples and FAQ, known limitations mentioned (Postgres demo), license clear (Apache-2.0), but no changelog, maintenance responsibility unclear. Deductions: missing changelog, unclear maintenance responsibility.
Evidence shows: output usability has formatting (e.g., format_recall_results), high marginal value (persistent memory), but cost-benefit not quantified. Deductions: insufficient cost-benefit evidence.
Evidence shows: research paper and benchmarks, but no specific data sources. Deductions: insufficient claim traceability, limited cross-source corroboration, unclear fact-inference separation.
- Not found in source: confirmation before actingTurn on (or add) a confirmation step before it acts, and try it in a sandbox or test environment before real data.
- User confirmation mechanism absent; delete operations may execute without prompt.
- Postgres graph store marked as demo; caution for production use.
- Dependency security notes exist but not comprehensive for all dependencies.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
v1.6.6 v1.6.6 — Conflict resolution & stability
Release notes excerpt
v1.6.6 — Conflict resolution & stability Release Date: 2026-10-29 Changes: v1.6.6rc1 → v1.6.6 Pull Requests: #6266, #6337, #6339, #6340 --- Summary This release focuses on making conflict handling more reliable and easier to manage, plus a handful of stability, vector, and data-layout fixes. You’ll find a new durable conflict-resolution API, safer retirement of conflicting choices, faster and safer cache/deletion paths, and improvements to vector handling that save re-embedding work. Highlights …View on GitHub ↗ -
v1.6.6rc1 v1.6.6rc1 — History controls, connectors, and sync hardening
Release notes excerpt
v1.6.6rc1 — History controls, connectors, and sync hardening Release Date: 2026-10-23 Changes: v1.6.5.dev0 → v1.6.6rc1 Pull Requests: #5765, #5850, #5893, #5898, #5938, #5955, #5958, #5961, #6011, #6013, #6014, #6185 --- Summary This release focuses on giving users clearer, safer controls over memory & search history, adding several new connectors, and hardening sync reliability. Key workflow changes include explicit history-purging behaviour, a new flag to remove search history from the CLI/API, and fixes that make Drive/Asana synchronisation and indexing more robust. …View on GitHub ↗ -
v1.6.5 v1.6.5 — Faster trace processing & richer code-graph docs
Release notes excerpt
v1.6.5 — Faster trace processing & richer code-graph docs Release Date: 2026-10-16 Changes: v1.6.4 → v1.6.5 Pull Requests: #5287, #5534, #5620, #5622, #5720, #5721, #5722, #5725, #5726, #5751, #5798, #5898, #5938, #5955, #5958, #5961 --- Summary This release speeds up trace and ingestion pipelines, improves session handling, and makes code documentation searchable inside the code graph. It also adds a new memify API, better embedding compatibility (base64), and several security and connector hardenings. Highlights …View on GitHub ↗