You have three parallel agents working on different modules of the same codebase. Each agent reads a shared state store at startup and writes its decisions back as it works. A developer reports that Agent B is making decisions that contradict Agent A's committed decisions from 10 minutes earlier. Which design pattern most directly resolves this conflict?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Three people editing the same document without tracking changes is a recipe for overwritten work — version control exists for exactly this reason. Agents sharing state need the same discipline: versioned reads and conflict-rejected writes so no agent can silently overwrite another's committed decisions. Optimistic locking gives you parallelism without chaos.
Full explanation below image
Full Explanation
When multiple agents share a mutable state store, two concurrency hazards appear: stale reads (an agent reads state that is already outdated by a peer's writes) and conflicting writes (an agent writes a decision that contradicts a peer's already-committed decision). Agent B's contradictory decisions are a direct result of reading a stale snapshot at startup and proceeding without re-checking.
Why B is correct: Optimistic locking (or versioned state) addresses this precisely: 1. Each write to the shared state store increments a version number. 2. When an agent reads state, it records the version it read. 3. When it attempts to write a decision, it includes the version it read as a precondition. If the current version no longer matches (because another agent has written in the interim), the write is rejected. 4. The agent then reloads the updated state, reconciles its pending decisions against the new reality, and retries. This pattern is well-established in distributed systems (compare-and-swap, ETags, Postgres advisory locks) and directly prevents the stale-read/conflicting-write problem.
Why A is wrong: Sequential execution eliminates parallelism, negating the performance benefit of running three agents concurrently. It's a valid correctness guarantee but an unacceptable trade-off for most production systems. The question asks for a design pattern that resolves the conflict — not one that avoids parallelism entirely.
Why C is wrong: Polling more frequently reduces the stale window but does not eliminate it. Between any two polls, another agent can commit a decision that the polling agent hasn't seen yet. Higher polling frequency also increases load on the state store. This is a mitigation, not a solution — the conflict can still occur.
Why D is wrong: Isolated memory stores allow each agent to proceed without conflict during the run, but they defer the conflict problem to the merge step at the end. If Agent A and Agent B made contradictory decisions during the run (which is precisely what the question describes), merging their stores at the end produces the same conflict — now possibly harder to resolve because both decision trees are fully built out.