Shared State Consistency Between Concurrently Running Agents

Shared state consistency between concurrently running agents is a coordination problem. Agent37's Cloud API sets up an isolated, persistent per-user AI agent sandbox with a single API call, keeping each customer's state separate without a complex infrastructure setup. That isolation keeps customers from interfering with each other's state, but agents that use shared resources still need to coordinate when their effects land.

Why concurrent agents fail even when every individual agent reasons correctly

CoAgent, from Shanghai Jiao Tong University, describes two agents working on a live Kubernetes cluster. Agent A repairs bad container images across deployments, while Agent B creates a canary release mirroring one service's current image. A scans before the canary exists, so its repair misses it. B reads the image before A repairs it, so the canary inherits the known-bad image. Both report success, yet the cluster has a bad-image canary ready to take live traffic.

Neither serial ordering would produce that result. If A finished first, B would copy the repaired image. If B finished first, A would find and repair the canary. The violated property is serializability, which requires a concurrent run to match some serial ordering, including what each agent sees when it reads.

CoAgent cites an audit of over 200 multi-agent traces that attributes more than a third of failures to inter-agent misalignment. Better reasoning alone cannot remove this structural risk. Hosting isolation, including Agent37's per-customer sandboxes, keeps each customer's state safe from other customers, though agents still need to coordinate access to external resources they share.

Why agent transactions cannot be treated like database transactions

An agent transaction differs from a database transaction in three important ways. It spans minutes of inference rather than milliseconds, its reads are broad and opaque, and its writes take effect immediately. A lock is costly to hold for so long because other agents must wait while generation runs. Opaque reads make it hard to establish in advance which state the operation will depend on.

Database isolation holds a transaction's reads under a lock or snapshot for its lifetime. An agent that reasons while the world changes cannot get that protection just by using a database connection. Its work can span files, Kubernetes configuration, and database rows across transaction boundaries. Agents therefore need explicit isolation, state checkpointing, or managed coordination in the system that hosts them.

Immediate writes are the sharpest break with the classical model. A database can hold effects until a commit decision, but an agent's tool call can change live state as soon as it executes. Without a defined coordination guarantee, those writes can interleave into a state no agent intended. By the time a conflict is discovered, there may already be an effect to undo.

The four anomalies that actually appear in production multi-agent runtimes

Khan (2026) exhibits tool-effect reordering in LangGraph's ToolNode on unmodified output. Two agents invoke tools, but the order in which their effects land produces a result neither intended. An L3 commit-order sequencer removes the anomaly in that example. The failure lies in the ordering of otherwise sound individual tool choices.

Stale-generation is a different failure. An agent reads a value, spends minutes generating a plan, and acts after that value changes. In the flight-booking scenario, the trip date changes during generation, but the agent books against the old date. The plan can be faithful to its input and still be wrong when applied.

Phantom-tool occurs when generation assumes a tool is available or has a particular signature, but another agent changes the tool registry before invocation. Causal-cascade concerns a dependency that has gone stale, where an action rests on a read another agent has since overwritten. Khan (2026) formalizes all four anomalies with model-checked counterexamples, giving designers distinct failure types.

Why the three approaches most teams reach for first — serialization, static partitioning, and fork-and-merge — each break under agent workloads

Serialization is correct and simple because only one agent acts at a time. Its price is the loss of concurrency itself. Static write-set partitioning preserves parallel work by assigning separate resources, but it needs the write set before execution starts. CoAgent attributes that approach to Anthropic (2024), while noting that dynamically emerging plans do not satisfy its premise.

Fork-and-merge gives each agent a separate workspace and reconciles changes afterward. CoAgent identifies this approach in Anysphere (2025), Cognition (2024), and Replit (2026), and characterizes its isolation as only equivalent to read-committed. Textual conflicts are visible, but semantic conflicts can survive a clean merge. STORM describes the problem through one agent writing a helper against a signature another agent changes in its branch.

Two-phase locking makes other agents wait through minutes of inference. Optimistic concurrency control discards that inference on a conflict and starts again. CoAgent reports that both surrender nearly all concurrency gains on ten contended workloads, while CoAgent stays within 5% of serial correctness at a 1.4× speedup.

How write-time conflict detection changes the trade-off — the STORM approach

STORM narrows the consistency requirement to the files behind the current edit. An agent needs the specific files it relied on to remain unchanged when it writes. STORM calls this local state consistency.

To enforce it, STORM mediates every file read and write. Before accepting a write, it checks whether another agent has changed the target file or its declared read dependencies since the writer last observed them. A conflict causes rejection, and the agent receives updated content for its retry. Recovery happens at the attempted write, rather than after separate branches have accumulated incompatible designs.

STORM reports gains of +18.7 on Commit0-Lite and +1.4 on PaperBench over the git-worktree-based multi-agent baseline, with comparable or better cost efficiency. Combined with single-agent runs, it reaches scores of 87.6 and 78.2 respectively. Those results support file-level checks for shared codebases but offer no guarantee that the checks will work for all live systems. In particular, local file consistency does not settle whether an external action remains authorized when it takes effect.

Advisory control and saga-style undo — how CoAgent's MTPO protocol handles the cases STORM cannot

CoAgent's Monotonic Trajectory Pre-Order, or MTPO, starts by deciding the serial order before execution. It then serves reads according to that order, so each agent receives the value appropriate to its assigned position. Writes still happen speculatively on live state. If an out-of-order write affects a reader, a one-way notification asks that reader to reconsider and patch its plan.

The LLM can judge whether the changed value actually invalidates its work and repair only the operations that depended on it. Unlike database OCC, the protocol need not discard the whole transaction, and unlike human review, repair is part of the agent's execution.

Mechanical recovery supports that judgment. Each tool registers a saga-style inverse in advance, allowing the framework to undo and reorder misplaced writes without restarting the agent. Once activity settles, the run is serializable in the pre-decided order. CoAgent implements this as toolcall middleware, with a privileged ToolSmith creating footprint-declared, undoable tools, and reports a task pass rate of 63/71 on a bash-only target at lower time and token cost than the baseline.

Stale authorization as a governance-layer anomaly that neither STORM nor CoAgent addresses

A consistent view of operational state does not guarantee valid permission to act. A refund, inventory reservation, cloud provisioning action, or financial transfer can be authorized before inference but lose that permission before its effect lands. Budgets, inventory counts, and approval status can change in that time. Neither STORM nor CoAgent handles this gap in permission checks.

Peng and Wu (2026) call the failure stale authorization. A request-local policy engine checks permission against the state when the request comes in, then lets the effect land later. Structurally, that is the same mistake as an optimistic system validating reads only at the start, leaving commit without read validation. The check was valid, but it no longer justifies the action.

Peng and Wu (2026) define policy-state serializability as the required condition. Each committed effect must be authorized by the policy state as it stands just before the effect occurs. Their MasuGate architecture keeps policy state and the effect it governs inside a shared trust boundary, so both land atomically against the same snapshot. In a scripted procurement workflow over shared budgets and inventory, MasuGate prevents stale authorizations that request-context baselines produce, while unrelated work remains parallel.

What a verified consistency hierarchy gives a system designer that heuristics do not

Khan (2026) builds a five-level consistency hierarchy, L0–L4, in which each level is defined by the anomalies it prevents. L0 is the base level verified against stale-generation, and L1 adds serializable snapshot isolation. Higher levels address causal-cascade and tool-effect reordering. A designer can match each precise guarantee to an access pattern.

For a workload exposed only to stale-generation, the base protection is the relevant minimum. When actions rely on facts that other agents can overwrite, they need causal protection. Where tool effects can land in a harmful order, commit ordering matters too. Stronger protection earns its cost when the workload can produce the anomaly it excludes.

Khan (2026) reports roughly 8% token overhead for snapshot isolation on one workload and a factor of 1.6–2.3× for pessimistic locking. These are measured costs for particular guarantees, with limited implications for throughput under stronger guarantees generally. The evidence goes only so far: three deployed Rust runtimes achieve L0–L1, L2 has been tested live across three model families, and L3 and L4 remain exec-verified.

How do per-user agent sandboxes fit the data layer, and why is the prompt the wrong place for shared state

Shared mutable state belongs in a layer that has defined isolation guarantees. A prompt, shared context window, or unstructured file does not supply those guarantees. Business records, including refund status, approval state, retry progress, and final tool results, belong in PostgreSQL with serializable isolation. Event flow belongs in Kafka or SQS, while multi-step progress belongs in a durable execution engine such as Temporal or Durable Functions. These choices protect individual parts of the system.

Messaging does not close the gap. A2A standardizes task and result exchange, but it does not reserve shared state. Two agents can both read that a task is unclaimed and then both claim it.

Customer isolation reduces how much state needs such coordination in the first place. Agent37 offers persistent per-user sandboxes through its Cloud API, and their storage is encrypted-in-transit and at-rest. Keeping each customer in a separate environment keeps sessions, histories, and tool credentials from being shared by default. The remaining coordination problem concerns resources that genuinely need sharing, so a sandbox complements the protocols above.

Choosing a coordination approach — matching the mechanism to the workload's actual conflict pattern

The decision starts with what agents can conflict over. When agents touch mostly disjoint files with occasional shared interfaces, STORM fits because it checks dependencies at write time without locking non-conflicting work. When agents build plans as they work on shared live external state, CoAgent fits because it keeps a fixed serial order and repairs or undoes only the work that needs it. When effects consume shared budgets, inventory, or approvals, policy-state serializability is the minimum requirement, regardless of how well the underlying data is coordinated.

These are different boundaries of correctness. Customer isolation limits who can share state, file checks protect edit dependencies, and runtime coordination governs live operations. Authorization control also checks whether those operations are allowed to happen at all. Across the three coordination approaches, the common principle is to detect and resolve conflicts close to the effect, rather than defer them to a final merge or wholesale retry.

The harder open problem lies after state has already been read and used. Ding et al. (2026) find that always-on agent research concentrates far more on accumulating and retrieving state than on governing, recovering, or relinquishing it. Audit, rollback, and update propagation across agents holding outdated facts remain the thinly developed return path. That is where the next class of concurrency failures will need to be found and controlled.