← All talks

Session XIX · 28 October 2026

Real-time knowledge graphs for AI agents with Graphiti

Presented by Pablo Pousada

Episodic memory for agents on a knowledge graph that keeps history: how Graphiti works, a local demo, and where it stops being a good fit.

What was covered

  • The memory problem. Classic RAG is stateless: chunks and embeddings have no sense of time or of how files relate, so complex reasoning is hard. Static knowledge graphs have structure but no temporal awareness. When a fact changes, the graph is rebuilt or heavily edited, and the history is lost.
  • Episodic memory. The proposal is a graph that tracks how facts change and never deletes the past. It rests on three ideas. Validity windows record when a fact started and stopped being true. Epistemic memory ties every fact back to the document that produced it. Dynamic ontologies let the types of node and relation change as the domain changes.
  • What it gives you. Graceful invalidation, because a fact that stops being true is marked and not removed. Hybrid retrieval, where vector search finds the nodes and graph pathing follows the relations. And shared state for multi-agent systems, where several agents read and write at once without a restart.
  • How Graphiti is built. Episodes are the raw data. Entities are the nodes, each with a summary and the episodes that mention it. Facts are the edges between nodes, with timestamps for when they became true and when they stopped. Everything traces back to an episode.
  • The demo. A local setup with Docker and Neo4j that ingests raw text, JSON, batches, conversations and temporal facts. In a bulk JSON run the writes took about 30 seconds and a query over the same data came back in under a second. The relations are created during ingestion, and node and relation types can be fixed in advance or left dynamic.

What came up

  • Writes are expensive, reads are cheap. Ingestion needs many LLM calls, so against an API it runs into concurrency limits and cost. The read path is a plain graph search and is fast.
  • Ontology drift. As data grows, the model keeps relations less consistent, duplicates nodes and invents categories. It needs regular jobs to clean up, compress and recategorise the graph.
  • It is a framework, not a product. Access control, graph partitioning and maintenance fall on the team. The library also sends telemetry by default, which has to be blocked explicitly in sensitive projects.
  • Compared with RAG. It suits small facts that change often, such as chat transcripts or JSON payloads. Large documents like PDFs ingest slowly and poorly, so a separate RAG for documents is still the better tool.
  • Where the room saw it fitting. As short-lived memory that agents in a multi-agent task spin up and then discard, or as a harness-level graph of simple project facts (which technology a project uses) for a coding agent to query.

Takeaway

Graphiti is worth trying where facts change and the history matters, in small and fast-moving data. For a large and stable document base it adds cost and upkeep that retrieval does not.