Single-Flight Safety: Why Your AI Should Never Refund Twice
Run the same action twice and you've double-refunded a customer. Here's how safe systems prevent it.
A customer messages twice because the first reply was slow. A network hiccup makes the agent retry. Two conversations about the same order land at the same moment. In each case the risk is identical and easy to miss: the same action runs twice, and now you've refunded one customer twice, or shipped two replacements for one broken item.
This isn't a model-quality problem. The agent was right both times — it should refund. It just shouldn't refund again. Safe AI actions are ones that run exactly once, no matter how many times the trigger fires. Here's how that works in plain English.
Why safe AI actions have to run exactly once
Real systems are messy. Messages arrive twice. Connections drop and retry. A page gets refreshed mid-action. Two reps — or two agents — touch the same case. None of that is exotic; it's Tuesday. And every one of those situations can fire the same action more than once.
For read-only work, a repeat is harmless. Looking up an order twice just gives you the order twice. The danger is in actions that change something: money moved, an item shipped, a plan canceled. Do those twice and the second one is pure damage.
The agent was right both times. It should refund. It just shouldn't refund again.
So the safety bar for any acting agent is this: every changing action must happen exactly once, even when the world conspires to trigger it repeatedly. Two ideas make that true.
Single-flight: one action per case at a time
The first idea is single-flight. It means that for a given case — say, order #10482 — only one action can be in progress at a time. If a second attempt arrives while the first is still running, it doesn't get its own turn. It waits for, or joins, the one already in flight.
Picture a doorway exactly one person wide. Two people arrive at once; only one goes through, the other waits. Single-flight is that doorway for actions on the same entity. It's what stops two simultaneous conversations from both refunding the same order, each unaware of the other.
- Same case, one at a time. Concurrent attempts on the same order, account, or ticket are serialized, not run in parallel.
- No racing. Two agents, two reps, or two retries can't collide into conflicting changes.
- The customer sees one outcome. Not two refunds, not a refund-and-a-reship fighting each other.
Idempotency: the same action twice is one effect
Single-flight handles things happening at the same time. The second idea, idempotency, handles things happening one after another — the retry that comes in a second later, the duplicate message an hour later.
Idempotency means an action carries a key identifying what it is — "refund order #10482 for $40" — and the system remembers keys it has already completed. If the same key shows up again, the system recognizes it as a repeat and returns the original result instead of doing it twice.
The customer still gets exactly one refund. The retry succeeds — it just succeeds by pointing at the refund that already happened, not by issuing a new one.
| Scenario | Without these safeguards | With single-flight + idempotency |
|---|---|---|
| Customer double-messages | Two refunds | One refund |
| Network retry after a timeout | Two refunds | One refund |
| Two reps act on one case | Conflicting changes | One change, one outcome |
| Same action replayed later | Another refund | Recognized as done |
Why this matters more for AI than for people
A person who refunds an order rarely refunds it twice in the same minute — they'd notice. An automated agent operating at speed and scale has no such instinct unless you build it in. The very things that make an agent valuable, doing many things fast, are what make duplicate actions likely if nothing prevents them.
That's why exactly-once execution can't be left to the model's good behavior. You can't prompt your way to it reliably. It has to be a property of the system the agent acts through — a guarantee that holds even when the model, the network, and the customer all misbehave at once.
And it pairs with everything else that makes an acting agent safe. Limits cap what an action can be. Fail-closed defaults decide whether it runs. Single-flight and idempotency make sure that when it does run, it runs once. The receipt then records that single action, so you can confirm there was only one.
Where BearScope fits
In BearScope, single-flight and idempotency are built into how actions run, not bolted on. The same action triggered twice — by a retry, a double message, or two people on one case — results in one effect, and the receipt shows the one action that happened. You get the speed of automation without the duplicate-refund tax that usually comes with it. See how it works in the product overview, read the details on our security page, or book a walkthrough.
See it on your own conversations.
Bring your busiest day. We'll score every conversation in it.
Book a walkthrough →