CogDB gives AI agents one interface for episodic, semantic, and procedural memory

Memory becomes infrastructure when agents have to remember together

An AI agent can get surprisingly far with a chat transcript and a few retrieved documents. The harder problems arrive when it must distinguish an event from a durable fact, reuse a successful process, or share context with other agents without treating every piece of memory the same way.

CogDB is an early-stage Python project aimed at that boundary. Its README describes a single memory system with three categories: episodic memory for what happened, semantic memory for what is known, and procedural memory for how to do something. The project packages those categories behind one API, rather than asking an agent developer to directly coordinate separate interfaces for vector retrieval, facts, and workflows.

That makes CogDB most relevant to builders working on agents that operate over time: support or operations assistants, coding agents, research workflows, and multi-agent systems where recalled context needs more structure than a single text buffer.

Three memory types, one query surface

The project’s central model is deliberately concrete.

Episodic memory records dated interactions, observations, and tool calls. In the documented API, db.remember() stores a piece of text with an agent_id and an importance value. The README says these records are stored as vector embeddings, numeric representations used to find semantically similar text.

Semantic memory represents facts as subject, predicate, and object triples. For example, an agent can record that api_service has version v2.3 with db.learn(). CogDB describes this store as a temporal knowledge graph, meaning facts can have confidence, provenance, validity windows, and lifecycles. Its documentation says newer contradictory facts can supersede earlier ones.

Procedural memory stores reusable workflows. The db.learn_procedure() example accepts a name, a series of action and tool steps, the responsible agent, and contexts in which the workflow applies. In the README’s CORS example, the workflow captures a sequence from inspecting an Nginx configuration through verifying the result. This is a useful distinction: a fact such as “the service runs version v2.3” is not the same thing as a repeatable repair process.

All three are intended to be retrieved through the same database object. The quick-start flow creates CognitiveDB, writes memories using the appropriate method, then calls db.recall() with a natural-language query and a token budget. That design lets application code express the kind of information it is saving without requiring a different retrieval client for each category.

Retrieval that starts with a budget

CogDB’s other notable design idea is token-aware retrieval. Language model prompts have finite context windows, and every recalled item competes with instructions, current user input, tool results, and generated output. Simply returning every plausible memory can make the prompt less useful.

The README describes a tiered context model. L0 contains identity information, L1 holds critical facts, L2 contains task-relevant material, and L3 is for deeper search. A caller supplies a token budget, and the project says it fills the budget from higher-priority tiers first with memories that fit.

The practical implication is that retrieval becomes an explicit product decision. A small budget can favor stable identity and high-importance facts. A larger one can make room for task-specific context or deeper results. CogDB also exposes get_context() with a level, task hint, and token budget, so an application can request progressively richer context instead of always sending the same bulk memory payload.

This is a sensible interface for builders to inspect closely. Token budgeting is only as useful as the project’s importance signals, ranking behavior, and estimate of each result’s size. CogDB documents importance scores and a learned importance model in its roadmap, while the manifest confirms tiktoken, a library commonly used to count tokens, as a dependency. Teams evaluating the project should test whether the retrieved tiers match their own tasks and prompts.

A memory layer for several agent ecosystems

CogDB documents adapters for AutoGen, LangGraph, CrewAI, the OpenAI Agents SDK, Semantic Kernel, and LlamaIndex. It also provides an MCP server entry point, cogdb-mcp. MCP, or Model Context Protocol, is a way for compatible agent tools and clients to expose callable capabilities through a shared protocol.

The documented MCP server exposes six operations: remember, recall, learn, learn_procedure, get_context, and forget. For framework users, the examples take a more native shape. The AutoGen adapter is presented as a memory object; the LangGraph integration provides checkpoint and store implementations; and the LlamaIndex integration offers chat memory and a vector index.

These adapters matter because memory APIs tend to leak into application architecture. A project can make storage more replaceable when it meets a framework at the framework’s extension points, such as a checkpointer or memory store, rather than requiring each agent to call custom functions throughout its business logic.

CogDB also documents four memory scopes: organization, team, private, and session. The first three express widening access boundaries, while session memory is described as ephemeral and automatically deleted. The README says contradiction detection runs during writes and that conflict resolution addresses concurrent writes. Those are important behaviors to validate against a deployment’s access controls and concurrency requirements, especially because the project’s manifest classifies the release as Alpha.

What the Python package brings together

The repository metadata lists Python as the primary language, and pyproject.toml requires Python 3.10 or newer. The package is version 0.4.0 and uses Hatchling as its build backend.

Its declared core dependencies reveal the components behind the documented model. ChromaDB is included for vector-oriented storage and retrieval. NetworkX supports graph data structures, which fits the semantic knowledge-graph concept. sentence-transformers supplies embedding models for turning text into vectors, while tiktoken supports the token-budgeted retrieval workflow. Pydantic is included for typed data validation.

Optional dependency groups cover AutoGen, LangGraph, and MCP, with separate development, benchmarking, and machine-learning extras. The manifest’s explicit MCP command also makes the server interface part of the installable package rather than just a README integration sketch.

The documentation additionally presents schema migration support. Its example builds a versioned migration that adds a field with a default value and renames another field before calling db.migrate_schema(). For agent applications that accumulate metadata over time, treating schema changes as a first-class operation can be preferable to quietly accepting incompatible old records.

CogDB is therefore not just proposing a place to save chat history. It is proposing that agent memory needs categories, scopes, lifecycle rules, integrations, and prompt-budget discipline. The project is still labeled Alpha, so it is best approached as a system to prototype and verify with representative workloads. Builders who want to examine that approach can start with the repository at https://github.com/MuLIAICHI/cogdb.