FUNCTION TOOLS · VALIDATE FIRST
Function tools: validate before dispatch
Send one refund call through a tool with three side effects and compare validating every argument first with checking each one just before it is used.
Your experiment
The model calls issue_refund with a reason that has no email template. Validation happens inside each step, so the audit row and the refund succeed before the email step rejects the reason; the agent sees an error and retries. Count the refunds, then validate first.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Fictional tool and ledger: no payment, email or database service is called. Order o-1 captured 80.00; the three steps run in a fixed order (audit, refund, email) and each inline check guards only the argument its step uses. The agent retry is a fixed policy of one repeat, not a model decision. Idempotency is modeled as remembering completed steps for the same call id.
A tool with three side effects
issue_refund(order_id, amount, reason) does three things in order: it writes an audit row, refunds through a payment API and emails the customer using a template chosen by reason. Order o-1 captured 80.00, so a valid amount is above 0 and at most 80.00, and only damaged, late and wrong item have templates. Tool call proposed by the model picks one of five fixed calls. Where arguments are validated decides whether every argument is checked before the first effect, or each step checks only the argument it is about to use.
The opening run: a refund, an error and a second refund
The proposed call refunds 25.00 on o-1 with reason "changed my mind". Validation is inline, so the audit row is written and the refund succeeds before the email step discovers that the reason has no template and returns an error. The agent repeats the call once after an error: the second attempt writes another audit row and refunds another 25.00 before failing at the same step. The ledger ends with 2 audit rows, 2 refunds and 0 emails, and the agent was told both times that the call failed.
Failure boundary: validate before any effect
Choose All arguments before any effect: the reason is rejected before the audit row, the ledger stays at zero, and the retry is never reached because the error says what is wrong. Validation first gives the same clean rejection for every invalid call. Inline validation is safe only when the bad argument belongs to the first step: an unknown order o-9 fails the audit step before anything is written. An amount of 120 or -5 passes the audit step and leaves orphaned audit rows (two with the retry) and no refund.
Retries and idempotency
Turn off Agent repeats the call once after an error and the opening case leaves 1 audit row and 1 refund with no email: still a refund the agent believes failed. Keep the retry and turn on Steps keyed by call id: the second attempt reuses the completed audit and refund steps, so there is exactly one refund, but the call still ends in error with a refund issued. Idempotency limits duplication; it does not undo a partial effect. The valid 25.00 refund completes once under every setting: one audit row, one refund, one email.
Reading the run and its limits
Play replays the call, every step of every attempt, the retry and the outcome over sixty inspection seconds; Next event, Restart, Speed and Inspection time control the replay, and any input change recomputes it. The table lists each step’s result and the final metrics give the ledger. The tool, ledger and retry policy are fixtures: no payment or email service is called, and the agent’s retry is fixed rather than chosen by a model. Real tools may also need compensation (refund reversal) when a later step fails after an irreversible one.