A correct sentence is not a completed transaction.
Treat a model’s tool call as a proposed command, not proof that the business action is valid or complete. Your application must authorize the user, validate current state, execute a bounded operation and reconcile its outcome. Reliability comes from the action adapter and recovery design as much as from the model’s reasoning.
What changed—and what the sources establish
OpenAI’s function-calling documentation separates a model’s requested function call from application execution and the returned tool result. The application therefore controls what is actually executed. OpenAI function calling.
Claude distinguishes client tools executed by your application from server tools executed by the provider. Assign recovery and authorization ownership to the component that performs the actual operation. Claude tool use.
OWASP identifies prompt injection as a risk that can redirect model behavior, including through retrieved or external content. Treat documents and tool outputs as data; they should not grant permission to execute a new action. OWASP prompt injection.
Choose the approach that fits the constraint
Separate failures by boundary. Sending every error back to a model for another attempt hides whether the problem is authorization, state, transport or policy.
| Situation | Start here | Tradeoff / acceptance check |
|---|---|---|
| Missing required argument | Validate typed request and ask for clarification | Do not guess identifiers or amounts |
| Policy or permission rejection | Stop and explain the allowed route | More reasoning cannot create authorization |
| Transient read failure | Bounded retry with backoff | Preserve the original task and budget |
| Write timeout with unknown outcome | Reconcile command and live state | Do not submit a new write blindly |
Define a tool contract smaller than the business system
Give the agent narrow operations such as fetch_order_status or prepare_invoice_change. Avoid an unrestricted SQL, shell or API tool when the task needs one scoped action. Derive tenant and user identity from trusted session context. Validate the arguments on the server even if structured output already passed a schema check. A syntactically valid order ID can still belong to another customer.
Separate read permissions from write permissions and proposals from execution. A tool may calculate a proposed refund without granting the assistant authority to issue it. Include currency, quantity, policy version and current-state references in the proposal. Set financial or operational limits in deterministic code and require human approval where the action exceeds them. The model can explain a decision; it should not silently rewrite the rule.
Persist commands and reconcile outcomes
Create a durable command record before attempting a consequential write. Track prepared, authorized, submitted, completed, failed and unknown states. Store the business target, allowed payload and a stable command ID. Use documented provider idempotency where available and application-level deduplication where it is not. A timeout after submission belongs in unknown state until evidence establishes what happened.
Read back the authoritative result or inspect the provider’s transaction status before reporting completion. If the external service is asynchronous, distinguish acceptance from completion and give the user a reference to the pending action. Make recovery available to a worker or operator that did not participate in the original conversation. A transcript alone is a poor substitute for structured state, especially after a process crash.
Test the failure paths that a happy-path demo hides
Use fixtures for expired permissions, stale state, duplicate requests, partial success and missing data. Inject a timeout after the external write succeeds to test whether recovery repeats the action. Include malicious instructions inside retrieved documents and tool responses. A customer message saying “ignore the policy” should not make the execution layer disregard its own policy. Verify the boundary rather than hoping the model notices the attack.
Instrument the sequence with task IDs, tool names, argument-validation outcomes and final evidence. Keep sensitive data out of logs when it is unnecessary. Measure completed permitted actions, rejected invalid actions, unknown outcomes and manual interventions separately. A low exception count may mean the system hides errors; it is not automatically a sign of reliable execution. Review samples of both successful and rejected commands.
Worked example: illustrative assumptions, not a reported result
Illustrative failure scenario: a customer asks to cancel an order. The agent prepares command C-17, the server verifies ownership and cancellability, and the commerce service accepts the cancellation. The response times out. A naive loop submits another cancellation; a durable workflow instead marks C-17 unknown and queries the live order and command evidence.
Suppose 100 commands are attempted: 90 complete, five are correctly rejected by policy, three need clarification and two remain unknown. This invented example should not be summarized as 90% accuracy. Report permitted completion, correct rejection and unresolved outcomes separately. The business objective includes preventing invalid actions, not merely maximizing the share of requests that execute.
Failure modes to catch before scaling
- Schema confidence: valid JSON is treated as correct business intent. Verify target identity, policy and live state separately.
- Timeout replay: missing response is treated as failed write. Reconcile the original command before retrying.
- Instruction leakage: a retrieved document changes allowed tool behavior. Keep authorization outside the prompt and treat external text as untrusted data.
Do not normalize every failure into a friendly success message. Users need to know whether an action is completed, pending, rejected or requires clarification, with evidence appropriate to that state.
A concrete next step
Choose one action with a clear authoritative result. Implement a typed proposal, server-side authorization, durable command state and a read-back check. Demonstrate duplicate requests and a timeout after successful submission before increasing autonomy.
| Identity | Trusted tenant/user context and target ownership |
|---|---|
| Policy | Versioned allowed-action rules and approval limits |
| Recovery | Stable command IDs and unknown-outcome reconciliation |
| Evidence | Authoritative result before a completion claim |
Set an operational target for unresolved commands and the time to reconcile them. Review policy rejections for correctness without pressuring the system to execute more risky requests. A useful agent knows when it cannot proceed, and the surrounding workflow knows how to recover without inventing a successful outcome.
Practical questions
Does structured output make an action safe?
No. It helps validate format, but server code must still check identity, permissions, current state, policy and business arguments. Valid JSON can describe an unauthorized or incorrect action.
What should happen after a write times out?
Keep the original command in an unknown state and reconcile provider and live business records. Do not assume failure or submit a new write without checking whether the first action succeeded.
Should every failed tool call be retried?
No. Retry transient failures within a budget. Permission, policy and clarification failures need a different route, and uncertain writes require reconciliation before another attempt.
What evidence proves an agent completed the task?
Use the authoritative system’s resulting state, transaction or object identifiers and any asynchronous completion status. The model’s explanation or a submitted API request alone is insufficient.
Primary sources checked 11 October 2026
- OpenAI function calling — Function calls request application tool execution; the application supplies tool results back to the model.
- Claude tool use — Client tools are executed by the application, while server tools are executed by the provider.
- OWASP prompt injection — Prompt injection can redirect model behavior through malicious instructions, including external content.
The calculations in this guide are illustrative planning examples. Product documentation establishes supported features and conditions; it does not establish a measured return for your organization. Recheck account availability and release notes when implementing the recommendation.
Continue with Shopify execution adapter and Agent evidence and recovery.
Research Path