Cognee Memory Platform
Persistent, self-hosted graph and vector memory for AI agents across sessions.
Per-dimension scores and reasoning
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.
- 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.
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.
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 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.
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.