What 15,865 agent memories taught us

We make a memory engine for AI agents. So a few weeks ago we asked ourselves an uncomfortable question: what do our own agents put in theirs?

We run a fleet of agents on our own infrastructure. Around sixty of them run on Hermes alone, handling research, content, code review, and operations. Every one of them shares one Uteke instance with scoped rooms. When we pulled the production snapshot and counted, the store held 15,865 memories across 180 rooms. This post is what the data taught us, including the parts we did not expect.

If you followed our piece on why a local model without memory feels amnesic, this is the sequel. That post named the problem. This one shows what a real solution looks like after months of daily use, and how the numbers reshaped the product we are building.

Most memories are boring, and that is the point

Our marketing story says decisions. The data says facts. 84 percent of everything our fleet stores is plain factual memory: a deployment time, a file path, a naming convention, a preference stated once by a human and never repeated again.

The average memory is 449 characters. The largest single one is 83,583. Almost everything lives near the small end. It turns out the highest traffic in an agent memory store is not the grand architectural rationale. It is the small stuff that would cost a whole conversation to re-explain.

That finding changed how we think about pricing the managed version. When your quota counts memories, you had better count the ones in daily use. More on that below.

Rooms turned out to be the real feature

We expected shared memory to be a nice-to-have. Instead, rooms are where the fleet lives: 180 of them, with the busiest single room holding 60 Hermes agents that work daily. Agents inherit project context from each other through the room, so a research agent's findings are recallable by the writing agent without anyone copy-pasting anything.

Cross-agent recall with author attribution became the workload we optimize for first, because it is the workload we run ourselves every day.

A third of our memories are dead, on purpose

5,190 of the 15,865 memories, about 33 percent, are deprecated. Superseded by newer versions, kept for history.

Our first reaction was mild embarrassment. Then we looked closer. A third of a memory store rotting is not a bug when your agents operate a real company. Decisions change, facts get corrected, plans move. A memory layer that cannot retire an old fact quietly becomes a liability that serves stale answers with total confidence. The supersede flow, where recall flags a stale result instead of serving it, is one of the features we are proudest of, precisely because the data proved it earns its keep.

The uncomfortable finding: salience can lie

The finding we did not enjoy: 4,458 memories had an access count above 500. Dug in, at least 1,273 of them were catalog entries that get embedded on every recall loop. Mechanical popularity, not relevance. If we billed per recall, that quirk would silently burn user money on repeated identical entries.

We caught it because we audit our own usage. The managed service now needs dedup and throttling around access counting before beta, and that requirement exists because of this one number in our own data.

What the audit changed in the product

The usage data directly shaped the cloud version we are building:

• Count caps now count live memories only. With a 33 percent deprecated ratio, counting totals would punish active users for their own housekeeping.
• Consolidation that needs an LLM is a paid operation. The free tier gets the deterministic dry run, which needs no model call at all.
• Bulk import became a first-class endpoint, tested to 64 MB and 50,000 entries, because moving your history in should not be a hack.

None of this came from a whiteboard. It came from watching 15,865 memories behave.

Try it on your own fleet

Uteke is Apache-2.0, at version 0.18.1, one Rust binary, zero API keys, fully offline. Recall runs in around 45 milliseconds on a CPU with fusion search scoring 0.98 recall at 5 on our public benchmark suite, and the reproduction scripts ship with the repo so you can check that number yourself.

Connect it to your agent over MCP, or use the auto-recall hook if you want context injected on every call. Rooms work the same way ours do.

For the managed version, we just put the landing live at cloud.uteke.app. It ships the same core contract as the open source engine, operated for you, and the waitlist is open now.

Start local: curl -sSL codecora.dev/uteke/install | sh. In a month, audit your own store. Whatever you find in there, it will probably not match your assumptions either.