Our AI agents share one memory. Here's what a week with Jev taught us.

Our AI agents do real work every day: they write code, review changes and run our operations. They share one memory, about 117,000 notes of facts, decisions and lessons they've saved along the way. When an agent starts a task, the notes that look most relevant are pulled from that memory and put in front of it.

We wanted to know two things. Is that memory actually helping? And can a low-cost AI keep it clean and relevant, without paying a large model to read every note?

For a week we tested Jev, a judge model from TypeSafe, on that job. Jev answers narrow questions, such as "do these two notes say the same thing?" or "is this note worth keeping?" Plain code decides what happens with each answer, so every change can be checked and undone.

In one pass, Jev retired 3,618 notes, 3.1% of the memory, for about $0.28 in model costs. Most were near-duplicates: the same fact saved twice in different words.

Nothing was deleted. A retired note is hidden from search and can be restored. We checked 300 retired notes afterwards. None came back in search, and the copy we kept was always still there.

What it means: a cheap judge can do housekeeping nobody has time for, as long as every change can be undone.

For three days, only 3% of memory lookups got Jev's ranking. The rest fell back to plain search. The cause was ours: our cost tracker counted timed-out calls as if they had been paid for, so a small daily budget looked used up. After the fix, 84% of lookups got Jev's ranking.

What it means: when the AI seems not to work, check the plumbing first.

We checked every note we put in front of an agent against what the agent wrote next. Of 6,568 notes, 48 were clearly used: about 7 in every 1,000. Our checker mostly matches words, so it misses some reworded use, but the picture is clear.

What it means: more memory in the prompt isn't better. Relevance is everything.

We asked an AI agent, Grok 4.7, questions about our own systems in four ways: with no memory, with notes handed in, with notes plus Jev's advice, and with a search tool it could use whenever it wanted. Each question ran twice.

With the search tool it got 3 of 12 wrong, against 9 of 12 when we handed it notes. It did that at about a third of the cost and a fifth of the time. It's a small test, so it points a direction rather than proving one.

What it means: memory should be something agents ask for, not something we push at them.

Each memory lookup checks its permission with a shared service our agents also use to coordinate. One evening that service got busy, and 23% of lookups ran out of time. We now reuse one permission check for up to a minute, which halved the calls. Lookups that run out of time are down to 5%.

What it means: as an agent fleet grows, the services it shares become the bottleneck.

• Whether Jev saves money or time overall. The costs above are estimates at the posted price.
• Whether it makes our agents' work more accurate.
• Which notes help which agent. We measure use across the whole fleet, not per agent.

• Pull, not push. Hand an agent a note only when Jev is confident it fits. Otherwise, tell the agent what memory holds and let it search.
• A memory for a hive. One store, many agents: a note that helps a coding agent is noise to a reviewer. We're studying how open-source projects handle this. Examples include shared memory blocks in Letta, scoped memory in CrewAI and time-aware knowledge graphs in Graphiti.
• A daily health check. It would track how many notes get used, how many are duplicates or out of date, and whether memory helps at all, compared with a small group of tasks that get none.
• Smaller models for routine calls. Jev has now made thousands of judgments. We want to teach a small local model the easy ones and send only the hard ones to Jev.

• The clean-up ran on 25 September 2026 over 117,506 live notes. Costs are Jev's estimated charges at TypeSafe's posted price, not an invoice.
• Of the 3,618 retired notes, 3,227 were near-duplicates, 371 were program output, 11 were exact duplicates and 9 were old snapshots of a machine's state.
• The bug figures compare the three days before the 24 September fix with the time from the fix to the evening of 25 September.
• Use was graded hourly across 1,961 agent turns on 24 and 25 September.
• The search test was 96 runs: 12 tasks, four setups, twice each. On six ordinary coding tasks, no setup made a mistake.
• On the 12 runs about our own systems, the wrong answers were 6 with no memory, 9 with notes handed in, 6 with notes plus Jev's advice and 3 with the search tool. The mean cost per run was $0.386, $0.373, $0.390 and $0.119, and the median time per run was 106 s, 113 s, 276 s and 24 s, in the same order.
• The traffic jam: 43 of 184 lookups ran out of time on the evening of 25 September. After the fix, 6 of 120 did in the next hour. The service was also less busy by then, so part of that drop is quieter traffic.