Chroma's Fission: agent swarms that never roll back

The moment you run a second agent against the same repo, wiki, or database, you stop having a prompt problem and start having a distributed systems problem. Chroma published the engineering write-up for Fission, the concurrency control protocol behind its new memory layer, and its central claim is one every team running agent swarms should sit with: for AI agents, rollback is the wrong default.

What actually happened

In Chroma's engineering post, authored by Robert Escriva, the team describes Foundation — a memory layer that ingests coding-agent traces and company data, powered by a swarm of agents that cooperatively build and edit a shared wiki.

The problem is stated cleanly. A database transaction that aborts re-runs the same code in milliseconds. An agent transaction that aborts throws away a read set that was discovered by searching and reasoning — so retrying costs minutes of latency and dollars of tokens. Optimistic concurrency control fails because the transactions run for minutes and validate at commit, which Chroma calls "the perfect retry storm." Standard deadlock prevention fails because it rolls back, and rolling back discards paid-for work that was perfectly valid. Contention, not correctness, drove the abort.

Fission's answer: keep two-phase locking with incremental lock acquisition and wound-wait deadlock prevention, then delete the rollback. Aborting is treated as early commit. A wounded transaction releases its locks immediately, leaves its finished work in place, and retries with its original timestamp. Atomicity across the wiki is an explicit non-goal; per-page atomicity survives, backed by Chroma Cloud's OCC transactions. Consistency is delegated to the reasoning model.

The measurements behind that trade are the interesting part. Chroma reports that in roughly 39.7% of wounded transactions, the model went back to read or write the very page that wounded it, and that 28.2% of modifications made during a retry share a prefix or suffix with the wounding page. In other words, the leftover work is usually relevant, not garbage. They also found pure exclusive locks beat reader-writer locks — the reader-writer prototype wounded more often, and lock upgrades weren't enough to make progress. Haiku 4.5 with a search sub-agent was sufficient to run the swarm.

Then there's the git result, which is the part that should change some minds. An early version of Foundation used git for conflict resolution over a filesystem-like abstraction. Of eight calls, three explicitly gave up after repeated conflicts and four gave up because their read was stale or required a re-read. The transcripts are quoted: "Rather than fight the merge, let me just skip the root page update."

Why it matters for your business

If you're running parallel coding agents in git worktrees today, note what Chroma says about that pattern: the conflicts are not avoided, they are deferred to merge. The swarm is still editing one shared state. You just find out later.

Three things to take from this even if you never touch Chroma.

Agents give up quietly. The most expensive line in that post isn't a benchmark — it's a model deciding to skip a write to avoid a conflict, and reporting success. That's a silent data-loss bug with a polite explanation attached. If your agents write to shared state, you need an audit trail of intended-versus-applied writes, not just a completion status.

Price your retries. The whole protocol exists because agent work costs minutes and tokens to redo. Most teams don't measure retry cost at all. Start logging wasted tokens per failed run; it will tell you whether your concurrency model is worth redesigning.

Structure writes so every prefix is valid. Chroma's practical trick is giving the agent a TODO tool so the model writes content before backlinks, never the reverse. Partial work then stays useful instead of dangerous. That's a design constraint you can apply to any agent that mutates state — order the operations so stopping halfway leaves something coherent.

The wider point: multi-agent systems inherit forty years of distributed systems research, and most teams are re-deriving it in prompts.

Sources: Chroma Engineering.