What a million team decisions taught us about memory at scale
Every memory tool works in the demo. Fifty records, one writer, everything instant. The interesting question is what happens at a scale no demo reaches, so we built a store no real team has yet and measured where our own design holds and where it doesn't.
The setup
One million decisions in a single store, written across thirty writers' shards to mimic a whole team recording in parallel. We build kgai, so treat the numbers as a vendor's numbers. The method and the raw runs are in the repository, reproduce them if you're deciding anything on their basis.
What stays fast
A decision lookup answers in about 100 ms, and it stays flat as the store grows. Element history behaves the same way. This is the path that matters most in practice, because it's what runs when an agent checks an area before editing it. That check costing the same at a million decisions as at a thousand was the design goal, and it held.
One caveat, and it's not fine print. That figure is the decision lookup specifically. Recall and free-text search are slower, and anyone who quotes our 100 ms without saying which query is measuring the wrong thing.
What surprised us
Not the speed, the determinism. The store is an append-only, immutable log projected into a graph by replay, so independent machines pulling the same shards should converge on the identical graph. They do, verifiably. Canonical exports match digest for digest, regardless of the order the shards arrived in. We knew the design said so. Watching thirty writers' worth of parallel history replay byte-identical on a fresh clone, with not one textual conflict anywhere, because write-once shards make conflicts impossible to express, made the argument feel less theoretical.
What doesn't stay fast
Free-text search across the whole log is the honest weak spot. Lexical matching over a million decisions is doing real work, and it shows. That's why the roadmap carries a contextual-search index for stores beyond roughly 100k decisions, and why we keep repeating which query the headline number describes.
What it means for your team
You will not record a million decisions any time soon. A busy team is in the thousands after years. The takeaway isn't that you need this headroom, it's that the operation your agents run constantly is the one that doesn't degrade, on a store with no daemon, no server, and nothing to operate.
The method and the raw runs sit in the repo next to the code, all of it MIT licensed. Install it, record for a month, and check our numbers against a store that's actually yours.
Try it on your repo. Two commands, MIT, nothing leaves your machine until you configure a bucket.
See how kgai compares to other tools on the comparison page, or browse the other notes.