Your Automation Said It Worked. Sixteen Records Never Existed.

You asked your AI assistant to load your project tracker with the week's work. Twenty-six tasks. It came back and told you it had created twenty-six tasks, and it gave you the ID of every one.

Ten of them existed.

Nothing errored. No red banner, no failed-run email, nothing sitting in a retry queue. The tool answered "created" twenty-six times and was wrong sixteen of them. The only reason anyone found out was that a person went looking for a task they remembered filing, and it wasn't there.

This isn't a story about one buggy product. It's a gap opening up underneath a lot of ordinary automation right now, and it's cheaper to understand than to discover.

What actually happened

The diagnosis is the useful part, so it's worth walking through.

The missing tasks didn't go missing at random. They came in two contiguous runs: every task in two rapid-fire batches, and none from the batches on either side. Retrying the exact same payloads worked the second time. That rules out the explanation you'd reach for first, which is that something was malformed in the data. There wasn't.

What was wrong was the pace. The writes were arriving faster than the system behind the API committed them, and somewhere in that gap the service accepted the request, generated an ID, answered "created," and then dropped the write. The ID was real in the sense that something generated it. It was not real in the sense that anything was stored under it. Ask for that ID a minute later and you get "not found."

A receipt is not a record

Here's the reframe that does the work. When a tool answers "success," it is telling you about a message it received. It is not telling you about a row that exists.

Those are two different systems talking. There's the API that answers you, and there's the storage that keeps your data, and the second one is not always finished (or even started) when the first one replies. Most days the distance between them is microseconds and completely invisible. Under load, mid-deploy, behind a queue, on a retry, it stops being invisible.

There's a name for the underlying property and a standard fix for it, and both are worth knowing so you can ask about them. Most delivery systems guarantee at least once, not exactly once: a request may end up processed twice, or accepted and lost, and the honest design goal is to make that survivable rather than to pretend it can't happen. The standard fix is an idempotency key, a unique string you generate per intended write and send along with the request. The service promises that two requests carrying the same key produce one record, not two, so a retry is safe and a silent drop is detectable. Stripe's public API documentation is the canonical example of how this is exposed to customers.

You will never implement this yourself. The reason to know the term is that "do your write endpoints support an idempotency key" is a ten-word question, and the answer tells you a great deal about whether a vendor has thought about writing your data in volume.

Why this is getting worse

The check used to be free. A person filling out a form makes one write and then looks at the result, because looking at the result is how you know to move on to the next one. Nobody had to be taught verification. It was bundled into the act of doing the work.

An agent doing the same job makes twenty-six writes across two messages, reads its own tool responses, and closes the loop by telling you it's finished. The verification that used to come along for free is now a step someone has to deliberately add back.

And notice who is writing the report. It's the same process that made the mistake, using the same responses that were wrong. An agent reading back its own tool results is not checking its work. It's quoting its work to you.

This is the part that generalizes past AI. Any system that batches writes and summarizes its own outcome has this property. Agents just made it common, fast, and confident.

The second failure mode: the read that agrees with you

Same application, a different defect, and it makes the first one look less like bad luck.

A recurring task in that tracker was spawning duplicate successors on completion. Complete this week's, get two copies of next week's. Every time. It never appeared on the daily view. It was visible only on a full list query.

The daily view wasn't broken. It answered its own question correctly, and the duplicate simply wasn't due today. The check quietly agreed with the assumption instead of testing it.

Both defects point at the same discipline. Verify with a query that could have disagreed with you. For a bulk load that means a list-and-count against what you asked for, not a spot check on the IDs you were handed. Counting catches the dropped writes and the duplicates. A spot check reliably catches neither, and the more records in the batch, the worse the odds it lands on a bad one.

What to do first

• Count after every batch. Ask the system how many records now match, and compare that number to the number you intended to create. This is one query and it is the entire defense. If the counts disagree, you have a finding rather than a suspicion.
• Never accept "done" from the thing that did it. When an agent runs a bulk load, the completion report has to come from a fresh read, not from the create responses. Say so in the instructions you give it. This is a one-line addition that turns a confident wrong answer into a correct one.
• Slow the batch before you blame the payload. Contiguous failures that succeed on retry are a pacing problem, not a data problem. Add a delay between writes, cut the batch size, and see whether the failures move. Rewriting perfectly good field mappings for a day is the expensive version of this diagnosis.
• Ask about idempotency keys during evaluation. Any tool you plan to write records into at volume should have an answer. A vendor who doesn't understand the question is telling you where their product has been tested.
• Put the check somewhere it can fail loudly. A verification step that runs but never reports is decoration. The count belongs where a mismatch reaches a human: a notification, an error branch, a row in a review table.

Where you've already met this

None of this is exotic, and you've probably absorbed a version of it without naming it.

• Zapier and Make run per item, so a multi-item run can partially succeed. A Zap that processes forty records and fails on six is not a failed Zap. Depending on your error settings you may only learn about it from the history view.
• n8n's error handling defaults are the ones to check. "Continue on error" is exactly the right setting for a workflow that should survive one bad record, and exactly the wrong setting if nothing downstream counts what got through. The node keeps going, the run goes green, and the missing items are only in the execution log.
• Airtable rate-limits the API per base, which is the classic source of the pacing failure above. The ceiling is per base, not per token (5 requests per second, with 429s after that). Any tool writing to Airtable in bulk has to handle it, and not all of them do.
• Coding agents and MCP connectors are the newest surface and the least battle-tested. Claude Code, Linear's and Notion's connectors, and the growing pile of MCP servers all write real records through interfaces that were designed and shipped fast. Treat a young connector's success response as the least trustworthy in your stack.

Operator's take

The instinct this should install is small and slightly rude: treat every write confirmation as a claim by an interested party.

That's not paranoia about AI. It's the same instinct that makes you glance at the row after you save it, which you already do without thinking, in every tool you've used long enough to trust. What changed is that automation removed the glance, then agents removed the pause during which you might have glanced, and both of them replaced it with a confident sentence.

The cost of the fix is genuinely low, which is what makes it worth arguing for. One count query per batch. One line in your instructions saying the report comes from a fresh read. That's the whole program, and it converts the failure mode from "we found out in October that September's data was wrong" into "the run flagged a mismatch and we reran it."

What I can't tell you is how often this is happening in your stack right now, because the failure is silent by construction and nobody is looking. That's the honest gap. If you've been running bulk writes through an agent or a connector for months without a count check, you don't have evidence that it's been fine. You have an absence of evidence that it hasn't.

So the question to sit with isn't whether to trust your tools. It's narrower and more answerable: which of your automations writes records in volume, and which of those has anything at all downstream that would notice if half of them never landed? Start there. Usually the list is shorter than you fear and one of the entries is worse than you'd guess.