Leave uncertain results open until you can check them

All a timeout tells you is that the caller didn't get a response in time. It doesn't tell you whether the destination did the work, so I'd mark that result as uncertain until there's enough evidence to settle it either way.

Malcolm Featonby's explanation of idempotent APIs in the Amazon Builders' Library walks through this problem with a resource-creation request. The caller has to find out whether the resource already exists before risking another create. A document workflow that's lost the response carrying its new record identifier is in exactly the same spot.

Use whatever lookup the destination supports. That might be a search by your own reference, a request-status lookup, or a read using an identifier you recorded before the timeout. Check the account and environment as part of the lookup, because an empty result from the wrong account tells you nothing about the original operation.

Also check how consistent that lookup is. A new record might take a while to show up in a search index, in which case one empty search straight after the timeout doesn't prove it isn't there. Go by the provider's documented behaviour, and if you can't decide, leave the case unresolved.

When you do reconcile, you want a finding someone can act on. Either the intended record exists and matches, or it exists with conflicting values, or you've confirmed it's absent within what the destination's contract lets you rely on, or you still don't know. Save when you checked and where you looked alongside the finding, so a later operator can tell a confirmed result apart from someone's best guess.

An agent can help gather those observations and write a short case summary, as long as the evidence links sit right next to its conclusion. If it can't tell whether the action happened, it should say so and hand the case to someone for review instead of writing a confident guess.