Notifications
Clear all
Topic starter
18/08/2026 2:13 pm
TL;DR: AI agents can reach the same valid outcome through different tool paths, so exact-match assertions miss real failures in tool choice, argument construction, execution order, and state changes, according to Braintrust. Reliable evaluation needs trace-based scoring, repeated trials, regression suites, and production feedback loops that turn observed failures into new cases.
NHIMG editorial — based on content published by Braintrust: How to test AI agents: A practical guide
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should teams test AI agents that can use tools and change state?
A: Test the decision path, not just the final answer.
Q: Why do exact-match tests fail for AI agents?
A: They assume one request should produce one fixed output, but agents can legitimately take different paths or phrase the result differently.
Q: What breaks when AI agent tests ignore tool order and intermediate steps?
A: A run may appear successful while the agent skips a required check, repeats a call, or sends the wrong argument to a downstream tool.
Practitioner guidance
- Instrument tool calls in every agent span Record tool name, arguments, return values, and errors for each hop so evaluation can isolate the exact failure point instead of only flagging the end result.
- Score trajectories with pass thresholds Use scorer outputs and repeated trials to measure whether the agent reaches the right state consistently across multiple valid execution paths.
- Version regression cases from real failures Turn reviewed production traces, support incidents, and near misses into versioned evaluation cases so the suite evolves with actual agent behaviour.
What's in the full article
Braintrust's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples for scoring tool selection, argument construction, and output quality in agent workflows
- Concrete patterns for building trace-enabled evals that expose the exact tool call or schema failure
- Implementation guidance for repeated trials, threshold selection, and CI regression gating
- Production monitoring patterns that turn low-scoring traces into new evaluation cases
👉 Read Braintrust's practical guide to testing AI agents →
AI agent testing: are exact-match checks keeping up?
Explore further
18/08/2026 3:05 pm
AI agent testing has become an identity control problem as much as a software QA problem. Once an agent can choose tools, pass tokens, and trigger state changes, the question is no longer only whether it answered correctly. The real issue is whether it stayed inside the permissions, scopes, and execution boundaries the organisation intended. That makes tool-call observability and privilege scoping part of the control plane, not just the test harness. Practitioners should treat agent evaluation as a governance function, not a one-off engineering check.
A question worth separating out:
Q: Who is accountable when an AI agent makes the wrong change?
A: Accountability sits with the governance chain that approved the access model, not with the agent alone. Teams need a trace from requester to policy decision to identity issuance to action results. If that chain is missing, incident review becomes guesswork and access governance cannot be defended to auditors.
👉 Read our full editorial: AI agent testing needs trajectory scoring, not exact-match checks
