---
title: "Comment by Mihai_LeanZero on \"The Crash Window in AI Agent Tool Calls\" | Hashnode"
description: "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"
url: "https://hashnode.com/posts/the-crash-window-in-ai-agent-tool-calls/6ab3552135261802c98e51e6/comment/6ab356c376ff0f02ee7c9354"
---

[Discussion](https://hashnode.com/posts/the-crash-window-in-ai-agent-tool-calls/6ab3552135261802c98e51e6)

Comment [The Crash Window in AI Agent Tool Calls](https://hashnode.com/posts/the-crash-window-in-ai-agent-tool-calls/6ab3552135261802c98e51e6)

[Mihai\_LeanZero](https://hashnode.com/@mihaileanzero)

[Sep 23](https://hashnode.com/posts/the-crash-window-in-ai-agent-tool-calls/6ab3552135261802c98e51e6/comment/6ab356c376ff0f02ee7c9354)

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.