What Is Unmergeable State?
Unmergeable state is shared, mutable state whose concurrent updates cannot be combined after the fact without breaking a rule the state must obey. Two writers that each acted correctly on the same earlier version can produce a combined result that is invalid, such as a balance below zero or a budget spent twice. Money, budgets, quotas, spending mandates, velocity counters and database schemas are typical examples. Correct concurrent use of unmergeable state requires coordination before the write, not a merge after it.
Updated
What is unmergeable state?
Unmergeable state is a term Tacnode uses when assessing AI agent workloads, to separate shared state that concurrent writers can safely reconcile from state they cannot. The distinction matters because many concurrent systems already have a working answer to conflicts. Code has git: concurrent changes on branches are merged, conflicts are surfaced, and a person usually reviews the result. A single stored record has a row lock, so the database serializes writers. Neither is unmergeable in this sense. The test Tacnode applies is one question: when two writers hit this state at the same moment, what resolves the conflict today?
The idea has a formal ancestor in database research. Coordination Avoidance in Database Systems (Bailis, Fekete, Franklin, Ghodsi, Hellerstein and Stoica) introduces invariant confluence, a test of whether operations can run without coordination and still preserve an application's invariants when their results are merged. Its analysis shows that a counter with a "greater-than" threshold, such as a balance that must stay above a floor, is invariant confluent for increments but not for decrements. Withdrawals from one balance cannot simply be merged. For that case the paper points to the escrow transactional method, which splits the amount between processes so each can spend its share without coordinating: "a balance of $100 might be divided between five servers, such that each server can dispense $20 without requiring coordination to enforce a non-negative balance invariant."
Conflict-free replicated data types (CRDTs) are the mergeable end of the same spectrum. They are designed so that, in crdt.tech's words, "the data can always be merged into a consistent state." A consistent merge is not the same as one that keeps an application's rules. Unmergeable state is what is left over: state whose rules a merge function cannot guarantee.
How unmergeable state works
The litmus test, applied to common kinds of shared state:
| State | What resolves concurrent writes today | Mergeable? |
|---|---|---|
| Source code | Branches, merge and review | Yes |
| One record, one writer at a time | Row lock or conditional update | Serialized by the database |
| Page-view counter | Increments add up | Yes |
| Account balance with a floor | Nothing, unless writes are coordinated | No |
| Shared budget or quota | Nothing, unless writes are coordinated | No |
| Database schema | Migrations collide | No |
A worked failure, with illustrative numbers. Two agents share a team budget with 400 remaining. Each reads the remaining amount, each sees 400, and each approves a 300 purchase. Both writes are valid against what each read. Combined, the budget is 200 overspent. There is no merge function that fixes this after the fact; one of the two approvals should never have happened.
Three designs keep unmergeable state correct:
- 1.Serialize the writers. Lock the budget row, or use a conditional update that re-checks the limit at commit.
- 2.Partition the state. Give each writer its own share of the budget, escrow style, and coordinate only to rebalance.
- 3.Decide and commit in one transaction. Read the current total and record the decision together, so a second conflicting commit sees the first.
Why unmergeable state matters in real-time systems
Unmergeable state is where concurrency becomes a correctness problem. With mergeable state, a stale read costs a little accuracy. With unmergeable state, a stale read lets a decision approve what it would have blocked if it had seen current state, and the damage is committed before anyone notices.
AI agents raise the stakes because they write. A fleet of agents drawing on one budget, one set of quotas or one customer account is many writers on unmergeable state with no person in between. For state Tacnode holds, such as budgets, holds and per-agent limits written by the decisions themselves, writes are transactional, so two conflicting commits cannot both land. For data owned by another system of record, Tacnode gives each decision accurate, current context to read; the conflict is still resolved where that data lives. The agent side of this is covered in ACID for agents.
FAQ
Related terms
Multi-writer contention is two or more actors reading and writing the same mutable state in the same short window. It is not multi-tenancy or partitioning.
A race condition occurs when a system's outcome depends on the timing of concurrent operations, letting interleaved reads and writes corrupt shared state.
Isolation levels control how database transactions see each other's concurrent changes, from READ UNCOMMITTED to SERIALIZABLE. Anomalies, defaults, examples.
Eventual consistency is a distributed-systems model guaranteeing all replicas converge to the same value once updates stop. How it works, and its trade-offs.
Agent spend limits cap what an AI agent may commit per transaction, period or agent. They are only as accurate as the spend total they are checked against.
ACID transactions guarantee atomicity, consistency, isolation, and durability, so a group of database operations either fully succeeds or fully fails.
The single-writer principle gives each item of mutable state one owner that performs every write, so writers never contend. Others read or send requests.
Stateful governance controls AI agent actions with policies that read changing state, such as budgets or inventory, and keeps each decision valid to commit.