Consistency models are product decisions

Choose eventual consistency and you have chosen which of your users will see stale data, and roughly when. Choose strong consistency and you have chosen what your product does when the network partitions. 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.

The CAP theorem makes the trade unavoidable rather than optional. Partitions happen, so under partition you pick consistency or availability — you don't get both. Engineering teams usually pick a default quietly, deep in a datastore configuration, and the product team discovers the choice months later through a support ticket. "Eventual" is doing heavy lifting in that sentence: it means someone, eventually, sees stale data — a user who just changed their payment method and watches the old card get charged, at exactly the moment trust matters most.

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

I used to think of this as settled database lore. Then multi-agent systems arrived and re-imported the entire catalogue. Concurrent agents sharing state hit race conditions exactly the way concurrent transactions do: two agents doing a lost update on a shared plan document, an agent reading a teammate's half-written output, state bleeding across sessions in a multi-tenant deployment. The classical remedies map across too — optimistic concurrency control on agent writes, append-only shared event logs, the choice between a global blackboard and per-agent local state with message passing. There's even a failure mode with no human analogue: uncoordinated shared state makes agents silently redo and contradict each other's work, burning tokens on conflicts nobody detects. The distributed-systems community spent four decades earning Paxos and Raft; agent platforms get to inherit that discipline or re-learn it in production.

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.