Graphiti Local and the mistakes a memory keeps

A bad answer can be retried. A bad memory keeps coming back.

The case

I wanted local agent memory that could remember a project decision without letting the agent decide what became a stored fact. In the synthetic walkthrough, Aurora Analytics starts on DuckDB. PostgreSQL appears only after a person approves and applies the proposed change.

Graphiti Local is my independent open-source project built on Graphiti. It is not affiliated with or endorsed by Zep.

The local setup uses Ollama for extraction and embeddings, with LadybugDB holding the graph in one file. No cloud API key. No Docker. The difficult part was making the write boundary useful when a small model got the facts wrong.

The numbers

The full walkthrough was measured on 11 September 2026, on an Apple M5 with 32 GiB memory, using local qwen2.5:7b and nomic-embed-text. The tested versions were Graphiti Local 0.3.0, graphiti-core 0.30.1 and LadybugDB 0.19.1. These are observations from one machine and a synthetic fixture. Downloads are excluded.

An MCP client found six read tools and retrieved the approved PostgreSQL fact. The captured results and failed attempts are public.

The guide published on 23 September reports a clean-directory run of the one-command read demo in 10 seconds, installing 54 packages. It searches a shipped synthetic graph by keywords. It contacts no model and does not test extraction.

What worked

• A separate proposal queue. Before approval, the PostgreSQL change was visible as a pending proposal but absent from stored facts. An unapproved drain had nothing to apply.
• Readers opened read-only. Earlier, the MCP server held the embedded database’s write lock and blocked other commands. Read-only readers let the server keep answering while the separate writer applies approved changes.
• Checking the embedder before ingest. The configured vector width must match the endpoint. The database also records the embedder that wrote it, so a later ingest under a different embedder is refused.
• A small read-path demo. One command lets someone inspect retrieval before downloading models or configuring a database.

What failed

• An episode receipt hid a missing relation. In two plain-JSON attempts, extraction omitted an entity. The relation was discarded even though the episode write reported ingestion. A receipt alone did not prove the fact had landed.
• Valid output shape did not mean valid facts. Schema-constrained extraction completed, but the small model incorrectly invalidated a reporting-database fact when an unrelated documentation fact arrived.
• The embedded search indexes were missing. The tested Kuzu driver declared full-text indexes without creating them. Hybrid search failed with a Binder exception until the indexes were created explicitly.

The final fixture narrowed the walkthrough to one clearly named organization and one database change. That made the walkthrough work. It did not establish extraction accuracy on arbitrary notes. The generic verification command also returned warnings; the specific CLI and MCP queries passed.

The architecture

Agent or MCP client
        |
        v
Six read-only tools --> LadybugDB graph file
                              ^
                              |
Proposed fact --> Human review --> Separate approved writer

The model can propose a change. The proposal stays outside the graph until a person approves it and runs the writer. Approving the text does not guarantee that extraction or invalidation will be correct; the resulting facts need inspection too. After application, the stored facts carry validity timestamps, so the previous database decision can remain as history.

The same boundary is part of the context layers I build for AI agents. This local fixture demonstrates the boundary; it is not a production workload or a tenant-isolation benchmark.

Next-step checklist

• Inspect the read demo:

  uvx --from git+https://github.com/renezander030/graphiti-local kg-demo
  

• Follow the local setup guide for the model-backed path.

• Check retrieved facts and their validity timestamps after ingestion.

• Confirm a proposed update is absent before approval and present after application.

• Choose an explicit isolation boundary before sharing a deployment across users.

• Report a successful or blocked setup with synthetic output and the failing step, if any.

Which fact could your agent store today without anyone checking it?