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.
Vince Wang
Building Kiso, an open-source runtime for AI agents.
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?