AI Agent Tool Validation: Check Every Action Before It Runs

Your support agent prepares a refund with a valid order ID, a numeric amount, and an accepted reason code. The request matches the tool's schema. The item, however, was already refunded after the agent read the order. If your application checks only the input format, it can send a second valid-looking refund.

Tool validation needs two layers. First, confirm that the proposed arguments match the tool contract. Then prove that the action is allowed for the current business record. The application should run both checks before any consequential tool call reaches Shopify, a help desk, an ad account, or an inventory system.

Models can produce structured arguments for a function such as issue_refund. A strict schema can require an order ID, line-item ID, amount, currency, and reason. It can reject text where a number belongs, missing fields, unsupported reason values, and unexpected properties.

That check protects the software boundary. It does not know whether the item shipped, whether another refund already exists, whether the return window closed, or whether this agent may approve the amount. Those facts live in business systems and policy records.

Treat schema validation and business validation as separate decisions. A proposal must pass both. This keeps a technically correct payload from bypassing the rules that a trained operator would check before taking the same action.

Define one tool around one business action. Give each field a specific type and meaning. Use enumerated values for controlled choices, explicit formats for IDs and currencies, minimum and maximum bounds for quantities, and required fields for evidence the action cannot proceed without.

OpenAI and Anthropic both document strict tool modes that constrain model output to the declared JSON Schema. Their guidance supports the same useful starting point: make the function contract explicit and reject arguments that do not conform. Strict output reduces malformed calls, but your application should still enforce the contract at execution time because it owns the write.

Reject extra fields rather than ignoring them. An unused field such as skip_review: true may have no effect today, but silently accepting it hides a mismatch between the agent's intent and the tool's behavior. Return a clear validation result so the job record shows why execution stopped.

Prompts can explain policy, but they should not be the final enforcement layer. Put refund limits, return windows, approval thresholds, allowed transitions, and account-specific restrictions in application code or a policy service that every caller must pass.

Check the proposed action against the agent's authority. A support employee may draft any refund but execute only refunds under a set threshold with required evidence. A Meta Ads analyst may prepare a budget change but need approval before increasing daily spend. The tool boundary should know which identity is calling and which approval record supports the request.

Return one failed rule at a time when the agent can repair it. If the request lacks a reason code, name the missing field and the allowed values. If the amount exceeds authority, stop the automated path and attach the proposal to a human review task. The agent should not negotiate with an enforcement rule through repeated guesses.

An action can pass schema and policy checks against stale evidence. Read the affected order, ticket, SKU, campaign, or payout again before the write. Compare the fields that support the decision with the version the agent used when it prepared the action.

For a refund, inspect current payment status, prior refunds, item quantity, fulfillment state, return eligibility, currency, and active disputes. If any decision field changed, stop the old proposal and evaluate it again. An approval granted against the earlier state does not automatically approve a different current state.

This check complements concurrency control. Version checks tell you that the record changed. Business validation tells you whether the proposed action remains allowed. Use both when people and automations can work on the same record.

Consider a hypothetical skincare store. A customer reports a leaking cleanser from order 1048. The support AI employee reads the order, verifies the store's photo requirement, and prepares a $28 refund for one line item. Its tool call includes every required field and uses an allowed damage reason.

While the employee waits for an approval, a support lead resolves the same ticket and issues the refund. The approval for the agent's original proposal arrives a few minutes later. The payload remains schema-valid, and the amount remains within policy. The order state has changed.

The validation gate rereads order 1048 and finds a completed $28 refund for that line item. It rejects the proposed write with code ALREADY_REFUNDED, records the matching refund ID, and tells the employee that the desired business result already exists. The employee closes the job and prepares a confirmation message instead of calling the refund tool.

If the existing refund covered a different item, the gate would return the changed refund state and require a fresh evaluation. It would not edit the proposed amount or choose a new line item on the agent's behalf.

A useful rejection has a stable code, the failed field or rule, the current record evidence, and one allowed next step. Separate repairable input errors from business decisions that need a person.

The employee can repair MISSING_REASON when the ticket contains an approved reason. It can refresh and reevaluate ORDER_STATE_CHANGED. It should route AUTHORITY_EXCEEDED or conflicting evidence to the named owner with the proposal attached.

Keep rejected calls in the job history. They show which control stopped the action and whether the employee repaired the request, refreshed its evidence, or handed the decision to a person. That record makes validation an operating control instead of a hidden technical error.

ShopDucky AI employees keep their evidence, approvals, and tool actions attached to the ecommerce job they are executing. Teams can add schema, policy, authority, and current-state checks before a connected tool changes a business record. Book a demo to see approval-gated ecommerce work run across your existing stack.