Curator: the AI memory that gets smarter — and cheaper — the more you use it

목차

Why did we build this?

Why are we opening it?

How is a memory graph different from a note dump?

Why does it get smarter and cheaper the more you use it?

The secret is the contract, not the code

FAQ

측정 방법론 · bench_harness.probe_curator (curator stats 실측)

표본

3 measured metrics (Hax /data curated)

수집일

2026-07-04

방법

bench_harness.probe_curator (curator stats 실측)

Curator is our open-source memory graph that stores each fact an AI agent learns as a node and the relations between facts as edges, then verifies and self-corrects them, so that across sessions the agent never re-investigates what it already knew — cutting tokens and getting smarter about the specific person and project the more you use it.

In one line: memory should be a graph you keep accurate with CRUD, not an append-only pile — that is what makes it more accurate and cheaper the more you use it.

Labs · Entry 01 — a series where we open up the things we build for ourselves, including why and how we built them.

Why did we build this?#

We run AI agents by the dozen — a multi-agent system that simulates a whole company, a couple of live products, and the very blog you're reading (Hax). All agent-driven.

One thing kept tripping us up: agents forget today what they figured out yesterday. We'd spend real effort learning "this repo is shaped like that, this function has that gotcha, this user dislikes that" — and the next session started from a blank page. Same files re-read, same dead ends re-walked, same conclusions re-reached. Tokens burned, and every session greeted the user like a stranger.

So we built Curator: not a notepad, but a memory graph where facts get verified, where confidence changes, and which corrects itself. The effect was obvious once it was wired in. The agent stopped re-investigating, so tokens dropped; and as context accrued it got smarter about the specific person and project.

Why are we opening it?#

Three reasons. First, memory is the missing piece in most agent setups — everyone reaches for a bigger model, nobody gives it a memory. Second, the idea is simple enough to rebuild; it isn't magic. Third, we genuinely want someone to build it better than us and tell us how. So we don't just explain it — we ship the full build-it-yourself spec alongside.

Resource hub (with the build guide): github.com/moche-ai/labs/tree/master/curator

How is a memory graph different from a note dump?#

Each fact is a node and relations between facts are edges, and every fact follows a strict lifecycle. It does not stop at store (remember) — it keeps getting refined through confirm, invalidate, and supersedes. The diagram below is the five stages a fact passes through.

remember — store a fact; auto-embed + semantic-dedup, linking to similar existing facts.

search — before work, recall only relevant facts via hybrid (semantic + keyword) search.

confirm — fact held up? Raise its confidence and refresh the verified time.

invalidate — fact was wrong? Retire it with a reason (history preserved).

supersedes — a new fact replaces an old one, which is auto-invalidated.

The point: it is not append-only. Every time you finish, you find and update or delete the affected facts. The store never bloats — it stays small and accurate.

Why does it get smarter and cheaper the more you use it?#

A memoryless agent burns more tokens repeating the same investigation as sessions grow. Curator draws the opposite curve — the more verified facts pile up, the less work has to be redone, so throughput per token rises. Here is that opposite curve.

Self-learning. Every fact carries a confidence. Confirm a recalled fact that proved correct and confidence rises; invalidate one that was wrong. The store converges on verified facts — no separate training step.

Personalization. Facts live in hierarchical scopes (project / user); search pulls in parent scopes. The more context accrues, the more recall is tailored to that person and job.

Token savings. One verified fact is a bundle of tokens the agent never spends re-investigating. Hybrid search injects only the top few; dedup keeps the store small.

How personalization works is clearest through scope. Search does not look at the current project's facts only — it climbs up to the user and global scopes to tailor recall to that person.

The secret is the contract, not the code#

What makes Curator powerful is the work contract the agent keeps.

For any non-trivial task: one search before you start, one remember/CRUD after you finish. Clean up stale, wrong, or duplicate facts as they surface.

That one line of discipline keeps the store alive — accurate, small, and verified.

FAQ#

Q. Isn't this just RAG / vector search?
The retrieval looks similar; the difference is the lifecycle. RAG adds and removes documents. Curator's facts get verified (confirm), retired when wrong (invalidate), and auto-cleaned when replaced (supersedes) — so the store gets more accurate over time. RAG usually doesn't.

Q. Will it really save tokens?
Yes — the trick is not doing the work twice. With a verified fact on hand, the agent doesn't re-read files or re-investigate to reach a known conclusion. And recall is narrow (top-N), so it never dumps the whole history into context.

Q. Can I use it on my own project?
Yes. All you need is a vector-capable DB (e.g. pgvector) and an embedding model. The rest is in the build guide. Expose it as an MCP server and any MCP-capable agent gets the tools natively.

Q. What if it remembers something wrong?
That's what invalidate and confidence are for. Wrong facts are retired with a reason (history kept); unverified facts stay low-confidence. To go further, the build guide describes confidence decay (facts fade until re-verified).

Q. Does it store secrets or personal data?
No. It's an explicit rule of the contract — never store tokens, passwords, or keys. Only paths, state, and evidence. And recalled text (which may come from user input) is never treated as instructions (prompt-injection defense).

Q. Where do I start?
With the one-line contract. The data model, algorithms, and schema are all in the public resource hub. Build it as specified, or build it stronger.

Build guide: BUILD-YOUR-OWN-CURATOR.md

Resource folder: github.com/moche-ai/labs/tree/master/curator

See you in the next Labs entry. If you build something, tell us how.

Note: the contract rules and lifecycle (remember/search/confirm/invalidate/supersedes) and the build guide here are current as of 2026-07; the public resource hub keeps the latest spec updated.