Why do multi-agent systems need a single-writer rule for each shared artifact?

## The failure this rule prevents Give two isolated subagents overlapping write authority over the same target — a module, a document, a configuration, a plan — and you do not get double the throughput. You get two coherent, incompatible pieces of work. Each worker made dozens of small implicit decisions along the way: what to call things, which error style to use, which of two ambiguous requirements to honour, how far the scope extends. None of those decisions is stated in the brief, because they only arise once the work is underway. And none of them is visible to the other worker, because isolation is the whole point of the architecture. When the summaries come back, the orchestrator sees two confident reports of success. It cannot detect that worker A standardized on one shape and worker B on another, because that detail did not survive the summary — and even if it had, reconciling would require re-reading both full transcripts, which is precisely the context the split was designed to keep out. The system's own architecture blinds it to its own conflict. ## Why the usual concurrency answers do not suffice Engineers reach instinctively for locks, transactions or merges. They address the wrong layer. A lock serializes *access*. It guarantees that two writes do not interleave mid-edit. It says nothing about two agents having made contradictory *decisions*; the second writer simply overwrites or extends work built on assumptions it never saw, and the result is internally inconsistent while being perfectly serialized. A merge assumes the conflicting edits are textually adjacent. Model-driven conflicts usually are not: one worker renames a concept in one place, another writes new code assuming the old name three files away, and no merge tool flags anything. The build may even pass. Last-write-wins silently discards work you paid a full worker loop to produce, and the orchestrator will still report both subtasks as complete. The conflict is semantic, so the fix has to be structural. ## The discipline For every artifact that can be mutated, exactly one agent holds write authority for the duration of the task. Everyone else is a reader. Read-only workers are cheap, safely parallel and exactly what isolation is good at: they explore, analyse and return findings. When a worker believes a change is needed, it returns a *proposal* — the finding, the recommendation, the specific edit — and the designated writer decides and applies it, in one context, with all the proposals in view. The writer role can be an agent or plain code; it does not have to be a model. What matters is that the decisions land in one place where they can be made consistently. The partition can also be by artifact rather than by role: worker A owns the ingestion module and only that, worker B owns the reporting module and only that, with no overlap. This works when the boundary is genuinely clean and neither piece constrains the other's interface. The moment two workers must agree on a shared contract, that contract needs a single owner too. ## Using it as a go/no-go test The rule doubles as a decision procedure before you build anything. Try to partition the work so that every mutable artifact has exactly one owner. If you can, you have a viable multi-agent design and the partition is your delegation plan. If you cannot — if every plausible split leaves two workers needing to change the same thing — that is telling you the work is tightly coupled, and the honest response is to keep it in a single agent rather than to invent a reconciliation strategy that will fail quietly. This is the more useful reading of the rule. It is not primarily a runtime safeguard; it is a design filter that catches unsuitable work before you have paid the multi-agent premium for it. ## Read-mostly work is where the fit is best Notice the alignment with everything else that makes multi-agent pay. Research, review, search and analysis are naturally read-only and therefore naturally single-writer: the only writer is the orchestrator producing the final synthesis. That is not a coincidence — it is why the pattern's clearest successes are exploratory and read-heavy. Work that is fundamentally about *changing* one coherent thing has one writer by definition, and its parallelism is limited by that. ## Where it gets genuinely hard Long-running systems make this messier than a single task does. If subagents can write in earlier turns and a later run reads that state, you effectively have writers separated in time as well as in context, and you need provenance — who wrote this, when, on what basis — to make later decisions defensible. Human-in-the-loop approval on the writer is a common and reasonable escalation for anything irreversible: the writer proposes, a person confirms, and the audit trail records both. And when a proposal is rejected, the workers that produced it have already exited; you are re-running work, not resuming it.