Agent Failure of the Week #2: Last Write Wins (And That's the Problem)

The failure

A dedup agent and an enrichment agent are both pointed at the contact database. One afternoon they land on the same record at the same instant. The dedup agent decides this contact is a duplicate of another and merges it. The enrichment agent, working from the pre-merge version, writes a fresh job title and company back to the record it thinks still exists. The result is a Frankenstein record, half-merged and half-enriched, that matches neither agent's intent. Worse, it happens intermittently, only when their timing collides, so it's nearly impossible to reproduce.

Why your stack wasn't built for this

Give one human a record and they edit it. Give two humans the same record and they'll eventually notice they're colliding and talk it out. Humans have an instinct to check. Agents have none. They both write, simultaneously, with no awareness of each other.

So which write wins? In a stack never designed for concurrent autonomous writers, the honest answer is whichever one commits last. That's not a rule. It's a race condition. And it produces the worst kind of data corruption: the record looks plausible, so nothing alarms, but it's wrong in ways that depend on millisecond timing you can't reproduce on demand. Nobody set out to corrupt the data. The stack simply had no opinion about collisions, so physics decided.

The test (how we score it)

When two agents write conflicting data to the same record, what resolves the conflict?

• Green: Deterministic resolution rules, documented and enforced (last-write-wins where safe, field-level merge rules where not, clear field ownership).
• Yellow: Some rules exist, but they're not comprehensive.
• Red: None. Whoever commits last wins, by accident.

The fix

1. Decide ownership per field, not per record. Name which agent or system is authoritative for each field, so two writers can't both claim it.
2. Make resolution deterministic. Last-write-wins is fine where it's genuinely safe, but that should be a decision, not a default.
3. Use field-level merges where collisions matter. Don't let one agent's blank overwrite another's good value.
4. Serialize writes to hot records. Locking or a write queue on high-contention objects turns a collision into an orderly sequence.

The bigger point

This isn't an AI problem. It's conflict resolution, a solved problem in databases for fifty years, just never wired into your CRM because, until now, your writers were humans who self-resolved. The outcome of a collision should be something you designed, not something you discover three weeks later in a data-quality fire drill.

We test exactly this on the Agentic Workflow Readiness pillar of our AI Readiness Benchmark.

See where your stack stands → revenuegroundwork.com/benchmark Or book a free consultation → revenuegroundwork.com/contact

Next week, #3: something went wrong in the data, and you can't tell whether a human or an agent did it.