The tool timed out. Did the action happen?
An agent submits an update, then the connection fails. The local run says “failed.” That does not establish whether the receiving service changed anything. Before another attempt, separate the intended operation from each attempt and the external effect.
Free investigation aid · v0.1 · September 22, 2026
Worked example, not an incident report.
Every event below is fictional. No agent, service or retry mechanism was tested. This aid records missing evidence; it does not execute a recovery or establish that a retry is safe.
Complete it locally. It includes a short synthetic example you can share without exposing a production trace.
One intended update, two attempts
The authorized job is to append one approved status note to private ticket T-17. Success means one copy of that exact note on that ticket, under its existing visibility. The agent may not email the note or switch accounts to finish the job.
- Attempt A submits operation O-17. The local trace records the outgoing request.
- The receiver appends the note. This is part of our fictional scenario. The caller has not yet established it.
- The response is lost. The caller records a timeout. Its known outcome is now unknown, not “no write.”
- A blind retry creates attempt B. If the receiver treats B as a new append, two notes can result. A local operation label alone does not make the receiver deduplicate it.
Which evidence changes the decision?
- Local attempt record
- Establishes what the caller recorded sending and receiving. A timeout leaves the external effect unresolved.
- Receiver state or operation lookup
- Can establish a specific effect when identity, operation correlation, observation time and visibility are adequate. An absent result from a delayed or incomplete view is inconclusive.
- Receiver idempotency contract
- Defines whether repeated requests for the same operation avoid additional effects. Check key scope, payload matching, retention, concurrent attempts and downstream actions.
- Current authority
- Establishes who may perform the next action now. Deduplication does not authorize a changed payload, recipient, account or fallback tool.
In a constructive version of this example, an authorized lookup correlates O-17 with the exact committed note. The operator records completion without another append. If that evidence is unavailable, record the unresolved outcome and ask the named recovery owner for a decision. Do not silently widen access to obtain certainty.
If a tool fails, what may replace it?
Name permitted alternatives and a stopping condition before the run. For T-17, a private local draft is an allowed fallback; installing a new connector, using a broader token or sending email is outside the task. A prompt can describe this rule. The integration still needs to enforce the relevant access and action limits.
For the earlier access decision, use the private-repository review. For why a credential grant is broader than a task, read Permission for the wrong thing.
Sources and limits
AWS explains the ambiguity after a missing response, caller-provided request identifiers and changed intent in Making retries safe with idempotent APIs. The agent-ledger README also identifies downstream idempotency as a limit on stronger execution guarantees. Both were checked September 22, 2026; neither verifies your receiver. The timeline and record are our proposed teaching aid. Their usefulness to readers remains unmeasured.