Engineering · memory at scale
What agent memory has to guarantee at 850 agents and 4.5M conversations a month
By Rajamohan Jabbala · August 8, 2026
Take a concrete enterprise workload: a fleet running about 850 agents at its median hour, handling 4.5 million conversations a month. When people hear those numbers they reach for words like "high throughput." It isn't. Do the arithmetic and the surprise is how small the request rate is — and how large the thing that actually gets hard.
The arithmetic
4.5M conversations a month is 150,000 a day, which is ~1.7 conversations per second averaged over the clock. Concentrate that into business hours and add bursts and you land in the low tens per second at peak. At roughly eight turns a conversation, that is on the order of ~14 captured turns per second on average — a few hundred at peak. Any competent service handles that request rate on a laptop.
~1.7/s
avg write rate
conversations, over 24h
~36M
turns / month
~8 turns per conversation
850
tenants
isolation boundaries, not load
10⁸+
new facts / yr
distilled, then billions over years
So the request rate is a rounding error. The two numbers that decide whether a memory layer is enterprise-ready are the last two: 850 isolation boundaries and tens of millions of turns a month compounding into hundreds of millions of facts. The question is not "can you serve the traffic" — it is "across all of that, will you ever silently lose or overwrite one fact, for onetenant, and can you prove you didn't."
Here are the five properties that get hard at that volume, what fails, and how CLS++ is architected against each. Where a property is measured today I say so; where it is a design guarantee still being hardened I say that too. We keep the gap on the wall rather than in the footnotes.
1. Durability that survives a deploy, not just a 200
What breaks at scale: At 36M turns a month you redeploy, autoscale, and rotate instances constantly. Any memory that lives only in an in-process cache — or in a write-ahead log on an ephemeral disk — is acked to the caller as stored and then vanishes on the next restart. The failure is invisible: the API returned success, the fact is simply gone.
How CLS++ is built for it
A write is acknowledged only after it is durable in Postgres (L1), and the durable path is independent of the embedder — a fact persists even when the vector step fails, flagged degraded so the loss shows up in metrics instead of in a user complaint. The write-ahead log refuses to run on a non-persistent mount rather than pretend an ephemeral disk is durable. Restart the process with a cold cache and the fact is still recalled.
2. Hard tenant isolation across 850 agents
What breaks at scale: 850 agents means 850 memory boundaries. Cross-tenant leakage is not a performance bug, it is a security incident — one agent recalling another's facts. Naive shared-index designs make isolation a WHERE clause you have to get right on every read path, forever.
How CLS++ is built for it
Namespace is the shard key through every layer — the hot working set, the durable store, the semantic graph, the audit ledger. A query only ever touches one tenant's partition, so isolation is structural rather than a filter you can forget, and it doubles as the scaling axis: adding tenants adds partitions, not contention.
3. Recall latency bounded by the tenant, not the corpus
What breaks at scale: 4.5M conversations a month compounds. A year in, the store holds hundreds of millions of facts. A design where recall scans or ranks across the whole corpus gets slower every month it succeeds — the reward for adoption is degradation.
How CLS++ is built for it
Memory is tiered: a hot in-process working set, a warm indexed episodic store, and a crystallized semantic layer, all per namespace. Reads are scoped to one tenant's partition and served from indexes — vector ANN plus a lexical arm fused by rank — so recall cost tracks the tenant's own footprint, not the global corpus. The resident working set is bounded and evicts cold tenants losslessly back to durable storage, so a thousand active agents don't have to fit in RAM at once.
4. Provable correctness, not hoped-for correctness
What breaks at scale: "It seems to remember" is not an answer a buyer at this scale accepts. Silent loss, stale answers after an update, a contradiction quietly overwritten — none of these throw. Without continuous measurement they surface as an eroding trust you can't attribute.
How CLS++ is built for it
Correctness is decomposed into a catalog of metrics — retention, contradiction handling, latest-wins after an update, cross-session recall, freshness — each with an SLA and a nightly drift check against a frozen golden set. Every number is earned by measurement, and the ones that aren't green yet are shown, not hidden. The point of an enterprise memory layer is that you can audit its correctness the same way you audit a database's, rather than trust a demo.
5. Every change leaves a receipt
What breaks at scale: When an agent's belief changes across millions of conversations, an enterprise has to be able to answer: what did it believe, when did it change, and why. A memory that overwrites in place cannot answer any of those — and under DPDP, GDPR, or SOC 2, "we can't reconstruct it" is a finding.
How CLS++ is built for it
A contradicted fact is never blindly overwritten: the prior value is archived with lineage, superseded and timestamped, and the write itself names the fact it collided with. On top of that sits an append-only, hash-chained audit ledger, per-namespace — so belief history, supersessions, and access are reconstructable and tamper-evident. We publish our own clause-by-clause compliance matrix against that catalog, gaps in amber.
Proven today vs still hardening
Honesty is the whole product, so here is the line. What is measured and holding: durability across a cold restart, per-namespace isolation, contradiction-with-lineage, the tiered indexed read path, and a growing set of correctness metrics under nightly drift. What we are still hardening toward the full reference workload: sustained multi-tenant load at the top of the burst envelope, cross-layer propagation guarantees under churn, and disaster-recovery cold-read latency. Those are named rows on our own board, not vibes — and they are red or amber there until a measurement turns them green.
That is the difference we are selling. Plenty of memory layers will demo beautifully at ten facts. The enterprise question is what happens at the ten-millionth, on the day you redeploy, for tenant 850 — and whether you can prove the answer. We build for that number, we measure against it, and we show our working.
See the working
The measured numbers behind these claims — including the ones that aren't green yet — are in CLS++ by the Numbers, and the reliability failure modes this architecture is built against are reproduced in Four reliability failure modes in agent memory. For the compliance view, see the self-scored compliance matrix.