Is your agent safe to ship?

Right tool, from overlapping tools

• Every eval item records which tool the agent chose, not only whether the task ultimately passed.
• When two or more of your tools overlap in capability, you have test cases that specifically probe which one the agent picks.
• You have a number for tool-selection accuracy. It is not a feeling, it is a percentage from a scored set.
• Near-duplicate tools (similar names, similar descriptions, overlapping parameters) are covered by dedicated confusion tests, not assumed to be fine.

The right tool, called the wrong way, is still a failure

• You score the arguments passed into a tool call, not only whether the correct tool was picked.
• A missing, malformed, or wrong-type required parameter counts as a failure, even if the call technically executes.
• You test parameter accuracy under ambiguous or underspecified requests, not only clean, fully-specified ones.
• You catch silent unit and format mismatches: wrong currency, wrong date format, wrong ID namespace, truncated strings.

Destructive actions are gated, forbidden actions are tested

• Destructive tools (delete, refund, cancel, send, transfer) are gated behind a required check or confirmation, and that gate is covered by a test, not just a prompt instruction.
• You have explicit test cases where the correct behavior is to refuse or ask a clarifying question, not to act.
• You run forbidden-tool tests: cases where a specific tool is available but must not be called, and you check that it wasn't.
• You test the agent under pressure scenarios, urgency, authority, social engineering, that are designed to push it past its own guardrails.

How it got there matters, not just where it ended up

• You score the full trajectory, the sequence of tool calls and steps, not only the final output.
• You measure how many steps or tool calls a task took, not only whether it eventually succeeded.
• Redundant or looping tool calls count against the agent, even when it eventually self-corrects.
• You would catch a task that technically succeeds but burns five times the tool calls a competent operator would use.

pass^k, not just pass@k

• You run each task multiple times and report pass^k, the odds that every attempt succeeds, not just pass@1 or pass@k.
• You know how often a reported 'success' is actually a lucky single run.
• You test the same task with paraphrased or reordered inputs to check for prompt-order and phrasing sensitivity.
• You have a number for consistency, separate from your number for raw capability.

Are you testing on data the model already trained on

• Your eval tasks were built after the model's training cutoff, or are otherwise verified to be out of its training distribution.
• None of your eval items are lifted verbatim from public docs, cookbooks, blog posts, or the tool vendor's own examples.
• You keep a private holdout slice that nobody on your own team tunes prompts or tools against.
• You would notice, and be suspicious, if a new model scored implausibly well on your exact eval set the first time it saw it.

Did anyone other than the builder check this

• Someone other than the person or team that built the agent graded the evaluation.
• Grading follows a written rubric or golden-answer set, not one person's gut call on the day.
• You keep an audit trail: every run, every score, every ship decision, timestamped and retrievable later.
• You could hand this evaluation to a skeptical stakeholder, auditor, or customer and defend every number in it.