How do you maintain consistency of shared state across multiple agents?

Shared-state consistency means multiple agents see and update a common workflow record without silently overwriting one another's work. Agents may execute in parallel, but updates to authoritative task status, accepted artifacts, and approvals must follow explicit concurrency rules.

Beginner-friendly example: API test generation

Two agents review the same payment endpoint:

• Agent A adds authorization test cases.
• Agent B adds invalid-input test cases.

Both read test-suite version 5. Agent A saves an update, producing version 6. If Agent B then writes its entire outdated version-5 copy, it may erase Agent A's changes. This is a lost update.

Read version → Prepare changes → Check expected version → Commit or resolve conflict → Publish new version

Step-by-step numerical example

The shared record initially contains 20 test cases, at version 5.

1. Agent A reads version 5 and proposes 3 new tests.
2. Agent B also reads version 5 and proposes 2 new tests.
3. Agent A commits, producing 23 tests at version 6.
4. Agent B's attempt to replace version 5 is rejected because the current version is 6.
5. Agent B reads version 6, checks that its two tests are distinct, then commits 25 tests at version 7.

Without the version check, Agent B could overwrite A's three tests and leave only 22. The numbers assume all additions are valid and unique.

Approaches to preserving consistency

1. Single authoritative store: Choose where the accepted workflow status and output version live; do not treat every agent's local memory as equally authoritative.
2. Optimistic concurrency: Require an expected version on updates, and re-read or merge when it changes.
3. Transactions: Make logically related changes atomic—for example, save an accepted result and mark its task complete together.
4. Scoped ownership: Give one agent responsibility for approving final shared state while specialists produce separate draft artifacts.
5. Append-only events or artifacts: Record independent contributions separately, then combine them through a validated aggregation step.
6. Conflict policies: Distinguish safely mergeable additions from conflicting approvals, replacements, or deletions.
7. Version-aware reads: Ensure downstream agents consume the correct accepted artifact version rather than a stale cache.

Simple PostgreSQL example

An optimistic update can check the version it read:

SQL
UPDATE test_suites
SET content = :new_content,
    version = version + 1
WHERE suite_id = :suite_id
  AND version = :expected_version
RETURNING version;

A returned row means the update succeeded. Zero rows means the record was not updated; determine whether the suite is missing or another writer changed its version. The agent must not assume success or repeatedly retry the same stale payload.

How should parallel agents share data?

Use immutable or versioned outputs for independent branches, then let a controlled aggregator assemble the final result. This often reduces contention compared with letting every agent edit one large JSON document.

For example, keep separate references for security tests and validation tests; when both complete, the aggregator checks source-specification versions, deduplicates cases, and records one approved suite.

Shared state is not the same as shared memory: memory can provide useful context, while authoritative workflow state needs clear ownership, durability, and concurrency controls.

LangGraph and Celery implementation

In LangGraph, define how state updates from parallel branches are combined and avoid assuming all concurrent writes automatically merge safely. Reducers can combine compatible updates, but reducers alone cannot prevent races on an external database or shared artifact store.

With Celery, several workers may run simultaneously or retry tasks. Use database transactions and version checks for shared records; Celery task execution order is not a reliable serialization mechanism.

In short

Maintain shared-state consistency with authoritative storage, version checks, atomic transactions, and explicit merge rules. Parallel agents can work independently, but committing accepted results must remain controlled and auditable.