Skip to main content
toolsSource-backedReview first Safety Privacy
Cognee logo

Cognee

Open-source AI memory platform that gives agents persistent long-term memory by ingesting data in any format and building a self-hosted knowledge graph, combining vector embeddings, graph reasoning, and ontology generation for meaning-based and relationship-based retrieval.

by topoteretes · submitted by davion-knight·added 2026-07-09·
HarnessCLI
Review first review before installing

Open the source and read safety notes before installing.

Citation facts

Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.

Source URLs
https://docs.cognee.ai/, https://github.com/topoteretes/cognee, https://www.cognee.ai/
Brand
Cognee
Brand domain
cognee.ai
Brand asset source
brandfetch
Safety notes
Cognee ingests your data and builds a knowledge graph that agents read from, so treat graph content derived from external or user data as untrusted input and constrain what an agent may do based on it., Use tenant or user isolation so one tenant's knowledge is not retrieved for another, and review which sources are eligible for ingestion., The extraction and cognify steps call a model provider with ingested content; scope credentials to the minimum needed and keep them out of source control., Cognee runs self-hosted, so secure the graph and vector stores and their endpoints, and do not expose them on a public interface without protection., Keep production ingestion and permissions narrower than quickstart examples, and set retention rules for the accumulating graph.
Privacy notes
Ingested documents and the resulting knowledge graph can contain personal, confidential, or proprietary data; apply retention, deletion, and access-control policies to the graph and vector stores., Extraction, ontology generation, and embedding send ingested content to the configured model and embedding providers, which process it under their own terms; local models keep that on your machine., Because Cognee is self-hosted, ingested data stays in the stores you configure, but any external providers used for processing follow their own data-handling policies., Provider keys, ingested data, and graph exports should be treated as sensitive and kept out of version control.
Author
topoteretes
Submitted by
davion-knight
Claim status
unclaimed
Last verified
2026-07-09

Decision playbook

Review trust signals before you adopt

Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.

Compare context
Selected

0

Current score

78

Baseline

Delta

No baseline selected

No major trust-signal divergence detected in the current selection.

Source and provenance checks

Complete

Confirm ownership and provenance before trusting install instructions.

  • Source link availableRequired

    Open the canonical repository and verify ownership.

    Done
  • Source provenance statusRequired

    Marked as source-backed.

    Done
  • Metadata reviewed

    Registry metadata indicates a reviewed listing.

    Done

Safety and privacy checks

Complete

Validate risk disclosures before installation or API wiring.

  • Safety notes presentRequired

    Review the listed safety guidance before running commands.

    Done
  • Privacy notes presentRequired

    Review data handling notes before connecting accounts or secrets.

    Done
  • Trust level risk gateRequired

    Trust level does not block evaluation.

    Done

Package and install checks

Needs review

Check package metadata and artifact integrity signals.

  • Install payload available

    Install or copy payload is available for review.

    Done
  • Package verification flag

    No package verification flag provided.

    Pending
  • Checksum metadata

    No checksum provided for downloaded artifact.

    Pending

Compare-driven decision checks

Needs review

Use compare context to validate trade-offs before adoption.

  • Compare tray has multiple entries

    Add at least one more entry to compare trust differences.

    Pending
  • Baseline comparison available

    No baseline peer selected yet.

    Pending
  • Diverging trust signals identified

    No major trust-signal divergence found.

    Pending

Adoption plan

Balanced adoption plan

Current risk score 16/100. Use staged verification before broader rollout.

Risk 16

Pre-adoption checks

Validate source and review signals before any execution.

  • Confirm source provenanceRequired

    Source URL/provenance metadata is present.

    Done
  • Confirm metadata review state

    Listing has review metadata.

    Done
  • Verify install payload

    Install/config payload exists and can be inspected.

    Done

Security checks

Confirm safety, privacy, and package integrity signals.

  • Review safety notesRequired

    Safety notes are present.

    Done
  • Review privacy notesRequired

    Privacy notes are present.

    Done
  • Verify package integrity metadata

    No package verification/checksum metadata.

    Pending

Rollout

Adopt in controlled steps based on the selected plan.

  • Run in isolated sandbox firstRequired

    Use a constrained sandbox and observe behavior across multiple tasks.

    Pending
  • Roll out graduallyRequired

    Roll out to a small cohort before wider usage.

    Pending
  • Set monitoring and fallback

    Define rollback path and monitor errors after adoption.

    Pending

Evidence readiness

Evidence readiness matrix · balanced

Required evidence gates are covered (5/6 signals complete).

Risk 15

Source provenance

Present

Source repository/provenance is listed.

Required in this preset

Metadata review

Present

Review metadata is present.

Required in this preset

Safety notes

Present

Safety notes are present.

Required in this preset

Privacy notes

Present

Privacy notes are present.

Optional in this preset

Package integrity

Missing

Package integrity metadata is missing.

Optional in this preset

Install payload

Present

Install payload is available.

Required in this preset

Required evidence gates are covered for this preset.

Decision timeline

Decision timeline · balanced

5/6 steps complete with no blocking gaps for this preset.

Risk 14

triage

Confirm source provenanceRequired

Source/provenance metadata is available.

Done

triage

Check metadata review statusRequired

Review metadata is available.

Done

verify

Review safety notesRequired

Safety notes are available.

Done

verify

Review privacy notes

Privacy notes are available.

Done

verify

Validate package integrity metadata

Package integrity metadata is missing.

Pending

rollout

Verify install payload and commandsRequired

Install payload is available.

Done

No required blockers for this timeline preset.

Safety notes

  • Cognee ingests your data and builds a knowledge graph that agents read from, so treat graph content derived from external or user data as untrusted input and constrain what an agent may do based on it.
  • Use tenant or user isolation so one tenant's knowledge is not retrieved for another, and review which sources are eligible for ingestion.
  • The extraction and cognify steps call a model provider with ingested content; scope credentials to the minimum needed and keep them out of source control.
  • Cognee runs self-hosted, so secure the graph and vector stores and their endpoints, and do not expose them on a public interface without protection.
  • Keep production ingestion and permissions narrower than quickstart examples, and set retention rules for the accumulating graph.

Privacy notes

  • Ingested documents and the resulting knowledge graph can contain personal, confidential, or proprietary data; apply retention, deletion, and access-control policies to the graph and vector stores.
  • Extraction, ontology generation, and embedding send ingested content to the configured model and embedding providers, which process it under their own terms; local models keep that on your machine.
  • Because Cognee is self-hosted, ingested data stays in the stores you configure, but any external providers used for processing follow their own data-handling policies.
  • Provider keys, ingested data, and graph exports should be treated as sensitive and kept out of version control.

Prerequisites

  • Python 3.10+ project and a dependency manager to install `cognee` from PyPI (TypeScript and Rust clients are also available).
  • A model provider for extraction and embeddings, or local models if you prefer to run them yourself.
  • Backing stores for the knowledge graph and vectors (Cognee runs self-hosted with supported graph and vector databases).
  • The data sources you want to ingest, and stable tenant or user identifiers if you need isolation between them.
  • A retention and access-control plan for the knowledge graph, since it accumulates ingested data.

Schema details

Install type
copy
Troubleshooting
No
Source repository stats
Scope
Source repo
Tool listing metadata
Pricing
open-source
Disclosure
editorial
Application category
DeveloperApplication
Operating system
macOS, Windows, Linux
Full copyable content
## Editorial notes

Cognee is useful when Claude-adjacent teams want agents to build durable, connected memory from their own data rather than re-reading raw documents each time. It ingests data in many formats and continuously builds a self-hosted knowledge graph, so agents can recall facts by meaning and follow the relationships between them across sessions. Cognee also ships integrations, including a Claude Code plugin.

Its approach is distinct from conversation-memory tools: rather than extracting individual memories from chat turns, Cognee builds a knowledge graph over ingested data with vector embeddings, graph reasoning, and ontology generation, so retrieval is both semantic and relationship-aware.

## Key capabilities

- **Knowledge-graph memory** — ingests data and continuously builds a self-hosted knowledge graph for long-term, connected recall.
- **ECL pipelines** — an Extract, Cognify, Load flow that turns raw sources into graph and vector representations.
- **Graph plus vector retrieval** — combines vector embeddings and graph reasoning so results are searchable by meaning and by relationships.
- **Ontology generation** — cognitive-science-grounded ontology generation to structure and connect knowledge.
- **Multimodal ingestion** — unify data from various sources and formats into one knowledge layer.
- **Isolation and traceability** — tenant and user isolation, traceability, an OpenTelemetry collector, and audit traits for reliability.
- **Multiple clients** — Python (`cognee`), TypeScript, and Rust clients, plus a Claude Code plugin and other integrations.
- **Self-hosted** — runs locally with supported graph and vector databases.

## How teams use it

- **Company brain** — unify data from many sources into one knowledge layer that agents can query.
- **Persistent agents** — give agents long-term memory that connects facts and evolves as knowledge changes.
- **Graph-augmented retrieval** — retrieve by meaning and by relationships for more complex reasoning than plain vector search.
- **Cross-agent knowledge** — share a common knowledge graph across multiple agents.
- **Domain grounding** — ground agents in your domain data with ontology-structured context.

## Getting started

Cognee is open source and runs self-hosted. Install it with `pip install cognee` (TypeScript and Rust
clients are also available), configure a model provider and backing graph and vector stores, then
ingest your data so Cognee builds the knowledge graph through its Extract, Cognify, and Load steps.
Agents query the graph to recall facts and relationships with full context; a Claude Code plugin is
available for that workflow.

## Source notes

- The official repository describes Cognee as an open-source AI memory platform that gives agents persistent long-term memory by ingesting data in any format and building a self-hosted knowledge graph.
- Documented capabilities include combining vector embeddings, graph reasoning, and cognitive-science-grounded ontology generation so documents are searchable by meaning and connected by relationships that evolve over time.
- Cognee provides unified ingestion, graph and vector search, tenant and user isolation, traceability, an OpenTelemetry collector, and audit traits.
- Clients are available for Python (`cognee`), TypeScript (`@cognee/cognee-ts`), and Rust, and integrations include a Claude Code plugin.
- The GitHub repository is `topoteretes/cognee`, is Apache-2.0 licensed, is installed from PyPI as `cognee`, and targets Python 3.10+.

## Duplicate check

Checked current `content/tools/`, `content/mcp/`, agents, skills, hooks, rules, commands, guides, open pull requests, and repository-wide content for `Cognee`, `cognee`, `topoteretes`, `cognee.ai`, `github.com/topoteretes/cognee`, `AI memory platform`, and `knowledge graph memory`. Existing entries cover adjacent memory, RAG, and storage tools, but Cognee's knowledge-graph and ontology approach is distinct, and no dedicated Cognee tools entry, Cognee source URL duplicate, or open duplicate PR was found.

## Disclosure

Editorial listing. No paid placement or affiliate link is used.

About this resource

Editorial notes

Cognee is useful when Claude-adjacent teams want agents to build durable, connected memory from their own data rather than re-reading raw documents each time. It ingests data in many formats and continuously builds a self-hosted knowledge graph, so agents can recall facts by meaning and follow the relationships between them across sessions. Cognee also ships integrations, including a Claude Code plugin.

Its approach is distinct from conversation-memory tools: rather than extracting individual memories from chat turns, Cognee builds a knowledge graph over ingested data with vector embeddings, graph reasoning, and ontology generation, so retrieval is both semantic and relationship-aware.

Key capabilities

  • Knowledge-graph memory — ingests data and continuously builds a self-hosted knowledge graph for long-term, connected recall.
  • ECL pipelines — an Extract, Cognify, Load flow that turns raw sources into graph and vector representations.
  • Graph plus vector retrieval — combines vector embeddings and graph reasoning so results are searchable by meaning and by relationships.
  • Ontology generation — cognitive-science-grounded ontology generation to structure and connect knowledge.
  • Multimodal ingestion — unify data from various sources and formats into one knowledge layer.
  • Isolation and traceability — tenant and user isolation, traceability, an OpenTelemetry collector, and audit traits for reliability.
  • Multiple clients — Python (cognee), TypeScript, and Rust clients, plus a Claude Code plugin and other integrations.
  • Self-hosted — runs locally with supported graph and vector databases.

How teams use it

  • Company brain — unify data from many sources into one knowledge layer that agents can query.
  • Persistent agents — give agents long-term memory that connects facts and evolves as knowledge changes.
  • Graph-augmented retrieval — retrieve by meaning and by relationships for more complex reasoning than plain vector search.
  • Cross-agent knowledge — share a common knowledge graph across multiple agents.
  • Domain grounding — ground agents in your domain data with ontology-structured context.

Getting started

Cognee is open source and runs self-hosted. Install it with pip install cognee (TypeScript and Rust clients are also available), configure a model provider and backing graph and vector stores, then ingest your data so Cognee builds the knowledge graph through its Extract, Cognify, and Load steps. Agents query the graph to recall facts and relationships with full context; a Claude Code plugin is available for that workflow.

Source notes

  • The official repository describes Cognee as an open-source AI memory platform that gives agents persistent long-term memory by ingesting data in any format and building a self-hosted knowledge graph.
  • Documented capabilities include combining vector embeddings, graph reasoning, and cognitive-science-grounded ontology generation so documents are searchable by meaning and connected by relationships that evolve over time.
  • Cognee provides unified ingestion, graph and vector search, tenant and user isolation, traceability, an OpenTelemetry collector, and audit traits.
  • Clients are available for Python (cognee), TypeScript (@cognee/cognee-ts), and Rust, and integrations include a Claude Code plugin.
  • The GitHub repository is topoteretes/cognee, is Apache-2.0 licensed, is installed from PyPI as cognee, and targets Python 3.10+.

Duplicate check

Checked current content/tools/, content/mcp/, agents, skills, hooks, rules, commands, guides, open pull requests, and repository-wide content for Cognee, cognee, topoteretes, cognee.ai, github.com/topoteretes/cognee, AI memory platform, and knowledge graph memory. Existing entries cover adjacent memory, RAG, and storage tools, but Cognee's knowledge-graph and ontology approach is distinct, and no dedicated Cognee tools entry, Cognee source URL duplicate, or open duplicate PR was found.

Disclosure

Editorial listing. No paid placement or affiliate link is used.

Source citations

Add this badge to your README

Show that Cognee is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.

Listed on HeyClaude
[![Listed on HeyClaude](https://heyclau.de/badge/tools/cognee.svg)](https://heyclau.de/entry/tools/cognee)

How it compares

Cognee side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.

1 trust signal differ across this comparison (Submitter).

Next steps differ across entries — use the actions in the table below to copy install commands and source links per resource.

Field

Open-source AI memory platform that gives agents persistent long-term memory by ingesting data in any format and building a self-hosted knowledge graph, combining vector embeddings, graph reasoning, and ontology generation for meaning-based and relationship-based retrieval.

Open dossier

Open-source memory layer for AI agents and assistants that extracts, stores, and retrieves user, session, and agent memories so applications can personalize and remember across interactions, with Python and TypeScript SDKs and pluggable vector, graph, and key-value stores.

Open dossier

Open-source Python multi-agent framework for building agent societies, role-playing agents, stateful ChatAgent workflows, RAG agents, synthetic data generation, MCP-enabled use cases, and research-scale agent experiments.

Open dossier

Modular open-source Python framework for building AI agents and LLM workflows with structures, tools, memory, drivers, and RAG engines, from Griptape.

Open dossier
Next stepsDiffers
Trust
Review statusReviewedMaintainer reviewedReviewedMaintainer reviewedReviewedMaintainer reviewedReviewedMaintainer reviewed
Package trustPackage not verifiedPackage not verifiedPackage not verifiedPackage not verified
Source provenanceSource-backedSource-backedSource-backedSource-backed
SubmitterDiffersdavion-knightdavion-knightdavion-knight
Install riskReview firstReview firstReview firstReview first
Notes Safety Privacy Safety Privacy Safety Privacy Safety Privacy
BrandCognee logoCogneeMem0 logoMem0CAMEL-AI CAMEL logoCAMEL-AI CAMELGriptape logoGriptape
Categorytoolstoolstoolstools
Sourcesource-backedsource-backedsource-backedsource-backed
Authortopoteretesmem0aiCAMEL-AIGriptape
Added2026-07-092026-07-092026-06-182026-07-09
Platforms
CLI
CLI
CLI
CLI
Source repo
Safety notesCognee ingests your data and builds a knowledge graph that agents read from, so treat graph content derived from external or user data as untrusted input and constrain what an agent may do based on it. Use tenant or user isolation so one tenant's knowledge is not retrieved for another, and review which sources are eligible for ingestion. The extraction and cognify steps call a model provider with ingested content; scope credentials to the minimum needed and keep them out of source control. Cognee runs self-hosted, so secure the graph and vector stores and their endpoints, and do not expose them on a public interface without protection. Keep production ingestion and permissions narrower than quickstart examples, and set retention rules for the accumulating graph.Stored memories influence future agent behavior, so treat memories written from external or user content as untrusted input and constrain what an agent may do based on retrieved memories. Scope memory by a per-user or per-agent identifier so one user's memories are not retrieved for another, and review which content is eligible to become a stored memory. The memory-extraction step calls a model provider with conversation content; use credentials scoped to the minimum needed and keep them out of source control. Self-hosting keeps memories in your own stores, while the managed platform processes them under its terms; choose the deployment that matches your data requirements. Keep production memory stores and permissions narrower than quickstart examples, and set retention rules for accumulated memories.CAMEL agents can coordinate multi-step tasks, call tools, use web/search integrations, connect to MCP examples, and run with provider credentials; review tool permissions before giving agents write access or account access. Large-scale agent societies and role-playing workflows can generate high volumes of model calls, tool calls, logs, synthetic data, and intermediate artifacts; set budgets, rate limits, and stop conditions before long runs. RAG, document, media, browser, communication, and data-tool extras may access local files, third-party APIs, vector stores, notebooks, or generated datasets; isolate experiments from production systems. CAMEL examples include MCP-oriented use cases, but MCP does not make connected tools safe by default. Scope server permissions, credentials, filesystem access, and approval gates separately. Do not treat generated code, generated datasets, citations, research summaries, or multi-agent decisions as verified until they have been reviewed against source data and policy requirements.Griptape structures (Agent, Pipeline, Workflow) can call tools that run code, execute shell or Python, query databases, scrape the web, call external APIs, and read or write files; review each tool's side effects before enabling it. Tool names, descriptions, schemas, rulesets, and retrieved documents become model-facing context, so treat them as untrusted input that can influence the agent. Off-prompt Task Memory keeps large or sensitive tool outputs out of the prompt by default, but data returned to the LLM, other tools, or downstream tasks still needs review. Human-in-the-loop approval, rate limits, timeouts, and rollback policies belong on any tool that performs account, billing, data, or infrastructure actions. Keep production permissions narrower than notebook or demo examples, and scope model-provider and tool credentials to least privilege.
Privacy notesIngested documents and the resulting knowledge graph can contain personal, confidential, or proprietary data; apply retention, deletion, and access-control policies to the graph and vector stores. Extraction, ontology generation, and embedding send ingested content to the configured model and embedding providers, which process it under their own terms; local models keep that on your machine. Because Cognee is self-hosted, ingested data stays in the stores you configure, but any external providers used for processing follow their own data-handling policies. Provider keys, ingested data, and graph exports should be treated as sensitive and kept out of version control.Mem0 stores user preferences, facts, and history as memories, which can include personal or sensitive data extracted from conversations. Memory extraction and embedding send conversation content to the configured model and embedding providers, which process it under their own terms; local models keep that on your machine. Stored memories persist in the vector, graph, or key-value backend you configure, so apply retention, deletion, and access-control policies to that store. Provider keys, memory data, and any exports should be treated as sensitive and kept out of version control.Prompts, model responses, agent messages, tool arguments, tool outputs, retrieved documents, search results, logs, generated datasets, traces, and errors may include user or workspace data. Model providers, search providers, MCP servers, vector stores, web tools, document parsers, browser tools, and observability integrations may receive data from CAMEL workflows. Keep provider API keys, OAuth tokens, MCP server credentials, vector database URLs, generated logs, and synthetic datasets out of committed examples, screenshots, public issues, and shared notebooks. If `CAMEL_MODEL_LOG_ENABLED` or other logging/tracing integrations are enabled, review request/response logs and model configuration logs before sharing or retaining them.Griptape runs can send prompts, instructions, conversation memory, tool arguments, tool results, and retrieved context to configured model providers and embedding services. Tools and drivers can expose local files, database records, API responses, secrets, or proprietary business data to the model and workflow if they are made available to a structure. Conversation memory, task memory, vector stores, and any observability or run-logging destinations can retain prompts, outputs, embeddings, and metadata outside the application runtime. The managed Griptape Cloud processes data you send to it; review its data-handling terms before sending production or customer data. RAG and web/file loaders can pull third-party or workspace content into prompts, memory, and stored artifacts, so apply normal retention and access-control policies.
Prerequisites
  • Python 3.10+ project and a dependency manager to install `cognee` from PyPI (TypeScript and Rust clients are also available).
  • A model provider for extraction and embeddings, or local models if you prefer to run them yourself.
  • Backing stores for the knowledge graph and vectors (Cognee runs self-hosted with supported graph and vector databases).
  • The data sources you want to ingest, and stable tenant or user identifiers if you need isolation between them.
  • Python or TypeScript project and a package manager to install the SDK (`mem0ai` for Python or the TypeScript SDK for Node).
  • A model provider for the extraction and embedding steps, or local models if you prefer to run them yourself.
  • A backing store for memories (a supported vector store, and optionally a graph or key-value store) for self-hosted use, or a Mem0 platform key.
  • Stable identifiers for the user, session, or agent whose memories you are storing and retrieving.
  • Python 3.10 through 3.14 and an isolated Python environment managed with pip, uv, or another package manager.
  • A configured model provider such as OpenAI or another provider supported by the selected CAMEL model route.
  • Provider API keys, search credentials, vector database credentials, or tool-specific secrets stored outside source control.
  • Optional extras for web tools, document tools, RAG, model platforms, storage backends, dev tools, or research tools only when those integrations are required.
  • Python 3.10+ project and a dependency manager to install `griptape` (optionally with extras such as `griptape[all]`) from PyPI.
  • Model-provider credentials or local model configuration for the prompt, embedding, and vector-store drivers the agent uses.
  • Clear tool, driver, and memory boundaries before connecting structures to databases, APIs, files, web scraping, or code-execution tools.
  • A decision on self-hosting the open-source framework versus using the managed Griptape Cloud, with the matching data and secret handling plan.
Install
pip install camel-ai
Config
Citations
ClaimUnclaimedUnclaimedUnclaimedUnclaimed
Open 4 picks in the interactive comparison tool

Related guides

Signals

Loading live community signals…

More like this, weekly

A short, calm digest of reviewed Claude resources. Unsubscribe any time.