When a tool call times out, how does your agent know whether it actually happened?

Reddit r/AI_Agents Tools
agent-engineering tool-calls idempotency timeouts llm-agents reliability

Summary

A practitioner asks how agent frameworks should handle write-tool timeouts, weighing idempotency keys, read-back verification, and human escalation when downstream APIs lack idempotency support.

Timeouts are the case I keep seeing underhandled in agent setups. The agent calls a write tool, the call times out, and nobody knows whether the email went, the refund posted, or the record changed. The default in most loops is to retry, which is fine for reads and risky for writes. The options I can see: Idempotency keys on every write, generated before the call and reused on retry, so a second attempt is a no-op if the first one landed. A read back after any timeout, checking the target system for the effect before deciding whether to retry. Treat a timed out write as unknown and hand it to a human instead of letting the agent decide. The first needs the downstream API to support it, and plenty do not. The second needs a reliable way to look the effect up. The third does not scale. What are you doing for this? Especially curious about tools wrapping APIs with no idempotency support.
Original Article

Similar Articles

Should an agent keep tool-call state in the model or the app?

Reddit r/AI_Agents

A developer discussion of the tradeoffs between keeping tool-call working state in the LLM (simpler prompts but messy retries) versus owning it in the application (cleaner control flow but less agentic), highlighting duplicated or stale tool calls after timeouts as a key failure mode.

Your agent's retry logic dies when the agent does

Reddit r/AI_Agents

The author shares lessons from putting an AI agent with write access into production, explaining that retry logic inside the agent loop fails when the process dies. They advocate for treating side-effectful tool calls as durable background jobs with idempotency keys.