cognee 1.0: The Open-Source Memory Platform for AI Agents

One brain. Every agent.

I started building AI memory before most people thought agents needed any. The question that pulled me in was simple: how is it that a person can come back to a project and pick up right where they left off, while an agent with a million-token context window forgets everything the moment the session ends?

That question became a conviction that memory is not a feature you bolt onto an agent — it's the layer the whole agent stack is missing.

Everything in cognee 1.0 is one bet, expressed in three ways:

1. Make the memory layer open,
2. Make it something you truly own,
3. Make it available anywhere your agents run.

Today, my team and I are releasing that bet as cognee 1.0.

It is the first version I am proud to put my name on, and it carries more of what I believe about this problem than anything we have shipped before.

This release has something for developers and teams at very different stages:

• Managed Cloud for those who don't want to operate memory infrastructure.
• A single Postgres for those wanting to stay close to the stack they already run.
• A Rust SDK for edge and on-device memory.
• A TypeScript SDK for Node-based agent workflows.
• A memory-native API built around remember, recall, forget, improve.

What I got wrong first

Early on, we believed the answer was to make developers adopt a more sophisticated storage stack. We leaned hard into graph databases, because a graph is genuinely the right way to model how facts relate to each other.

But we learned something the hard way: almost nobody wants to run a graph database. Enterprises don't want another system to license, secure, and operate. An individual developer just wants to install something and have it work. We had built something powerful, but too much of that power was locked behind infrastructure most users did not want to run.

The second lesson was about ownership. The memory of your agents is the memory of your business. No serious team was going to hand that to a black box they couldn't inspect, host themselves, or take with them if they left.

Those two lessons are why 1.0 looks the way it does. We stopped asking people to adopt our complexity, and started meeting them where they already were.

How we rebuilt cognee

1 – The surface area

Earlier versions were shaped around the steps cognee had to perform: add data, process (cognify) it, search it. That made sense to us as builders, but not to agents.

Agents don't think in pipelines. They need to remember, recall, forget, and improve. So in cognee 1.0, those four verbs became the API.

• remember adds new information to memory.
• recall retrieves what matters in context.
• improve updates memory from use, correction, and feedback, so the system can get better instead of only getting bigger.
• forget removes data when it should no longer be used.

The core flow is those four lines:

import cognee

await cognee.remember("cognee turns documents into agent memory.")

answer = await cognee.recall("What does cognee do?")

await cognee.improve()  # memory re-weights itself from use

await cognee.forget(dataset="main_dataset")

2 – Where cognee can run

Your agents shouldn't have to move to where the memory is — the memory should meet them where they already work.

One install — pip install cognee — and connect cognee to Claude Desktop, Claude Code, Cursor, Codex, OpenClaw, Windsurf, Gemini CLI, Cline, plain REST, or any MCP-compatible agent. For JavaScript and Node workflows, cognee 1.0 also includes a first-class TypeScript SDK alongside Python.

3 – Memory ownership

You can use cognee as a managed Cloud solution, self-host it, run it on infrastructure you already operate, or use the new Rust core when memory needs to run in lightweight environments closer to the edge.

Your data is portable too: cognee can export to the open COGX format, so the memory you build doesn't become another locked system.

That's what cognee 1.0 is meant to be: not another isolated memory feature inside one agent, but a shared memory layer your agents can use anywhere, improve over time, and that remains yours.

One brain. Every MCP agent reads and writes the same memory.

Building memory you can trust to learn

This is the part I am most proud of, and the part that took the longest.

Most memory tools are built to store more; cognee is built to get better with use. When agents retrieve, correct, reuse, or ignore information, those interactions become signals. Over time, cognee can learn which facts matter, which ones are outdated or wrong, and which pieces of memory agents actually rely on.

That changes the role of memory in production. A correction shouldn't die inside one chat — if an agent gets something wrong, the system should be able to absorb that feedback so the same mistake is less likely to happen again.

That's what makes a memory layer trustworthy in real workflows. We cover the mechanics of how this loop works here.

What the numbers say

Memory systems behave very differently depending on the task, the data, the retrieval pattern, and how agents use the results. Still, we have tested cognee extensively against other memory systems, long-context baselines, and agent-style retrieval workflows, because production memory needs to be quantified, not just claimed.

Across those tests, the pattern has been consistent: cognee performs strongly on memory quality while staying efficient as data grows.

The important point is not that a benchmark can serve as a definitive score, but that the same pattern keeps showing up from different angles. Larger context windows help, but they can't replace structured, persistent memory that knows what to keep, what to connect, what to update, and what to ignore.

The production numbers tell the same story. Around 6 million memories are created on cognee every month across 100+ companies. At Bayer, for instance, cognee is used in scientific research workflows, helping researchers work with connected knowledge and generate hypotheses from complex information sources.

The range is the real proof. The same engine can support a personal second brain, a sales team's deal memory, an equity-research desk, a ship's maintenance manuals, and a developer's coding-error knowledge base.

cognee is seed-stage, backed by Pebblebed — run by Pamela Vagata of OpenAI's founding team and Keith Adams, ex-Facebook AI Research — with 42CAP, Vermilion Cliffs, and angels from Google DeepMind, n8n, and Snowplow.

What I hope happens next

The next hard problem in agents won't be getting one agent to answer one question well. It will be getting many agents to work together across tools, teams, and systems that were never designed to share state.

We want to enable stateful agents.

That only works if there is durable memory underneath. Agents need a place to preserve what happened, what changed, what was corrected, what should be ignored, and what another agent already learned. Without that layer, every workflow eventually becomes a chain of systems trying to reconstruct context from scratch.

My hope is bigger than cognee. I want agent memory to become an open layer for stateful agents, not another closed feature inside one vendor's product. We shouldn't have to choose between functional and controllable memory.

That's the company I want to build: useful enough to be recognized, open enough that people can trust it, and portable enough that no one is trapped inside it. cognee 1.0 is the clearest statement of that mission we have shipped so far.

Give your agents memory they can keep

Already using Mem0, Zep, or Letta? Bring your memory into cognee in one line, then export it to the open COGX format whenever you need to.

That's the point of cognee 1.0: your agents get memory that works, and you keep control over the memory they build.

Get your free Cloud key and start building now!

Let's build the memory layer for all agents — open, owned, and free to run with the providers you choose. — Vasilije Marković, Founder and CEO, cognee