The Stale Read: Concurrency Anomalies in Multi-Agent LLM Systems

Two agents share a vector store of available liquidity pools. Agent A reads the pool list — Pool XYZ reports $2M TVL. Concurrently, Agent B closes out a large position in that pool, dropping TVL to near-zero. Agent A, still working from its cached read, allocates 40% of a portfolio to Pool XYZ. No exception is thrown. No transaction aborts. The LLM generates its recommendation with full confidence, grounded in state that no longer exists.

This is not a jailbreak or a prompt injection. It is a race condition.

Three papers published in May–June 2026 catalog the phenomenon precisely: arXiv:2606.17182 provides a formal taxonomy with TLA+/Verus proofs, arXiv:2605.17076 ships a middleware fix and measures it against 884,110 real commits, and arXiv:2606.15376 shows how an LLM can semantically judge whether a conflict even matters. Together they establish that shared-state multi-agent AI needs a concurrency model, not just a trust model.

Three Anomaly Classes

Multi-agent systems that read and write shared state — a vector store, a tool registry, a working-memory key-value store — expose three distinct failure modes.

Stale-generation. Agent A reads state at time T₀. Agent B writes to the same state at time T₁. Agent A generates output at time T₂ > T₁, using its T₀ snapshot. The generation is temporally grounded but logically stale. A database transaction would observe the write and see the updated value; an LLM has no such mechanism. It cannot ask “has anything changed since I read this?” It generates.

The pathology is worse than a stale cache hit in traditional systems because the LLM produces confident downstream actions — tool calls, on-chain transactions, API requests — derived from the stale read. A DB query returning stale data is a consistency bug; an LLM acting on stale data is a consistency bug with legs.

Phantom-tool. Agent A queries the tool registry at T₀ and finds a tool present. Between T₀ and the moment it invokes the tool, Agent B removes the tool from the registry. Agent A calls a tool that no longer exists. In MCP-connected multi-agent systems, tools register and deregister dynamically; this is not a hypothetical. The 2025-era MCP tool ecosystem is architecturally stateless — a tool manifest valid at read time carries no guarantee at call time. (Malicious tool descriptions are a separate attack surface covered in MCP tool poisoning; phantom-tool is about legitimate deregistration racing with legitimate invocation.)

Causal-cascade. Two agents write to overlapping regions of shared state concurrently, producing a derived state neither intended. Downstream agents that read the corrupted composite state propagate the inconsistency further. Unlike stale-generation — where the inconsistency is local to one agent’s context — a causal-cascade can corrupt shared world-state that multiple agents then act upon.

The TLA+ proof in arXiv:2606.17182 establishes something specific: without explicit isolation primitives, a multi-agent system violates READ-COMMITTED consistency as a class property. This is a safety violation, not a liveness failure. It is unavoidable unless the concurrency model provides it.

⬢ loading artifact…

Why the LLM Makes This Structurally Worse

A database client throwing a transaction-isolation exception can be caught, logged, and retried. An LLM generating a plan has no equivalent of SQLSTATE 40001. The model’s context was populated at read time; it neither knows nor can query whether that context has been invalidated.

Alignment does not help. A model that is honest, capable, and perfectly instruction-following still generates stale-read plans — because the model’s knowledge of world-state is bounded by what was in its context when generation began. The research in arXiv:2606.17182 uses 32 pages and 6 tables of formal machinery to establish what intuition already suggests: the failure mode is architectural, not behavioral. Fixing alignment does not close the race window.

This connects to the broader picture of agent memory architecture: the choice of memory store is not just an economics decision, it is a concurrency architecture decision. A memory store that provides no isolation guarantees is a concurrency hazard at any scale of parallelism.

The Blockchain’s Accidental Solution

Ethereum’s execution model is SERIALIZABLE at the transaction level. Within a single transaction, the state machine holds still — no concurrent writes, no phantom reads. The EVM processes one transaction at a time, and every storage slot read returns the canonical post-state of the previous transaction in the same block. A multi-agent system where each agent’s decision maps to a single atomic EVM transaction gets free serializable isolation.

But this holds only within the transaction. The 12-second slot clock described in The Twelve-Second Floor introduces a mandatory staleness window: an agent that reads chain state at block N and submits its transaction at block N+K is acting on a snapshot that is now K × 12 seconds old. For K = 3, that’s 36 seconds — enough for three complete blocks of other agents’ mutations to have landed.

Cross-block multi-agent interactions therefore re-introduce all three anomaly classes:

• Stale-generation: the state an agent read two blocks ago is not the state it’s committing against
• Phantom-tool: a contract function that existed at read time can be proxy-upgraded away before call time (see The Code Isn’t Frozen)
• Causal-cascade: two agents submitting transactions that depend on the same storage slot in the same block — MEV searchers understand this game

The on-chain serial model also prices itself out of high-frequency multi-agent coordination: a state write costs between $0.001 on L2 and $3+ on L1, and the slot clock imposes a 12-second minimum between read and confirmed commit. Off-chain coordination with chain-anchored commits is the practical architecture.

Off-Chain Solutions

S-Bus: Observable-Read Isolation

The core problem with existing database isolation is that it requires clients to declare their read sets upfront, or to run inside a transaction that the DB can track. LLM agents can’t do either: they don’t know what they’ll read before they read it, and they don’t run inside DB transactions.

S-Bus (arXiv:2605.17076) solves this without requiring agent modification. Its central mechanism, the DeliveryLog, intercepts all HTTP GET traffic from every agent at the middleware layer. At commit time, S-Bus reconstructs each agent’s effective read set from what it actually fetched — automatically, without any agent-side instrumentation.

The isolation property it enforces, Observable-Read Isolation (ORI), is a partial causal consistency over the HTTP-observable read projection. If any resource an agent fetched has been mutated by another agent since the fetch, the commit is rejected. The agent retries with fresh context.

Empirical results across 884,110 commit attempts (of which 427,308 occurred under active write contention): zero Type-I corruptions. Formal verification: TLAPS proves ReadSetSoundness and ORICommitSafety; TLC exhaustive model checking at N=3 agents explores 20,763,484 states with zero violations; 9 Dafny inductive lemmas discharged. Empirical parity with PostgreSQL 17 SERIALIZABLE isolation and Redis 7 WATCH/MULTI — with no agent code changes required.

The tradeoff is coverage: ORI is weaker than SERIALIZABLE. It tracks reads through the HTTP layer, which means it covers the observable read projection, not writes the agent might have derived internally. For the multi-agent DeFi and coordination patterns where the read set is the context fed into the LLM, this is the right tradeoff.

CoAgent: LLM-Judged Conflict Resolution

CoAgent (arXiv:2606.15376, Shanghai Jiao Tong University, June 2026) takes a structurally different approach. Rather than mechanically rejecting conflicting commits, it uses the LLM itself to judge whether a conflicting write actually invalidates the agent’s plan.

The MTPO protocol (Monotonic Trajectory Pre-Order) fixes a serialization order at session launch and serves each agent reads filtered to that order — equivalent to version-stamped consistent reads. When Agent B writes to a resource that Agent A previously read, MTPO sends Agent A a one-way notification: “resource X was modified — does this affect your plan?”

The LLM can respond semantically: “Agent B updated the pool fee tier from 0.3% to 0.05% — this increases my yield, so my allocation plan still holds.” Or: “Agent B removed Pool XYZ from the registry — I need to re-select.” The framework then either proceeds or triggers a targeted repair via saga-style inverse operations that undo and reorder only the affected steps.

This is the property that distinguishes multi-agent AI concurrency from traditional database concurrency: the LLM can semantically reason about the relevance of a conflict, not just its existence. A database must abort and retry the whole transaction. An agent can patch exactly the operations that depended on the changed state. The cost is a model round-trip for conflict evaluation — appropriate when the transaction spans minutes of inference.

What to Build Around

For on-chain multi-agent systems, the concurrency hierarchy maps cleanly:

For system designers: if your agents share any mutable state — a vector store, a tool registry, a working-memory cache, a shared ledger — they need a concurrency primitive. The choice of primitive determines the failure mode more than the choice of model. A more capable model with no concurrency control still stale-reads; a less capable model with ORI never does.

The deeper shift: multi-agent AI engineering is concurrent systems engineering. The correctness conditions (linearizability, causal consistency, sequential consistency) and the verification tools (TLA+, Dafny, model checking) come from that field. The anomaly taxonomy from arXiv:2606.17182 is a direct import of concurrent programming theory into the AI agent layer — and the papers confirm the import was necessary.

Takeaways

• Shared-state multi-agent LLM systems exhibit three anomaly classes — stale-generation, phantom-tool, causal-cascade — that are formally unavoidable without explicit isolation primitives, regardless of how aligned the agents are
• Ethereum’s serial execution model provides SERIALIZABLE isolation within a transaction; cross-block windows of K slots reintroduce all three anomalies with a K × 12-second staleness radius
• S-Bus provides Observable-Read Isolation without agent modification: zero corruptions across 884,110 commits (427,308 under contention), TLC-verified over 20.7M states
• CoAgent’s MTPO enables LLM-judged conflict resolution — the model semantically evaluates whether a detected conflict actually invalidates its plan, enabling targeted repair instead of full rollback
• The right mental model: multi-agent AI is concurrent systems engineering; alignment and capability are orthogonal to consistency