Two agents read the same unassigned task, then both write different assignments because one read missed the other's update. That is a normal operating condition in multi-agent systems coordinating around shared state, not a theoretical edge case at scale. Whether both writes succeed, one wins, or both return errors depends on the guarantees provided by the data layer. Teams often confront this only after agents begin producing contradictory results from state they assumed was synchronized.
This post maps the consistency spectrum for agent data, describes the model LaserData exposes, and explains when stronger or weaker guarantees fit different types of shared state.
What consistency means here
Distributed data systems use "consistency" in several ways, depending on the model. For agent developers, the key distinction is among linearizability, sequential consistency, and eventual consistency.
Linearizability is the strongest model. After a write completes, every later read from every session returns the new value, with one globally consistent operation order. If agent A updates a status at time T, any agent reading that field afterward sees the update. Each operation appears to occur instantly between issuance and acknowledgment.
Sequential consistency is weaker. Every agent observes operations in the same order, but that order need not follow real time. Agent B may not see agent A's write immediately, but after it appears, it remains visible to subsequent reads.
Eventual consistency is weaker again. If writes stop and enough time passes, all readers converge on one value. Shortly after a write, however, some readers can still return the old value. Convergence timing depends on the implementation and usually has no hard bound.
For agents making real-time decisions, this distinction is operational. An agent verifying that another completed a prerequisite needs linearizability, or at least sequential consistency, for a dependable check. An agent reading an infrequently changed preference can use eventual consistency when briefly seeing a stale value has little cost.
LaserData's consistency model
LaserData provides per-key linearizability for writes within one session partition. A write to shared state is immediately visible to subsequent reads of that record from any session. This guarantee covers individual record writes, not multi-record transactions by default.
LaserData uses snapshot isolation for reads, as described in our concurrency post. In brief, each read gets a consistent snapshot and includes every write completed before that snapshot. A read started after a completed write always sees it. A read that starts while a write is in flight may return the old or new value, but never a partial write.
LaserData supports explicit transactions with a commit and rollback API for multi-record operations requiring atomicity. At commit, all transaction writes become visible together. If the transaction rolls back, none do. Reads inside the transaction use snapshot isolation.
When strong consistency pays off
Strong consistency costs performance. Making a write visible everywhere before acknowledgment adds coordination latency. On a single node, that means a memory barrier and flush. In a distributed deployment, replicas require a synchronous round-trip before acknowledgment. For high-frequency agent writes, the overhead accumulates.
Strong consistency is worth the cost when an agent's decision depends on a state value and acting on stale data creates a behavioral error that is difficult to detect or fix.
Consider a coordinator managing a pool of work items. It reads each item's assignment to decide which sub-agents should take the next task. If two coordinator instances run in parallel for redundancy and use eventually consistent reads, both can see the same item as unassigned and assign it to different agents. That creates duplicate work, possible resource conflicts, and a coordination failure that is difficult to debug because each coordinator acted on data it reasonably believed was current.
This pattern requires strong consistency on the assignment record. The coordinator reads the record, confirms it is unassigned, then atomically writes the assignment with a condition that the record has not changed since the read. This is optimistic concurrency. If another coordinator wins first, the conditional write fails, so the coordinator reads again and reevaluates. It is more involved than read then write, but correct for a shared mutable resource pool.
When eventual consistency fits
Not every shared agent state needs strong consistency. We are not saying to always choose the strongest guarantee. Choose based on the cost of acting on stale data.
Agent configuration, including system prompts, model parameters, and behavior flags, is usually updated infrequently but read often. Eventual convergence within a few seconds is generally acceptable. Configuration does not change multiple times per second, and briefly running with a slightly stale value usually has a low cost.
Frequently updated aggregate counters also tolerate eventual consistency when they support display or logging rather than control flow. If a counter records total actions across an agent pool for a monitoring dashboard, showing a value a few seconds behind does not affect agent behavior.
Eventual consistency fits when state is written frequently, stale reads are inexpensive, and no agent uses the value for a decision that would be wrong if it were slightly outdated.
Cross-agent coordination patterns and consistency needs
Several multi-agent coordination patterns have consistency requirements that deserve explicit treatment.
Producer-consumer hand-off: Agent A finishes a task and writes a result with status "done." Agent B searches for records with that status and processes them. The status field needs at least sequential consistency: after A writes "done," B should eventually see it and should not later see "pending." Linearizability is stronger, making "done" visible immediately after A's write completes, which suits frequent polling where processing latency matters.
Consensus or voting patterns: Several agents write votes or preferences to a shared record, then a coordinator reads them to determine the outcome. The coordinator's read must include votes written before it. Snapshot isolation provides this: the read takes a snapshot and includes every vote committed before that point. Votes written afterward remain invisible, which is correct when determining that voting is closed.
Shared resource allocation: This is the coordinator pool pattern described earlier. It most clearly requires linearizability and conditional writes. Eventual consistency is wrong because an allocation is valid only when the resource has not changed between the read and the write.
Selecting consistency at write time
LaserData lets each write declare its consistency requirements. The default for shared state is per-key linearizability with synchronous acknowledgment, a safe choice that is not always needed. Session-scoped state is not shared across sessions, so synchronous replication adds unnecessary overhead. LaserData therefore defaults those writes to local acknowledgment with asynchronous replication, since no other session is waiting to observe them.
The write API exposes consistency as an explicit parameter by design. We considered always using the strongest guarantee with an option to reduce it, versus starting with the weakest and letting developers increase it. Shared state gets the strong default because coordination failures cost more and are harder to debug than modestly higher write latency. Session-scoped state uses the weaker default because isolation, not synchronous replication, provides correctness.
Consistency is not a deployment-wide setting. Records in one agent system can have different requirements. Classify each record type and choose its write consistency accordingly instead of applying one policy everywhere.