An AI Should Be Allowed to Say: I Don't Know Whether That Action Happened

Imagine you're on the phone with your bank, initiating a wire transfer. Right as you hit confirm, the call drops. Did the transfer go through? You genuinely don't know. Calling back and just trying again is dangerous — if the first attempt succeeded, you might send the money twice. Assuming it failed and doing nothing is also dangerous — if it succeeded, you'll be surprised later. The honest answer, the one that actually protects you, is: "I don't know yet — let me check before I decide what to do next."

That small, human instinct — to pause when you're not sure, rather than commit to a guess — is something we routinely fail to build into software, and especially into AI systems that are increasingly asked to take real actions in the world: send an email, place an order, call another service, update a record somewhere outside their own control.

The problem

Any system that triggers a consequential action outside itself — a payment, an API call to another company's server, a message that can't be unsent — eventually runs into the same failure mode: it gets interrupted, crashes, times out, or loses its network connection at exactly the wrong moment, after it sent the request but before it received confirmation that the request was received, processed, or completed. The action itself is now in an unknown state on the other side of that gap. Did it happen? Did it half-happen? There is often no way, at the moment things go wrong, for the system to truthfully answer that question.

This isn't a hypothetical edge case; it's one of the oldest and most-studied classes of problems in distributed systems. It appears whenever independent systems have to coordinate consequential actions across unreliable communication — a payment retried after a timeout, a network partition that separates a service from the database it just wrote to, a request that reaches a server but whose response never makes it back. Engineers have built an entire vocabulary around coping with it — idempotency keys, at-least-once versus exactly-once delivery, retries with deduplication — precisely because the underlying uncertainty can't be engineered away. It can only be handled well or handled badly.

Handled badly almost always means guessing, and guessing has two failure directions, both bad. Guess "it must have succeeded" and you can silently lose real failures — the money never sent, the record never updated, and nobody finds out until a customer complains weeks later. Guess "it must have failed" and retry, and you risk the opposite: double charges, duplicate orders, duplicate messages, all because the system assumed it needed to try again when the original attempt had actually gone through fine.

The principle

The more trustworthy response, when a system genuinely cannot know what happened, is to say so — durably, not just as a transient error that scrolls off a log somewhere. An honest "I don't know whether this completed" is more useful, and safer, than a confident wrong answer in either direction. It preserves the actual state of the world (uncertain) instead of replacing it with a fiction the system finds convenient (success, or failure). And critically, it leaves the door open for the uncertainty to actually get resolved later — by checking the other system's own record, by asking a human, by waiting for a delayed confirmation to arrive — rather than closing that door the moment a guess gets made.

This matters more, not less, as more systems are given the ability to act autonomously. An AI agent that can place orders, send money, or call other services on someone's behalf inherits the exact same failure mode any distributed system has always had — except now the "guess" might be made silently, at machine speed, with no human in the loop to notice the mistake. The instinct to demand certainty before acting again, and to hold onto doubt honestly rather than resolve it by assumption, isn't a limitation. It's the same discipline that keeps a bank, an airline, or a payment processor from quietly making the same mistake at scale.

The outcome

Systems built this way don't pretend to know things they don't. They are better equipped to avoid duplicate actions and silently lost failures, and — maybe most importantly — leave a legible trail of "this didn't resolve" that a person or a later process can actually act on. The goal isn't a system that never fails. It's a system honest enough to admit when it can't tell.