When Every Agent Writes at Once
Run enough agent sessions against one memory and the hard part stops being recall. It becomes making sure every save lands. Curator got a round of hardening for exactly that kind of load.
We run Curator the way we expect people to run it: several agent sessions open at once, across several projects, all writing into the same local memory and all leaning on one shared local model. That kind of load does not show up in a recall benchmark. What matters there is simpler: whether the thing a session asked Curator to keep actually gets kept when everything is busy at the same time.
A round of work went into exactly that.
A backlog never blocks a save
Captured turns wait in line until the local model can read them. Working through a long line now never holds the store closed while the model works, so another session’s save goes straight through instead of waiting behind it. If some future change ever left the store held open, Curator closes it before the next model call and names the problem in its health report, so a regression of this kind announces itself instead of passing for general slowness.
Each turn gets captured once
Each session remembers what it has already sent, and only new turns join the line. One long session cannot crowd the line with copies of work that was already captured, so the backlog drains instead of churning.
Health that tells the truth under load
When the shared model is reachable but not serving, for instance because it has been paused while the machine does something else, the health report says so plainly and confirms that capture keeps queuing until the model is back.
The health check also counts correctly while the line is shrinking underneath it. A turn handled mid-check is simply left out of the count, so the supervisor watching Curator never mistakes a busy moment for a stopped process.
Recall does not wait on someone else’s write
Recall keeps a little bookkeeping about what it returned. Under contention, that bookkeeping gives way quickly, so your answer never waits on somebody else’s write.
The unglamorous part that matters
A memory layer earns trust on the boring path. A wrong recall is visible: you see it and correct it. A save that does not land is invisible until weeks later, when the decision you made is simply not there. That is why this round was driven by running Curator under our own multi-session load, which is where a memory that agents share is actually going to live.
Where it stands
Curator is a working pre-release product that runs on your own machine and reaches your agents over MCP. The shared local model it leans on is the setup described in one GPU, every agent, served by Arbiter. Follow release preparation.
Was this useful?