A tool timeout is an unknown outcome—not proof of failure

I. The missing response is not the missing action

Imagine asking an assistant to publish an article. The tool waits, then times out. The article might not have reached the server. It might still be processing. Or it might already be public, with only the response lost on its way back.

These are different states with the same symptom. Retrying immediately can turn an uncertain result into a duplicate post. The same ambiguity matters when a tool creates a ticket, sends a message or provisions a server.

The Amazon Builders’ Library describes this problem through a provisioning request that receives no response: the caller cannot safely infer whether the resource exists. Its discussion motivates caller-provided request identifiers and reconciliation.^[1]

II. Give the operation an identity

For a publishing system, a useful proposed contract binds an operation identifier to the target publication, article identifier and exact reviewed content version. A repeated request for that same operation should return its recorded outcome. A request that reuses the identifier for different content should be rejected.

A hash of the text is useful for detecting a changed draft, but it is not the whole operation identity: publishing identical text to two deliberately selected destinations can be two legitimate actions. Keep destination and intent explicit.

HTTP defines idempotency in terms of the intended effect of repeated identical requests. RFC 9110 also cautions against automatically retrying non-idempotent requests unless the client knows their semantics are idempotent or knows the original was not applied.^[2] A JSON field called requestId does not provide that guarantee by itself; the service must enforce it.

III. Keep fallback access separate from publication semantics

Two connectors can provide useful access redundancy. They do not constitute two independent business operations. Switching from a publishing API to a workflow should carry the same operation identity, destination and content version—not manufacture a fresh request merely because the transport changed.

Our proposed fallback sequence is deliberately conservative: read the existing operation record; verify whether the intended result exists; resume only an incomplete, safely resumable step. Where the receiving service has no suitable idempotency contract, reconcile manually rather than claiming an automatic retry is safe.

Every route must retain authentication, resource authorization and the original approval scope. An access denial is not an ambiguous network outcome and must not be “recovered” by finding a route that ignores the denied permission.

IV. Report the evidence, not the most optimistic state

For a blog, define completion from the reader’s perspective. The canonical URL must return the reviewed article, including its final paragraph. The title, canonical metadata and article listing must identify that same publication. A successful database write is useful intermediate evidence; it does not establish that a static build or cached page serves the new text.

Test the failure boundary deliberately in an isolated environment: let the server commit, interrupt the response, and retry the same operation. Check that one article exists and that a changed version is refused. Then test a failed delivery followed by recovery, and verify the complete public result.

“Saved,” “delivery started” and “publicly verified” should be separate states. An assistant should report the strongest state supported by evidence, preserve uncertainty when necessary, and attach the actual result when publication is complete.