Should an agent keep tool-call state in the model or the app?
Summary
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.
Similar Articles
When a tool call times out, how does your agent know whether it actually happened?
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.
How are you catching bad tool calls before your agent acts on them in prod?
A discussion about strategies for detecting and preventing erroneous tool calls by AI agents before they execute in production environments.
As you add more tools to an agent, it starts calling the wrong ones. Letting the model write code to call them is the fix.
The post argues that as an agent's tool set grows, direct tool calling degrades, and the more robust fix is letting the model write code in a sandbox to call tools as functions — reducing schema clutter in context and lowering wrong-call rates — at the cost of sandbox security concerns.
Should AI agent tool calls be checked before they run?
A discussion on whether AI agent tool calls should be checked before execution, exploring safety and validation considerations.
Your agent's retry logic dies when the agent does
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.