Agent concurrency needs an abort budget

Chroma's Foundation engineering account describes eight Git conflict retries: three abandoned repeated conflicts, four stopped after stale reads or a required reread, and one correctly decided no write was needed. Those are first-party observations from a knowledge-building workload, inspected on 16 October 2026, not a benchmark I reproduced.

The engineering question is bigger than which merge strategy wins. Agent concurrency needs an abort budget: how much paid reasoning can be discarded, which completed changes may survive and what human repair becomes necessary when work stops halfway through. Choose the transaction boundary from that budget and the harm of partial state.

Agent concurrency makes discarded work visible

Chroma's account describes workers that discover relevant wiki pages through search and reasoning. Its Fission approach retains completed page edits when a longer task is interrupted, while keeping individual page writes atomic. Whole-wiki atomicity is explicitly outside its goal.

That workload choice matters. Keeping a useful wiki edit can be reasonable even when the surrounding batch is unfinished. It is not a general argument for partially completing an operation whose meaning depends on every step succeeding together. The source does not establish that its protocol is suitable for money movement, permission changes or arbitrary enterprise workflows.

I would turn that distinction into a design review before turning it into an infrastructure purchase. The expensive thing is not merely the number of conflicts. It is the useful work each conflict destroys, plus the inconsistency the chosen recovery path leaves behind.

Define the smallest safe unit of progress

Start with an operation that a reader or another worker is allowed to observe. What must be true at that boundary? A page should not contain half a sentence. An entitlement change may need several records to agree. An external action may already be irreversible before the next internal write begins.

These are different units of progress. Giving them all the same transaction boundary hides the decisions that matter.

PostgreSQL's serialization-failure guidance requires retrying the complete transaction, including the logic that chose its statements and values. That protects the transaction's meaning. If expensive model work sits inside that retry unit, the retry cost belongs in the application design rather than being dismissed as a database detail.

The alternative is not automatically to retain every earlier change. Partial progress is useful only when the surviving prefix is acceptable. If the first step publishes an answer and the second adds its missing evidence, stopping after step one has preserved activity while damaging the result.

The diagram is my proposed decision process. It does not represent Chroma's implementation or claim that one branch is universally cheaper.

Keep a sourced paragraph together

Consider a hypothetical team of agents maintaining a product research workspace. One worker extracts evidence, another revises a comparison and a third checks citations. I would treat a sourced paragraph and its provenance as one publishable unit, even if storage makes it convenient to write them separately.

Next, I would decide whether the comparison may temporarily contain a mixture of old and new sections. If yes, each section needs enough version and source information to remain interpretable. If no, the comparison needs a stronger release boundary than the individual paragraph writes.

Then I would run deliberate interruptions at those boundaries. Stop after the evidence is staged. Stop after one section is accepted. Stop before the public comparison is updated. Inspect what another worker can read in each case. This is a proposed failure exercise, not a test of a deployed client system.

The key acceptance question is whether the retained work is independently valid. “The agent spent tokens on it” is not a sufficient reason to keep it. Useful work needs an observable predicate that a reviewer or another component can check.

Make the abort budget an operating record

I would record four things for each conflicted attempt: reasoning time attempted, reasoning cost discarded, accepted writes preserved and conflicts requiring human repair. Keep them separate rather than compressing them into a success percentage.

Reasoning time exposes latency that users feel. Discarded cost exposes repeated computation. Preserved writes show whether recovery retains useful progress. Human repair exposes the price of relaxing all-or-nothing completion. A protocol can improve one column while worsening another.

The record also needs context: task identity, source versions, conflict cause and the chosen recovery action. Without those fields, a reduction in retries may simply mean workers stopped attempting useful updates. A quiet system is not necessarily a productive one.

Compare recovery policies on the same bounded workload before generalising. Whole-task retries, smaller atomic units and compensating actions each make different promises. An external side effect that cannot be undone should not disappear from the analysis because the database transaction rolled back successfully.

My preferred default is the smallest boundary whose partial completion is demonstrably safe, with explicit escalation when that cannot be established. That is an engineering judgement, not a universal concurrency theorem. Chroma's reported outcome motivates the question; it does not answer it for another system.

What's in it for you

• Ask what survives an interrupted agent before asking how many agents can run together.
• Measure discarded reasoning and human repair alongside completed work.
• Test the acceptability of partial state at the actual boundary readers observe.

Concurrency is affordable only when you know what an abort destroys and what its surviving work still means.