Consistency models are product decisions

Choose eventual consistency and you have allowed readers to see temporarily different versions of state; you have not yet specified whose reads may lag or how much delay the product will tolerate. Choose strong consistency and you must decide which operations can wait or fail when coordination is unavailable. Neither is an implementation detail. Both are product decisions wearing engineering clothes, and I want product stakeholders in the room when they get made.

The anomalies have names, and the names are older than most of the companies shipping them. A lost update is two people editing the same record and one of them silently losing their work. A dirty read is a dashboard rendering a half-committed transaction. A non-repeatable read is a value changing between two reads inside what the user thought was one operation; a phantom read is rows appearing or vanishing mid-query. Database texts file these under isolation levels, as if they were tuning parameters. They aren't. Each isolation level is a menu of anomalies you have agreed to serve your users in exchange for throughput. Somebody should read the menu out loud.

I separate three contracts before choosing a datastore: which concurrent transaction anomalies are allowed, how fresh a replica's reads must be, and whose state a caller may access. They need different controls. CAP constrains the replica-consistency contract during a network partition; it does not choose transaction isolation or enforce tenant boundaries. “Eventual” permits temporary divergence, not a product-specific freshness promise. A user who changes their payment method needs an explicit read-your-writes policy; the operation that charges the card needs its own rule about which state is authoritative. Calling the database eventually consistent answers neither question.

The anomaly is the spec

So I treat the consistency decision as specification work. For each class of data: which anomalies are acceptable, for how long, visible to whom? Can a user read their own write immediately, even if others lag? Can two admins overwrite each other, and if so, who wins and is the loser told? These are questions a product manager can answer — often better than an engineer can, because the answer depends on what the moment means to the user, not on what the database can promise. Writing the acceptable-anomaly list into the PRD costs an afternoon. Discovering it in production costs a customer.

Agents re-import every classical anomaly

Multi-agent systems make those contracts harder to ignore. Two agents can overwrite a shared plan, or one can act on an incomplete update. A version check on each write makes a conflicting save fail visibly instead of silently replacing a teammate's work; the workflow must then decide whether to retry against the new version or ask for resolution. An append-only event log can be authoritative while individual agents' views lag behind it. Cross-tenant state bleed is a different failure: it requires enforced tenant and session boundaries, not merely fresher reads. I would specify these controls separately rather than put them all under “strong consistency.”

Consensus adds another boundary. Paxos and Raft can supply agreement on an input sequence; identical replicated state also requires deterministic application of those inputs. Re-running an LLM against the same history is not that guarantee. If recovery must preserve an agent's earlier decision, record the model response and replay that recorded result rather than regenerate it. The product question is whether recovery should resume the decision already made or make a new one. An agreed log cannot answer that on the product team's behalf.

The honest concession: eventual consistency is often the right call. Like counts, analytics rollups, feed ordering — staleness there is invisible or harmless, and strong consistency's cost in latency and availability is real, not theoretical. I'm not arguing for strong-everywhere; that fails differently, by being slow and fragile everywhere. I'm arguing against choosing by default. The consistency model determines which broken moments your users experience. Decide those moments on purpose, write them down, and make sure the person who owns the user's trust signed the decision — whether the writers are humans on keyboards or agents on a shared task.