Not the model: your AI can repeat a real action (posting, ordering, invoicing, alerting) when the retry built in as a safety net fires before the "this is already done" mark gets written. The model doesn't need to get anything wrong. All it takes is the system around it writing that mark at the wrong moment. We found this in our own social media publishing engine, and the rule we learned applies just as much to any AI agent that genuinely acts on your ERP, your CRM, or your business WhatsApp.
The pattern: a safety net that duplicates the thing it was protecting
Almost any system that posts, sends, or writes something automatically carries a retry: if the first attempt fails because of a slow network, a service that blips for a second, or a function that takes longer than expected, it tries again later so the job doesn't get stuck half done. That's a reasonable call. The problem isn't retrying. It's when the system records that the action already happened.
If that mark gets written after confirming the action succeeded, there's a gap between "the action already happened" and "the system knows it happened." If something fails exactly in that gap, not while acting, but while trying to record it, the system still thinks the task is pending. The retry, doing exactly what it was told to do, repeats it.
The real case: two duplicates out of six days that didn't duplicate anything
Our LinkedIn publishing engine runs twice a day on purpose, as a safety net in case the first pass fails. The "this post is already published" mark was written right after confirming the post went out, not before. Twice (August 23rd and August 28th), a slow network or a function that took longer than usual left the post published but unmarked in time, and the second pass of the day, seeing the task as still pending, published it again.
What makes the case interesting isn't the failure itself, it's the proportion. Since this cadence started on August 12th, there were six other publishing days that didn't duplicate anything, and the three other networks running in parallel (Threads, Facebook, and Instagram) duplicated zero posts in that same period, because they don't share that same double-pass mechanism. The failure wasn't in "posting to social media" in general. It sat, precisely, in one single time gap between two steps of a single channel.
| What was checked | Result |
|---|---|
| Publishing days since August 12th | 2 of them duplicated the LinkedIn post |
| Days that did NOT duplicate anything | 6, in the same channel and period |
| Other three networks (Threads, Facebook, Instagram) | 0 duplicates, since they don't run a double pass |
| Cause | the "done" mark was written after publishing, not before |
The fix wasn't removing the retry (it's still needed, in case the first pass genuinely fails). It was flipping the order: reserve the publish before attempting it, and only release that reservation if the attempt actually fails. If the attempt succeeds, the reservation stays locked, and the second pass, finding it already taken, leaves it alone. A hard cap of one publish per day per channel was also added, as a second, independent barrier.
The decision rule: reserve before acting, release only on failure
The question to ask of any AI agent that writes to your system (not one that just answers, but one that acts: posts, orders, invoices, schedules) isn't "does it have a retry?". Almost all of them do, and that's fine. The question is: in what order does it write the "already done" mark relative to when it actually acts?
- If the mark is written before acting (reserve the slot, act, and only release the reservation if it fails), a retry that arrives late finds the slot taken and does nothing. Correct.
- If the mark is written after acting, there's a gap where the action already happened but the system doesn't know it yet. A retry that lands exactly in that gap repeats the action. That's the failure we had.
A quick checklist to audit any agent or automation that acts with a retry:
- What happens if the same action runs twice? (Is repeating it harmless, or does it have a real consequence: a duplicate order, a duplicate message, a repeated charge?)
- Where does the system write the "already done" mark: before acting, or after confirming it went well?
- Is there an independent hard cap (once per day, per order, per client) as a second barrier, on top of the mark?
- Does the retry fire automatically, or only once a person confirms it by hand?
If the answer to the first question is "it has a real consequence" and the answer to the second is "after", that's the hole, whether or not a retry is involved.
Why this matters beyond posting on social media
Posting twice is, at worst, awkward. But the same pattern, in an AI agent that acts on your actual business, costs a lot more: an agent that quotes and creates real orders inside an ERP, like the AI sales agent over WhatsApp we built for an industrial distributor (full case), has to answer this exact same question before it's allowed to write to production data: if a client check, a stock check, or an order creation gets retried because the response was slow, does the system know it already happened, or does it repeat it?
The same logic applies to an agent that invoices, books an appointment, or sends a notification to a customer: any action with a real consequence that can be retried needs this same barrier. It isn't a question of how good the model is. It's a question of the order in which two lines of code get written around it.
Checking this, in what order your agent acts and marks, and whether it has a hard cap independent of the retry, is part of the same integration work we do at AutoBoost before letting any agent touch a client's production data: more at /servicios.
If your business has (or is evaluating) an AI agent that writes to your ERP, your CRM, or your social media, and you're not sure whether it has this same hole, tell us about your case and we'll look at it with you.
