inspeximus: agent memory with provenance, GDPR erasure and a tamper-evident aud…

inspeximus

Tamper-evident long-term memory for AI agents. Correct a fact once and the old value stays retired; erase a person and prove it; show an auditor what the agent knew when it acted. One zero-dependency Python file, plus an MCP server.

The erasure proof covers this store only, not a vector index, prompt logs, or backups, and it is an integrity primitive, not a compliance certification.

Quickstart · Docs · vs mem0 and Graphiti · Migrate from mem0 · EU AI Act and GDPR evidence · Claude Code, one line · Transparency log · PyPI

pip install "inspeximus[crypto]"

inspeximus demo # a first result: offline, touches nothing of yours

from inspeximus import Inspeximus

m = Inspeximus("memory.json") m.remember("The staging database is db-3.internal", key="staging-db") m.remember("The staging database is db-7.internal", key="staging-db") # a correction m.recall("which staging database")0 # 'The staging database is db-7.internal' m.revert("staging-db") # and it is reversible, on purpose

memory.json is a name, not a format: a new store is a SQLite file. Read it through inspeximus or the sqlite3 module, never with json.load or cat.

Why inspeximus

Use it when the agent runs for days and the facts it holds will change under it, and when somebody can later ask what it knew and what it erased. That is the whole design brief.

agno is the one that is not ours. It ships an official integration example in its own cookbook, cookbook/11_memory/integrations/inspeximus_integration.py, merged in agno#10146 on 2026-09-20, alongside mem0, zep, memori and dakera. Their own README describes it as *"inspeximus for corrections that stay corrected."* We did not write that file's home and we do not maintain it, which is exactly why it is worth listing: it is one integration a reader can check without taking our word for anything. The same holds for agmi, an agent-memory integrity scorecard whose maintainer merged our three-row adapter, agmi/adapters/inspeximus_rows.py, in agmi#1 after reproducing it himself.

Not the right tool when you want a hosted service with a dashboard, a knowledge graph over documents, or the highest score on a conversational-recall benchmark. mem0, Zep and cognee lead there, and the comparison page says where each of us wins and where we do not.

The receipts

We measured the one thing the others do not publish: how often a corrected fact comes back.

Each system was run on its own native configuration, same task, same 30 trials:

n = 30 per system. mem0 measured at 2.0.11 (2026-07); mem0 is now on 2.0.18 and we have not re-run it — the version is stamped rather than the claim being restated as current. Full method, raw arrays and the re-runnable harness: RAMR · echo_resistance_backends_result.json

Read the Graphiti row correctly — its echo defense did not fail. Our own raw output records

echo_attributable_flips: 0 out of 26 corrections that were extracted correctly before the echo

ran. Graphiti's bi-temporal invalidation held every one of them. The 13.3% above is four *pre-echo

extraction misses* — the correction never made it into the graph — which is a different failure from

the one this table is about. Stated as the mechanism rather than the headline: on echo-attributable

resurrection, Graphiti scores 0%, the same as us, by keeping the supersession link at write time.

That is the real finding here: what separates these systems is whether the link is recorded, not who

recorded it.

Two numbers you can check in three seconds, with no API key

Measured 2026-08-25 against Hindsight 0.9.2 (vectorize-io, 21k stars) and mem0, each in its own native config, n=20. These two need no judge at all — they read the raw recall payload, so nothing depends on a model reading well:

Both competitors return the corrected value *and* the retired one, and leave the choice to the caller. That is a defensible design — a bitemporal store handing back old and new with validity markers is being honest — but it is a different promise from ours, and the difference is whose job disambiguation is.

The first row is free to verify. No key, no server, no network:

git clone https://github.com/DanceNitra/inspeximus && cd inspeximus

python probes/integrity_bench_store_resolves.py --systems inspeximus

It finishes in milliseconds and prints store-resolved=1.00 (resolved=20 both=0 stale=0 neither=0, n=20). Adding ,mem0 or ,hindsight reproduces their columns and costs their own extractor calls. Method, caveats and the cells where we do not win.

The bottom row is the point. Turn our guard off and we score zero — so the number is the mechanism, not the benchmark being kind to us.

Keep the big tool result out of the context window

The context saver replaces an oversized tool result with a ranked digest and the path of a file holding the whole output. The agent reads the digest, and reads the file when it needs the rest. It ships two ways, and neither needs a code change in your agent. In Claude Code it is part of the PostToolUse hook that inspeximus install --all or inspeximus install --ide claude wires up. For Hermes, integrations/hermes-context-engine-inspeximus/ is a context engine that runs before every provider request. Measured on one Hermes session store, 3,233 messages across 11 sessions, where tool results are 84.4% of the message bytes, over the 264 results longer than 2,000 characters:

Scope: inspeximus 3.26.0, measured 2026-10-29, one operator's sessions on one machine, lexical ranking with no embedder, and a mid-output question term is a word of the tool call's own arguments present in the output but absent from its first and last 400 bytes. The probe behind the table runs against one operator's own session store and is not shipped here, so read the figures as reported rather than as reproducible from this package. Hermes replaces a tool result it has no summarizer for with a byte count, which carries no term from the output at any setting of that window, and the agent re-runs the tool to get the content back.

What we could not show. An earlier version of the engine's page compared the digest with head-and-tail truncation at the same byte budget. That row is withdrawn: the window size decides the direction, the digest's own Searchable terms: footer is worth several points to a substring scorer, and on the Hermes corpus an unranked evenly spaced sampler matches the footerless digest. The honest reason to use the saver is wha