Cognee v1.5.4 is a reasonable candidate for teams that want self-hosted, persistent memory for AI agents and can operate a Python service plus a graph/vector stack. Adopt it for internal tools and pilots where you control the data and can absorb upgrade churn; hold off for regulated, always-on production until you confirm the licensed Postgres graph path, your storage backends, and the migration behavior. This is a source and documentation review, not a runtime test.
facts about this cognee review
| Field | Value |
|---|---|
| Author / reviewer | Xiang Peng (XP812) |
| Review method | Source and documentation review of the public repository, README, release notes, and open issues. No installation, benchmark, or deployment was run. |
| Review date | 2026-09-10 |
| Version / release snapshot | v1.5.4, published 2026-09-04; repository last pushed 2026-09-09; snapshot collected 2026-09-10 |
| License | Apache-2.0 |
| Stars (snapshot) | 30,609 stars and 3,011 forks on 2026-09-10, as reported by the GitHub API |
| Language | Python |
| Verification level | observed |
| Material unknowns | No runtime, load, security, or upgrade test was performed. Benchmark figures are maintainer-reported. The licensed production Postgres graph path, real throughput limits, and per-tenant isolation behavior are not verifiable from the documents reviewed. |
the problem: agents that forget between sessions
The decision this review serves is narrow and practical. You already run an assistant, support bot, or internal agent, and every new session starts blank: past decisions, resolved tickets, and user preferences are gone. You are at the evaluation stage, deciding whether to add a self-hosted memory layer instead of rebuilding your application around one vendor’s managed store.
Cognee is one candidate for that job. The repository describes it as an open-source AI memory platform that gives agents persistent long-term memory across sessions using a self-hosted knowledge graph. In practice, adopting it means operating a Python service, owning a data model, and keeping up with an upgrade path.
what the v1.5.4 release changed
Maintainers label v1.5.4 “Stability & Integrations” and describe it as a patch release focused on reliability, data-ingestion convenience, front-end polish, and security hardening. Most of the value is in fixes, so upgrading is less about new capability and more about whether you can absorb two breaking changes.
breaking changes to check before upgrading
- The
repositoriesparameter was removed from the affected API and CLI calls. If your integrations pass it today, maintainers say to update them to the new calling pattern and check the OpenAPI or SDK docs for the current signature. COGNEE_ALLOWED_LOCAL_FILE_ROOTSis now disabled by default. If you relied on it to let the server read local paths, you must explicitly re-enable it and verify that the permitted paths are still correct.
A related release, v1.5.3.dev1, carried two more changes that affect self-hosted operators: the Postgres graph adapter was rewritten and moved, so code importing the old adapter may need path or configuration updates, and the MCP workspace UI was removed. If you are upgrading across that boundary rather than from v1.5.3, treat both as migration work rather than a routine patch.
security and reliability changes worth noting
Maintainers report that API tokens are now redacted in startup logs, local file-root access is off by default, migrations run once per process, logging is initialized once, and the graph is written before vectors during storage operations to reduce partial writes. Those are sensible hardening and consistency changes, and they also describe a system that was recently fixing ordering and race issues. That is useful context for how much testing your own deployment will need.
how cognee is meant to be used
The README positions cognee around three patterns: a company brain that pulls documentation, conversations, tickets, and code into shared memory; agent memory across runs, so one session can retrieve decisions and fixes from another; and domain grounding through custom data models and ontologies. The public surface is a small set of operations: remember, recall, improve, and forget, reachable through a Python API, a TypeScript SDK, a REST API, or MCP, plus plugins for tools such as Claude Code and Codex.
For a founder or operations manager, the practical read is that cognee is infrastructure, not an end-user product. The closest thing to a packaged experience is the bundled CLI demo, which maintainers say runs without an API key, and Cognee Cloud, which they offer as the managed alternative.
deployment concerns before production
Several conditions in the documentation should shape your plan before you commit.
- Provider calls are the default. The README states that the default setup uses OpenAI for language models and embeddings, and that processing and generated answers make provider calls. Local Ollama models, including a local embedding model, are documented as an option. Budget for external API cost and for data leaving your environment unless you switch providers.
- The runtime footprint is more than one process. Running the API, UI, and MCP server from a source checkout uses Docker Compose with
uiandmcpprofiles on ports 8000, 3000, and 8001. The UI launcher requires Node.js and npm, and Docker is needed for its MCP service. - Version constraints are explicit. v1.5.4 lists Python
>=3.10,<3.15, pydantic>=2.10.5, and litellm>=1.83.7,<1.97.0, among others. Pinning these in your own image avoids surprises. - Authentication and storage are your responsibility. Maintainers describe the minimal Compose setup as a single-user demo and point to a permissions guide and deployment templates for anything beyond that.
Maintainers warn in the README that running the whole memory layer on a single Postgres instance (relational metadata, PGVector, and graph together) is currently released as a demo feature, and that the production-ready version is a licensed product.
That single sentence should settle a lot of architecture conversations. A team that reads “Postgres simplifies the stack” and ships it is acting on a demo path, not a supported production one. If Postgres consolidation is central to your plan, confirm licensing and support terms with the maintainers first.
maintenance signals from the repository
The release history shows a fast, small-patch cadence: v1.5.1, v1.5.2, v1.5.3, and v1.5.4 all landed between 2026-08-21 and 2026-09-04, each describing stability, search-relevance, and ingestion-reliability fixes. Frequent small releases are a positive maintenance signal, but they also mean your upgrade discipline has to be real.
The backlog is the other side of the picture. The snapshot shows 514 open issues. A large share of recent activity is hackathon-labeled contributor work, including integrations that remain open in the issues reviewed: a Vellum integration, an Aider CLI integration, a companion session dataset, mid-session dataset switching, and on-demand subgraph generation. Those are roadmap items, not shipped features, and that is useful context when deciding how much of your workflow to build on the current API.
On performance, the README reports maintainer-run BEAM scores of 0.79 at 100K tokens and 0.67 at 10M tokens, and describes the second as exploratory. The page itself notes the two settings use different conversations, ingestion models, and retrieval procedures, and documents a remaining reproduction gap for distributed 10M ingestion. Treat those numbers as directional claims from the project, not a comparison you can rely on for procurement.
who should use cognee, and who should wait
a reasonable fit
- Teams building internal agents or copilots that need session-to-session recall and can run and patch a Python service.
- Organizations that must keep memory self-hosted for data-control reasons and are comfortable with provider calls or a local model setup.
- Developers who want a graph-based memory layer they can extend with custom ontologies, under a permissive Apache-2.0 license.
- Pilots and proofs of concept where a fast release cadence is acceptable because you control the deployment window.
not a fit yet
- Teams that need a documented, supported Postgres-only production topology today.
- Buyers who want a managed SLA and no infrastructure ownership. Cognee Cloud is the maintainers’ answer to that, and this review cannot assess it.
- Anyone unwilling to pin dependencies and re-test ingestion and search after each upgrade.
- Projects where the memory layer must pass a formal security or compliance review; the review set here is documentation only and contains no such attestation.
alternatives and questions to ask before adopting
Before committing, work through a short list. What is your data classification, and can prompts and embeddings leave your environment? Which storage backends are supported for production, and where does the licensed graph path fit? What is your rollback plan for the removed repositories parameter and the changed local-file default? Who owns dependency pinning when litellm or pydantic moves?
On alternatives, the maintainers document a COGX exchange format for importing memory from Mem0, Letta, Zep, or Graphiti, so cognee works as a consolidation target if you already run one of those. Cognee competes on self-hosting and graph structure rather than being the only option; if you need a managed service or narrower vector search, another tool may fit better.
verdict
Cognee is worth a serious pilot for teams that need self-hosted agent memory and have the engineering capacity to own a Python service. The project is active, the license is permissive, and the docs state the constraints plainly.
It is not yet a drop-in production memory layer for a buyer who wants to avoid infrastructure ownership. The demo status of the Postgres graph path, breaking changes landing in patch releases, and a 514-item backlog are the three conditions to resolve before putting it on a critical path. This is a source and documentation review; the version, date, and unknowns above define what it can and cannot tell you.
sources
- topoteretes/cognee repository and README
- Cognee v1.5.4 release notes (2026-09-04)
- Cognee v1.5.3.dev1 release notes (2026-08-26)
- Cognee documentation
- Open issue #3625: JSON Schema to graph utilities
If you are wiring persistent memory into an existing agent stack, most of the work is integration and upgrade planning rather than a fresh build: aligning provider configuration, choosing storage backends, moving off the removed repositories argument, and re-checking local file access after the v1.5.4 default change. I take on that kind of work as custom AI and agent development. To scope it I would need your current stack (agent framework, model and embedding providers), where memory should live, your data classification, and a representative workflow that currently fails or is unclear. I would start from that assessment rather than promise an outcome. If that matches your situation, send me the details.