Discussion on "The Crash Window in AI Agent Tool Calls"

Vince Wang · 2026-09-23T04:27:13.121Z

Disclosure: I created Kiso, the open-source agent runtime in this article. I used AI assistance to edit this English draft, and I reviewed the implementation details and claims. An agent can send a to

If the person checks and finds the ticket did get opened, does abandon cover that, or is there a way to tell the model the effect actually landed?

That still leaves the narrow window right at the send call itself, a crash between the request going out and the record write landing. That's the case the slower pass exists for, not the general retry path you've already got covered. Small enough surface that waiting until you've actually hit it once before adding it seems reasonable.

That's the window, yes. One thing narrows it for us: before posting, the sender also checks what's already public under our account, so a rerun after a crash there should stop on the duplicate instead of posting twice. Would a stop on the duplicate count as hitting it, or only a double post?

I'd call that hitting it and handling it, not missing it. A crash right at the send call is exactly what that pre-post check catches, since it looks at the destination directly instead of relying on the local record that might not have been written yet. Where it can still go sideways is if that public-state check itself comes back stale or inconclusive right after a crash, since some destinations lag before a post is visible. If the check always resolves cleanly, it's already doing what the slower pass would do and you don't need both. If it ever comes back unsure, that's the case the slower pass is actually for.

Good point. When the receiving system durably enforces an idempotency key, rerunning with the same key is much safer than asking a person to decide. Kiso’s executionId is currently a local ledger identity; it is not automatically passed through as a remote idempotency key. I also agree that checking authoritative state after a crash could shrink the ambiguous cases. Kiso doesn’t currently define a generic reconciliation hook, so a human verdict is the fallback when neither mechanism exists. How would you handle a stale or inconclusive status query?

I'd treat a stale or inconclusive status query as its own explicit outcome rather than rounding it into either success or failure. Concretely, retry the status check itself a bounded number of times with backoff first, since a single stale read right after a crash is common and often resolves within a few seconds once the receiving system catches up. But if it's still ambiguous after that window, I wouldn't retry the original tool call blind, because at that point you genuinely don't know whether you'd be creating a duplicate or completing something already in flight, and guessing wrong either direction has a real cost. I'd surface it to a human with the ambiguous status attached rather than picking a side, since the alternative is silently trading a duplicate-creation risk for a stuck-task risk with no way to tell which one you picked.

The retry-vs-ask boundary comes down to whether the tool gives you a caller-supplied idempotency key. If it does, a crash-safe retry is trivial - the receiving system dedupes on your key and there's nothing to ask a human about. Most CLI/shell tools don't expose that, so you're genuinely guessing after a crash. Before defaulting to a person, I'd check whether the tool exposes any way to query current state - did the ticket already get created for this input - rather than treating it as a binary retry-or-ask. That side-channel check is often available even when an idempotency key isn't, and it shrinks the set of cases that actually need a human to the ones where neither exists.

Search Hashnode

The Crash Window in AI Agent Tool Calls

Responses9