Entry 26 · Tuesday
the retry was safe and the side effect was not
Kitchen table
When the shop did not answer, we ordered again, and then two identical parcels turned up at the door.
Whiteboard
An agent tool call timed out and the harness retried it. The first call had already succeeded, but the caller never saw the response. We ended up with two of the same record. The retry logic was correct and the tool was not idempotent. Most agent harnesses retry on timeout by default. Most tools people expose to agents are plain HTTP handlers. Nobody writes an idempotency key for an internal endpoint. A read is safe to repeat and a write is not. The agent cannot tell the difference from the tool description. So the harness treats every call the same way. The fix is cheap and it belongs in the tool, not the prompt. Give every write an idempotency key the caller supplies. Return the stored result on a repeat instead of creating a second one. Then make the failure visible. Count duplicate keys received and alert on the rate. A retry that silently worked twice looks exactly like a retry that worked once.
Boardroom
Our agents now act in real systems. They place orders, open tickets and move money. When a call times out, the agent tries again. If the first attempt already worked, the action happens twice. Nothing in the logs looks wrong. The duplicate shows up later as a billing dispute or a double shipment. This is not a model problem and no better prompt fixes it. It is a gap in how our own services accept writes. The cost is small per event and it compounds quietly. So here is the decision for us. Must every tool an agent writes through reject a repeat first?
Tags
All entries · 32 in all