Build with AI

Memory for AI agents

Context windows forget. An agent whose knowledge lives in a graph traverses what it knows — what did I decide about X, what depends on it, who said what about it last Tuesday — instead of replaying its own history and hoping.

The model

The shape of the problem

Agent memory isn't a list of paragraphs to retrieve by similarity. It's a web of entities — people, tools, facts, decisions, tasks — connected by typed edges that carry meaning. Stored as tokens, that structure is flattened and re-inferred every prompt, at full corpus cost. Stored as a graph, retrieval becomes a traversal with a defined answer, bounded by neighbourhood size — which is why graph retrieval cuts token spend by ~98.7% at 2,000 entities.

A database that's a function call

When the engine starts in milliseconds, a graph can be born when the agent starts and gone when it finishes — context scoped to a run, real-time rather than batch, zero standing footprint while idle. Per-task isolation stops being a prompt-engineering problem and becomes a credential boundary.

MCP makes the graph a first-class tool

The MCP server gives any compatible client two capabilities: read the schema, run a query. The agent discovers what its memory contains and composes its own questions — no bespoke tool per question you anticipated.

Snapshots, replay, and provenance for free

Every fact links to where it came from, so the citation is always a hop away. Backups restore to a new instance, which makes a reasoning session replayable by construction — fork the snapshot, explore the what-if, and the original is never touched.

What the agent knows about an entity, with sources, newest first.cypher
MATCH (a:Agent {id: $agent})-[:LEARNED]->(f:Fact)-[:ABOUT]->(e:Entity {name: $entity})
MATCH (f)-[:FROM]->(src)
RETURN f.statement, src.title, f.at
ORDER BY f.at DESC

Questions

Agent memory, asked directly.

Why a graph instead of a vector store?

They answer different questions. Similarity search finds text that sounds related; a graph answers structural questions exactly — what depends on this, what did I already decide, which source said so. Many stacks run both; the graph is the part that makes answers auditable.

How does the agent actually query it?

Over MCP: the server exposes schema inspection and Cypher execution to Claude, Cursor and any MCP-compatible client. Read-only mode exists for agents that should explore but never write.

One shared graph or one per agent?

Per agent (or per session) is the pattern CognoDB is built for — instances provision quickly and bill by the second, so isolation costs almost nothing while idle. Share a graph only when agents genuinely need shared memory.

What happens when a session ends?

Your choice: keep the instance as persistent memory, pause it (storage-only cost), or delete it. Deletion is soft for 30 days with a final snapshot.

How do facts get in?

The agent writes them — MERGE for entities so repeated observations converge, CREATE for events. The same Bolt connection the drivers use; nothing agent-specific to deploy.

Can I inspect what an agent has learned?

Yes — it's a database. Open it in the console's browser, run Cypher against it, or point a second read-only MCP client at it and ask.

Start now

~98.7%

token efficiency at 2,000 entities — see the footnotes above

Put your first graph up in a minute.

A free instance takes about a minute and no card. Write two MERGE statements, read them back, and you have a living graph — with provenance on every fact.

First-graph path

Live
  1. Create a free instance

    No card. Ready in about a minute.

  2. Connect your driver

    bolt+ssc:// URI into the driver you already use.

  3. Write two MERGEs

    That's the entire shape of agent memory.

  4. Point an agent at it

    One MCP config block. No integration code.