Identity
A YAML header: where the document came from, what it covers, the date range it spans. Enough to decide whether this file is relevant at all.
Your AI's memory,
as files you own.
Kerneta is a Sirotics spinout. It builds DaiDocs and the open .dai format, a way to store an AI assistant's long-term memory as plain text files on your own disk, readable by any model, owned by you. It ranks 2nd on LongMemEval-S, the standard AI memory benchmark, at a third of the tokens of the system above it.
2nd, AI memory benchmark
Siro Robotics Ltd, trading as Kerneta
Registered in England and Wales. The .dai specification and reference implementation are open source under Apache 2.0. The format is deliberately not ours to own.
Why it exists
Memory became the
bottleneck.
Every assistant now remembers something, and none of them let you take it with you. Your history sits inside one vendor's product, in a format you cannot read, growing until it no longer fits in a context window.
The usual alternative is a vector database, an embedding pipeline and a memory server: a lot of infrastructure to maintain, and a lot of ways to be subtly wrong about what gets retrieved.
Kerneta took the opposite position. Memory should be a folder of text files you can open, read, diff, back up and move between assistants. No vector database. No embedding pipeline. No server.
"A folder of text files. That's the whole trick."
The DaiDocs positioning, and an accurate description of the architecture.
The format
One file per
conversation.
A .dai file is plain text and human-readable. It has three zones, and each one exists so a model can stop reading as early as possible.
Understanding
A fenced JSON block holding the extracted summary, topics, entities, tags, dated facts and events. This is what retrieval ranks on, and it answers most questions on its own.
Content
The original conversation, preserved in full and split into numbered segments. Nothing is summarised away, exact wording is always recoverable when it matters.
The shared index
Alongside the documents, an _index/ directory holds four JSONL files
that make the whole store searchable without embeddings, and a _raw/
directory keeps byte-exact originals, so nothing is ever lost to a bad extraction.
- manifest.jsonl
- One line per file: id, path, title, date, summary, topics, entities, tags. The first thing any query touches.
- facts.jsonl
- Every dated fact, typed as event, attribute, preference or plan. What makes "when did X happen" answerable.
- events.jsonl
- One row per countable real-world occurrence, deduplicated, so "how many times did I…" returns a number rather than a guess.
- profile.jsonl
- Stated and implied preferences, which is what turns recall into useful recommendations.
Vendor-agnostic on purpose
The same store is readable by Claude, GPT, Gemini, Cursor, Windsurf and local models, at the same time. Switching assistant does not mean losing history, because the history was never inside the assistant.
Open source
Apache 2.0Open specification
Reference implementationLocal-first
Retrieval
Read the least
you can get away with.
The efficiency does not come from compression. It comes from a discipline: stop at the shallowest zoom that answers the question. Reading whole files is the default failure mode, and it costs roughly 15× the tokens for no gain in accuracy.
Zoom 01
The manifest
One JSON line per file. Scan it, pick the one to three documents that actually match, ignore everything else in the store.
- Which files are relevant
Zoom 02
Frontmatter + Understanding
The extracted layer of the chosen files. Most questions are fully answered here, without ever opening the conversation itself.
- Facts, entities, dates, summary
Zoom 03
Specific segments
Named segments from the content zone, requested by number, only when exact wording is required, never the whole content zone.
- Verbatim quotes and fine detail
Prompt caching multiplies it.
Measured on one real session, caching alone was worth 7.8×, the three zooms alone 2.9×, and both together 16.7×. The two savings are independent, so they compound.
Benchmark
Second on the AI memory
benchmark. A third of the tokens.
.dai places 2nd on LongMemEval-S, the standard AI memory benchmark, ahead of Supermemory, TiMem, Zep, Feather and every baseline, and 1.8 points behind first.
That gap is nine questions out of five hundred. The system ahead of it spends roughly three times the context to get there, which is the part worth paying attention to.
| Rank | AI memory system | Accuracy | Tokens per question |
|---|---|---|---|
| 1st | Mastra OM | 84.80% | ~30,000 |
| 2nd | .dai v4.4n Kerneta | 83.00% | 10,065 |
| n/a | Supermemory, TiMem, Zep, Feather | Below .dai | n/a |
| n/a | Full history pasted into context (baseline) | 60.60% | Full transcript |
LongMemEval-S, 500 questions, GPT-4o answering in every row, so the memory layer is the only variable. .dai figures use a GPT-4.1-mini observer at temperature 0. Published by Kerneta; see daidocs.com for the current standings.
2nd
On LongMemEval-S, the AI memory benchmark, 1.8 points off first place
3×
Fewer tokens per question than the system ranked above it
+22.4 pts
Over the same history pasted into the context window
16.7×
Combined saving from prompt caching plus the three-zoom method
The efficiency is the point
Near-parity accuracy at a third of the context means a question costs roughly a third as much, and that ratio is what decides whether a memory layer survives its first budget review.
The actor is swappable
Across answering models the same store scores from 78.00% on Claude Haiku to 92.00% on Claude Fable 5. Nothing needs re-indexing to switch.
Past the context window
History lives in files, so a project can exceed a model's context limit entirely. Retrieval reads only the portion a question actually needs.
In practice
It plugs into what
you already use.
DaiDocs exposes the store over the Model Context Protocol, so assistants can save and recall memory as ordinary tool calls. A session hook archives finished conversations automatically.
MCP tools
- save_memory
- Archive a conversation into the store as a .dai document.
- recall_memory
- Query across the store using the three-zoom strategy.
- list_memories
- Enumerate what the store contains.
- read_memory
- Open a specific document, or specific segments of one.
Clients
Claude DesktopClaude Code
CursorWindsurf
OpenAI Agents SDKAnthropic API
Ollama / local
Keys stay in the OS
Read the documentation
API keys live in the user environment, never in files in the store. Existing configuration is backed up before any change is written.
The spinout
Why this came
out of Sirotics.
Kerneta started as an internal answer to a problem we kept hitting on client programmes: long-running AI work loses its own history, and every team was rebuilding the same fragile memory layer from scratch.
It connects directly to the memory and long-context thread in our AI research practice. Deciding what an assistant should keep, compress, or fetch on demand is the same question whether you are building a personal assistant or a clinical decision-support system that has to explain where an answer came from.
We spun it out because a format only becomes a standard if it is not owned by one consultancy's client list. It is open, separately held, and free to adopt without any relationship with us.
What it tells you about how we work
- We build the boring infrastructure layer when it is the real blocker
- We measure: the benchmark numbers came before the marketing page
- We prefer open formats to lock-in, including our own
- Research that does not reach production does not count
Kerneta is operated by Siro Robotics Ltd, registered in England and Wales, and is independent of Sirotics client engagements.
Next step
Building something that
needs to remember?
Memory architecture is one of the threads we research hardest, and one of the most common reasons an AI product cannot go to production. Bring us the version of it you are stuck on.