Chroma's Fission Protocol Stops AI Agent Swarms from Destroying Shared Memory

Chroma just published the engineering behind Fission, a concurrency control protocol built to solve an increasingly relevant problem: what happens when a swarm of LLM agents tries to edit the same shared document at the same time. It powers Foundation, Chroma's memory layer that turns coding agent traces and company data into a self-maintaining wiki.

Classical database transactions assume work is cheap to redo, so when two writers collide, one gets aborted and retried in milliseconds. Agent transactions invert that assumption. When an agent's transaction aborts, the read set was discovered by searching and reasoning, so retrying means paying for that discovery again, in minutes and tokens. Fission is Chroma's answer to that economics problem.

Why textbook transactions burn money here

Foundation runs an agent swarm that cooperatively edits a wiki. Each agent takes a batch of traces and does the following: searches for relevant pages, reads what seems promising, and updates any page that would benefit from information in the batch. Two properties make this hostile to normal concurrency control:

• A batch ingest can last several minutes.
• A batch's read set is discovered through searching and reasoning.

Optimistic concurrency control (OCC), where transactions run freely and only check for conflicts at commit time, becomes a retry storm when transactions last that long. Pessimistic locking hits a different wall: because the read set is discovered incrementally through search, locks get acquired in orders that can form deadlock cycles, and the usual fix is to abort somebody and throw away their reasoning.

The trick: aborts become early commits

Fission looks like textbook two-phase locking with wound-wait deadlock prevention, where older transactions forcibly preempt younger ones to break potential cycles. The twist is that transactions never roll back. When a transaction gets wounded, whatever it already wrote stays written. The abort is treated as an early commit.

This works because Chroma decided atomicity across the whole wiki is not a goal. Individual page writes stay atomic (backed by Chroma Cloud's OCC transactions), while the wiki as a whole is allowed to see partial progress from a killed worker. The full protocol, per the post:

• Lock pages using exclusive locks.
• Acquire locks at first page read, explicitly not over search results.
• Wound-wait over batch arrival timestamps.
• Wounded transactions release locks immediately and retry with the original timestamp.
• Durability comes from Chroma Cloud.

The guarantees Fission still gives you: isolation while a worker is reasoning about a page, per-page atomicity, and consistency delegated to the reasoning model, which is expected to make logically sound edits.

What the numbers say

Chroma reports empirical behavior from running this in production. In roughly 39.7% of wounded transactions, the model revisits (via read or write) the page that wounded its prior attempt. Of pages written during a wounded transaction's retry, 28.2% of modifications share a prefix or suffix with the page that caused the abort. Translation: the reasoning model is smart enough to look at the partial state a wounded predecessor left behind and continue from there instead of redoing everything.

This behavior requires a capable model. In practice, Haiku 4.5 with Context-1 as a search sub-agent was sufficient for wiki generation. An earlier prototype used reader-writer locks and saw higher wounding rates, so the team moved to pure exclusive locks.

Why not just use Git

The post spends a whole section on this because it's the obvious question. Chroma actually tried it. An early version of Foundation used Git for conflict resolution atop a file-system-like abstraction. 3/8 of the calls explicitly gave up after a repeated conflict. 4/8 gave up because their read was stale or required a re-read to write after someone else wrote out from under them. The agent traces read like a tired engineer at 2am, with the model repeatedly deciding to skip updates rather than fight merge conflicts.

Git merge can work well for code because code is written in lines: line-based diffs mostly coincide with syntactic units, edits are mostly local, and there's an intelligence standing by to escalate conflicts to. Prose written by agents violates all of those assumptions. It gets summarized, reorganized, and retracted, with no human sitting there to arbitrate.

Where this fits in the distributed systems zoo

Chroma is careful to distinguish Fission from adjacent ideas. It avoids CRDTs and lattices, because the model is allowed to overwrite and retract state. It avoids eventual consistency, because it sits on a linearizable history. It resembles sagas but has no compensating actions, since nothing is ever undone.

Why this matters

If you are building anything that looks like an agent swarm writing to shared memory, a knowledge base, or a codebase, the failure mode Chroma describes is what you will hit. The framing itself is the takeaway: goodput, meaning the share of paid reasoning that actually survives, becomes a first-class metric once tokens are the dominant cost. Whether or not you adopt Foundation, the design principle generalizes: when reasoning is expensive and code is cheap, trade atomicity for progress and let the model reconcile.