Tool Execution
The unglamorous machinery that makes an agent's actions safe: every tool call has a time limit, a careful way to retry, and a guarantee it cannot accidentally happen twice.
You've hovered over a payment button after the page froze — click again and maybe you pay twice. Good checkout systems make that impossible: press the button as many times as you like, you are charged once. Tool execution gives every agent action that same guarantee.
The problem, in plain words
An agent tells a tool to issue a refund. The network hiccups mid-call. Did the refund go through? If the agent retries, maybe the customer gets refunded twice. If it doesn't, maybe the customer was never refunded at all. Multiply that dilemma by every action your agents take, every day, and 'the agent did it twice' or 'the agent crashed halfway through' stops being a technicality — it becomes a customer-visible problem with your name on it.
What we set up
Every call carries an idempotency key — a unique receipt number derived from the job itself, so if the same request arrives twice, the system recognizes the receipt and performs the action only once. Every tool has an explicit timeout, so nothing waits forever. Retries are bounded and spaced with exponential backoff (waiting a little longer between each attempt instead of hammering a struggling system). Each call site declares its failure plan in advance — retry, escalate to a human, or park the job in a dead-letter queue (a holding pen for failed work, so nothing silently disappears). And every attempt links back to its parent in the trace, so a retried call reads as one story instead of scattered fragments.
How it works, step by step
- Every action gets a receipt number
The idempotency key means the same request arriving twice is performed once. Retrying becomes safe by construction.
- Every call has a time limit
A stuck tool triggers the timeout instead of freezing the whole workflow.
- Retries are careful, not frantic
A bounded number of attempts, each spaced further apart — pressure comes off a struggling system instead of piling on.
- Every call knows its plan B
Declared in advance: retry, hand off to a human, or park in the dead-letter queue. Failure is a plan, not a surprise.
- Nothing disappears silently
Work that ultimately fails waits in the holding pen for a human — it never just evaporates.
- The whole story is one thread
Every retry links to the original call in the trace, so an investigation reads one timeline, not confetti.
What changes for you
Before: a timeout was a genuine dilemma — retry and risk doubling the action, or don't and risk it never happened — and a crash mid-action meant manual cleanup by whoever noticed. After: retries are safe, crashes are recoverable, failed work waits visibly for a human, and the runtime stops being a source of incident reports. What it won't do: it makes actions safe to perform and repeat — it does not judge whether an action should happen at all. That decision belongs to permissions and human approvals.