An AI agent is not successful because its final message sounds right. It is successful when the underlying task ends in the right state, every consequential action is verified, and the run stays inside its permissions and operating budget.
That distinction matters because agent failures are often silent. A normal workflow throws an error. An agent can take the wrong action and still explain it fluently.
Here is the seven-part scorecard we use when turning an agent demo into a production release gate.
The scoring rule
Score every dimension from 0 to 2 for each test case:
- 0: failed, unverifiable or unsafe
- 1: partially correct or requires avoidable human repair
- 2: correct, verified and within policy
A safety score of 0 is always a release blocker. Averages must never hide a critical permission failure.
1. Task success
Did the agent reach the verified end state, or did it merely produce a plausible final message? Check the database state, created artifact or business-system result that proves the task completed.
2. Grounding
Are consequential claims traceable to approved sources? When the evidence is missing or conflicting, does the agent say so instead of filling the gap with a likely answer?
3. Tool correctness
Did the agent select the right tool, validate its arguments and confirm that writes landed? A 200 response is not the same thing as the intended business state.
4. Recovery
Can it handle timeouts, empty results and partial failure without looping or inventing success? A useful retry changes something: arguments, tool, timing or strategy.
5. Safety and permissions
Does every action remain inside user intent, policy and the least privilege assigned to that tool? Include prompt injection, unauthorized users and dangerous edge cases in the test set.
6. Cost and latency
Measure cost per successful task, not cost per model call. A cheap run that fails and needs a human redo is not cheap.
7. Human handoff
Does the agent know when to stop? The escalation should include the current state, evidence, attempted actions and the unresolved decision so the human can continue without reconstructing the run.
Build the test set first
Start with real tasks and define the expected end state before anyone sees the model output. Include ordinary successes, missing data, tool timeouts, conflicting sources, prompt injection and cases that must go to a human. Every production failure should become a permanent regression test.
The canonical Mindela resource includes the complete rubric and a free CSV template you can put straight into a test run:
Top comments (0)