Parallelization: the race that corrupted the state

A reporting agent builds the quarterly summary. To make it fast, the orchestrator fans out two workers: one updates the revenue section, one updates the costs section. Both run at once. Each worker reads the whole document, edits its section, and writes the whole document back. On the last day of the quarter worker A read version 7, worker B read version 7, A saved version 8 with the new revenue, and B saved version 9 with the new costs, built from version 7. Version 9 has the new costs and the old revenue. The orchestrator reported both sections updated. The run ended with status success.

The finance lead found the stale revenue number in the board deck. Nobody could tell when it had reverted, because the log said both updates succeeded. They had. One of them was then overwritten.

Line 6 is the write that erased the other write. B's document was built from a snapshot that was already stale, and the write tool accepted it. This is a lost update, the oldest race there is, and it has nothing to do with language models. Two writers, one shared value, no coordination.

It happened because parallel work was added to a design made for one worker. Anthropic's "Building effective agents" (December 2024) describes parallelization in two forms: sectioning, where a task is split into independent subtasks that run at the same time, and voting, where the same task runs several times. The word that matters is independent. Two workers that write the same document are not independent, however different their sections are.

Frameworks know this. LangGraph refuses the ambiguous case: if two parallel nodes write the same state key in one step and the key has no reducer, it raises InvalidUpdateError rather than guess which write wins. That is the good default. Silent last write wins is the bad one, and a plain write_doc tool gives you exactly that.

Three fixes, in order of preference. First, change what the workers write. Each worker returns only its section as a structured result: the section name and the new body. The orchestrator merges the two sections into the document with one write, in code. The workers never touch the shared document. This is sectioning done properly, and it is how a reducer works: the parallel branches produce values, one function combines them.

Second, if workers must write to a shared store, make the write conditional. The read returns a version. The write carries the version it was based on, and the store rejects it if the current version has moved. HTTP has done this for years with ETags and If-Match; RFC 9110 section 13.1.1 defines the header. The rejected worker re-reads and retries, or gives up and reports. A lost update becomes a visible conflict.

Third, if neither is possible, do not parallelize that step. Run revenue, then costs. The time saved by running two model calls at once is seconds. The time lost finding a reverted number in a board deck is a day.

Whatever you pick, tag every write with the worker and the run, so when the trace shows two saves you can see which one came from which snapshot.

"Line 6. Worker B saved a whole document built from version 7 after A had already saved version 8, and the write tool took it. It is a lost update. I would have workers return their section as data and let the orchestrator do the one merge, or make the write conditional on the version read." Then say when you would not parallelize at all: when the steps share state and the gain is seconds.