Shared State and Conflict Resolution

Goal

Protect shared multi-agent state with ownership, version checks, idempotent updates, and explicit conflict resolution rather than last-writer guessing.

See the stale-write problem

Imagine you and a classmate open the same online score sheet. Both screens show version 7. Your classmate corrects a score and saves, creating version 8. Your screen still shows the old version 7. If you now save a different change without checking, your older copy could erase the newer correction.

That is the shared-state problem in small form. Several agents can each make a reasonable decision using the information they saw, yet their updates can collide because they did not see events in exactly the same order. In distributed systems, there is no guarantee that every worker has the newest view at the same instant.

Reject updates from an old version

A version precondition adds a simple safety check: "Save this update only if the record is still version 7." If somebody already changed it to version 8, the stale write is rejected. The agent must reload the newer state and decide what to do with the conflict instead of silently overwriting it.

Suppose Agent A and Agent B both read task version 7. A marks the task approved and writes version 8. B, still holding the old version 7, tries a different update. The version check rejects B's stale write.

Optimistic concurrency is one useful pattern: read a version, compute an update, then write only if the version has not changed. If it changed, reload and decide again. This works well when conflicts are uncommon and updates can be retried safely.

read version 7
write if version == 7 → success → version 8
later write if version == 7 → reject as stale

Use ownership and append-only evidence

Some state should have a single owner. A supervisor may own the final task status while child agents only append evidence. Ownership reduces the number of fields that require merge logic.

Append-only event logs are another useful tool. Rather than allowing agents to overwrite one shared summary, record claims or observations with source, timestamp, and task identity. A later reducer can build a current view while preserving disagreement.

Conflict resolution should use domain rules. Two agents disagreeing on a shipping status might be resolved by choosing the latest verified carrier observation, not by choosing the agent that wrote last. The state layer should preserve enough provenance to apply that rule.

Keep retries and remote state separate

Idempotency still matters. Retrying an update with the same operation identity should not create duplicate artifacts or events. Shared state does not replace the Level 12 recovery rules.

Remote task status also needs careful mapping. An A2A task state is protocol-visible remote state; your local task may have additional states such as waiting for review or quarantined result. Do not collapse local policy state into the remote task field.

Tracing conflicts is essential. Record expected version, observed version, operation identity, writer, and resolution outcome. A conflict that disappears into a generic retry is difficult to evaluate later.

Predict

Two agents both read version 7, but one has already written version 8. What should happen when the second tries to write using expected_version=7?

Reject the stale write and require a reload or explicit conflict pathOverwrite version 8 because both agents started from a valid stateMerge fields automatically without checking whether the updates conflict

Run the Docker-environment Lab preflight

This activity is registered for the Docker-oriented environment used by multi-agent operational work. Start with the deterministic Python preflight so protocol/controller failures remain distinguishable from container or network setup problems.

Run:

python3 labs/notebooks/level-13/l13-10-shared-state.py

The Lab simulates two writers using expected-version updates.

1. Run it unchanged with SECOND_WRITER_RELOADS = False. Writer A advances the store from version 7 to 8; writer B still expects version 7 and is rejected as stale.
2. Before editing, predict what the final version and writer-B result should be if B reloads the latest version before writing.
3. Change only SECOND_WRITER_RELOADS = False to SECOND_WRITER_RELOADS = True, then rerun.
4. Confirm B reloads version 8, its write succeeds, and the final version becomes 9. The conflict rule did not disappear; B supplied fresh evidence instead of a stale precondition.

Loading lab…

Write the core logic yourself

Open:

labs/notebooks/level-13/l13-10-shared-state-exercise.py

Implement optimistic concurrency: accept only the expected version, increment on success, and leave state unchanged on a stale write.

Run:

python3 labs/notebooks/level-13/l13-10-shared-state-exercise.py

The starter intentionally fails at its TODO boundary. A completed implementation ends with a PASS: marker. Compare with the solved deterministic Lab only after attempting the implementation yourself.

Quick Check

1. What does an expected-version check prevent?

All semantic disagreements between valid updatesIt prevents stale writes from overwriting newer stateIt prevents two agents from reading the same data

2. Why use append-only evidence for some shared data?

To make deletion impossible everywhereTo avoid assigning task identifiersTo preserve source and history

3. How should conflict resolution choose between two observations?

Accept whichever observation has the longer explanationAccept whichever agent wrote lastUse a domain rule based on provenance, freshness, or authority

0 of 3 questions answered.

Explain it back

Describe a shared task record with one supervisor-owned status field and append-only child evidence. Explain how a version conflict is detected and resolved.

Key Takeaways

• Shared state needs concurrency and ownership rules.
• Version preconditions catch stale writes.
• Append-only evidence preserves provenance and disagreement.
• Resolution should follow domain evidence, not last-writer timing.
• Idempotency and tracing still apply to shared updates.

Next Lesson

Next, L13.11 — Multi-Agent Evaluation measures the whole coordination system rather than only isolated agent outputs.

References

• Agent2Agent Protocol, v1.0.0 Specification.
• Temporal, Documentation.