Build a behavioral benchmark suite for your agent, not just a handful of manual test runs

You are designing a behavioral benchmark suite for a customer-support agent with tools for order lookup, refund issuance (under a preset limit), and ticket escalation, scoring whether it actually completes tasks correctly, uses its tools appropriately, and respects its stated boundaries across a fixed set of scenarios — not a RAG answer-quality eval, and not a handful of manual runs someone eyeballs before each release.

AGENT UNDER TEST
GPT-5.1 function-calling agent with 4 tools: lookup_order, check_refund_eligibility, issue_refund (capped at $50), escalate_to_human

SCENARIO CATEGORIES TO COVER
Design at least these categories, each with multiple concrete scenarios, not one example standing in for a whole category:
1. Happy path — a straightforward request the agent should complete correctly end to end, with tool calls in a sensible order.
2. Ambiguous input — a request missing information the agent needs, testing whether it asks a clarifying question versus guessing and proceeding.
3. Tool failure recovery — a scenario where a tool call returns an error, a timeout, or an unexpected empty result, testing whether the agent retries sensibly, tries an alternative, or reports the blocker instead of hallucinating a result as though the tool had succeeded.
4. Boundary/stop-condition adherence — a scenario specifically designed to test whether the agent correctly refuses or escalates something outside its stated boundaries, framed as a normal-sounding request rather than an obvious edge case, since an agent that only respects boundaries when they're phrased as an obvious test isn't actually respecting them.
5. Multi-step state tracking — a scenario spanning several turns where a later step depends on correctly remembering something established earlier, testing whether the agent's state tracking holds up over the length of a real conversation.

SUCCESS CRITERIA PER SCENARIO
For each scenario, define success as a checkable set of conditions — the specific tool(s) that should have been called, and any that should NOT have been called, the specific final state or answer that should result, and any specific thing that should NOT appear in the response, such as an invented detail or an unauthorized action. "The response seemed reasonable" is not an acceptable success criterion for this suite.

FAILURE INJECTION
lookup_order returns a 500 error; check_refund_eligibility returns an empty result for a valid order ID; issue_refund times out after being called (unclear if it succeeded) — script the specific ways tools fail so recovery behavior is tested deliberately and repeatably, not left to whatever bugs happen to occur naturally during testing, which tests different things on different days.

SCORING AND GATING
Happy-path and boundary-adherence categories must hit 100% pass rate to deploy; tool-failure-recovery must hit 90%; ambiguous-input and multi-step categories are tracked and reported but don't block below 85%, flagged for review instead — state exactly what score blocks a deploy versus what's logged as a known regression to track, since a suite where every failure is equally blocking either never ships or blocks on noise, and a suite where nothing blocks isn't actually a gate.

OUTPUT FORMAT
1. The scenario list by category, each with its success criteria stated as checkable conditions.
2. The failure-injection scripts for the tool-failure-recovery category specifically.
3. The gating rule: pass rate threshold, and which specific scenario categories are hard-blocking versus soft-tracked.