The Agent That Sent the Same Email Four Times
Read what each party saw, commit to a cause, and only then find out which of them was right. The root cause, why the obvious reading was wrong, and the fixes are all held back until you have answered.
The symptom
What was reported, before anyone knew what was happening.
What each party saw, and what each concluded
The evidence, in the form it actually arrived in — several parties, several partial views, several confident conclusions.
| Who | What they could actually see | What they concluded | Verdict |
|---|---|---|---|
| Agent runtime | The model returned a send_email tool call. The tool call executed and the HTTP request timed out at 30s. | The tool call failed; return the error to the model so it can decide what to do. | ✕ wrong |
| The model | A tool result reading error: request timed out. | The email was not sent. Reasonable next action: send it again. | ✕ wrong |
| Email provider | Four distinct API calls, each with a unique message id, each well-formed. | Four legitimate sends. | ✕ wrong |
| Operator | Run log: 1,100 runs, zero errors, zero retries. | The agent behaved correctly; the provider must be duplicating. | ✕ wrong |
4 of 4 parties reasoned correctly from what they could see and still reached the wrong conclusion. Nobody in this table is careless. Each one acted on complete-looking local information, and the information was local. That gap — between what a node can observe and what is true — is the whole domain, and one of these readings will usually be yours.
Commit before you read on
Nothing in the orchestration layer retried anything — the retry count really is zero. Commit before reading on: identify who performed the retry, and why the run log could not see it.
Write it down even if you are unsure. An unwritten guess quietly becomes “that is what I thought” the moment you read the answer.