An AI agent cannot be measured only by answer quality, and a successful tool call is not the same as a successful task. An agent can call an API correctly but modify the wrong object. It can also produce an acceptable deliverable after an expensive, fragile sequence of unnecessary steps. A complete metric system must answer:
- Did the user's task actually finish?
- Was the agent's process correct, necessary, and controlled?
- Could the system recover safely or transfer to a person?
- Were time and cost per successful task sustainable?
This guide focuses on agents that call tools, change external state, or execute multi-step workflows. For dataset design and output rubrics for a general AI feature, use the AI product evaluation framework.
1. Define One Task Before Counting It
An ambiguous denominator is a common source of misleading metrics. One conversation can contain three requests, while one request can span multiple sessions. Create a stable task object:
| Field | Definition question |
|---|---|
| task_id | Stable ID from goal creation to completion, cancellation, or timeout |
| task_type | Query, create, update, approve, or cross-system workflow |
| success_criteria | What evidence proves completion beyond the agent's claim? |
| risk_tier | Is failure reversible? Does it involve money, privacy, or external communication? |
| terminal_state | Success, partial, handoff, cancelled, failed, or timed out |
| evidence | Database state, API response, user confirmation, or human review |
For “move my customer meeting to next Monday,” a confirmation sentence is not proof. Verify that the intended calendar event changed, the time zone is correct, participants match the request, and any external notification received the required confirmation.
2. North Star: Verified Task Success Rate
A useful primary metric is:
Verified task success rate = tasks with external evidence and all critical conditions met / evaluable tasks
Define “evaluable” carefully. Unsupported requests, user cancellations, and requests missing required information can be excluded, but report those rates separately. Otherwise a team can improve the metric simply by expanding exclusions.
Record three outcome states:
- Strict success: every critical requirement is met with no severe failure.
- Partial success: the deliverable is useful after a small user correction.
- Failure: a critical goal is missed, state is inconsistent, or work must be repeated.
Do not collapse all three into an average. High-risk tasks may require strict success before any autonomous rollout.
Google Cloud's official agent evaluation documentation assesses final response quality, tool-use quality, and hallucination while retaining interaction traces. See Vertex AI agent evaluation. Microsoft's official framework similarly separates end-to-end task completion from tool selection, arguments, execution, and use of outputs: Agent evaluators.
3. A Five-Layer Metric Tree
Outcome layer
| Metric | Suggested definition | Use |
|---|---|---|
| Strict task success | Strict successes / evaluable tasks | Real product utility |
| Partial success | Usable after light correction / evaluable tasks | Product friction |
| User confirmation | Confirmed / tasks reaching confirmation | User understanding |
| Post-success reversal | Reversed within window / successful tasks | False success |
| Recovery success | Successful after retry / first-attempt failures | Recovery value |
Confirmation alone is not truth. Default selection, accidental clicks, or undetected errors can inflate it.
Process and tool layer
- Tool selection accuracy: necessary tools are selected without unnecessary high-risk tools.
- Argument accuracy: object IDs, times, amounts, scopes, and idempotency keys satisfy constraints.
- Tool execution success: calls do not time out, throw, or receive dependency rejection.
- Tool-output utilization: the final decision respects returned data and failure states.
- Required-step coverage: confirmation, approval, validation, and persistence are not skipped.
- Redundant-call rate: repeated or irrelevant calls that do not change the result.
An HTTP 200 means a request was accepted, not that business state is correct. For side effects, use read-after-write, ledger records, or final-state verification.
Human and recovery layer
| Metric | Numerator / denominator | Interpretation |
|---|---|---|
| Human takeover | Handed-off tasks / all tasks | Split appropriate escalation from capability failure |
| User correction | Materially edited / tasks with agent output | Output utility |
| Correction time | Total edit time / edited tasks | Human cost |
| Automatic recovery | Recovered without a person / recoverable failures | Retry and fallback value |
| Duplicate execution | Duplicate side effect / side-effect tasks | Idempotency guardrail |
A lower takeover rate is not inherently better. For ambiguous or high-risk work, timely escalation is correct behavior. Measure appropriate takeover instead of trying to remove people from every workflow.
System, latency, and cost layer
- End-to-end P50, P95, and P99 task duration.
- Time to first useful feedback, not just total completion.
- Model, retrieval, tool, and infrastructure cost per task.
- Cost per strict success = total operating cost / strict successful tasks.
- Timeout, queue wait, dependency failure, and fallback rates.
- Steps, model calls, and context growth per task.
Cost per model call rewards systems that fail cheaply. Cost per verified successful task supports a real comparison.
Safety and authorization guardrails
For agents that change external state, monitor:
- Unauthorized tool attempts and permission denials.
- Sensitive-data exposure, cross-tenant access, and unsafe logging.
- High-impact actions without confirmation.
- Operations outside amount, quantity, recipient, or time limits.
- Policy violation after prompt injection or malicious external content.
- Failed rollback, missing audit record, and unclear accountable actor.
A severe event must not be averaged away by task success. Give each event class a zero-tolerance rule or explicit ceiling with an automation stop condition.
4. Slice by Task Type and Risk
An overall rate hides important regressions. At minimum, segment:
- Read-only query versus side-effect action.
- One-tool versus multi-tool workflow.
- Common versus long-tail task.
- New versus experienced user.
- Language, region, and device.
- Low, medium, and high risk.
- First attempt versus retry.
- Agent, prompt, tool, and knowledge-source version.
Show sample size with every slice. Do not treat a one-case movement as conclusive or automatically expand traffic from a small percentage swing.
5. Event and Trace Design
A reviewable trajectory may contain:
task_started intent_resolved plan_created tool_call_requested tool_call_authorized tool_call_completed confirmation_requested user_confirmed task_completed task_verified
Useful fields include:
- De-identified task_id, session_id, and user_id.
- Agent, model, prompt, tool-definition, and policy versions.
- Tool name, argument summary, authorization result, duration, and error code.
- Side-effect flag, idempotency key, and rollback state.
- Terminal outcome, evidence source, and failure label.
- Privacy retention and access policy.
Do not log complete user inputs, credentials, or tool outputs by default. Observability remains subject to data minimization and authorization.
6. Production Dashboard
User and business outcomes
- Task volume, strict success, and partial success.
- Human takeover, user correction, and reversal.
- Trends by task type and risk.
Process diagnosis
- Tool selection, argument, execution, and output use.
- Most common failing step and error code.
- Redundant steps, loops, and trajectory-length distribution.
Efficiency and risk
- P50/P95 duration and cost per strict success.
- Unauthorized actions, duplicate side effects, privacy, and confirmation guardrails.
- Current version compared with baseline.
Every alert needs an owner and a response. For the general incident workflow, use the operations metric anomaly diagnosis guide.
7. Clearly Labeled Hypothetical Example
The following is instructional, not a real product result.
Scenario: An agent updates a CRM follow-up note and creates the next reminder.
Success requires:
- The intended customer is updated.
- The summary is faithful to user input.
- Reminder date and time zone are correct.
- The user confirms before the write.
- A CRM read-back shows both objects in the expected state.
Insufficient metrics: CRM API 200, an “all done” message, or result-page views.
Metric bundle:
- Strict task success.
- Wrong-customer and duplicate-write rates as blocking guardrails.
- Summary correction rate and mean correction time.
- P95 completion time and cost per strict success.
- Appropriate escalation when customer identity is ambiguous.
If aggregate success rises but the wrong-customer count moves from zero to one, the average is not enough to justify launch.
8. Offline Evaluation to Production Monitoring
- Build a regression set from task definitions and historical failures.
- Evaluate final state, tool trajectory, and safety policy offline.
- Pair each candidate with a rules workflow or previous version.
- Roll out to limited task types and permissions.
- Monitor outcome, process, human effort, cost, and guardrails.
- Add de-identified, reviewed production failures to regression.
- Re-run evaluation after any model, prompt, tool, or authorization change.
Offline passage is not permanent certification. Models, tools, and business data all change.
9. Copyable Metric Definition
Metric name: User task: Numerator: Denominator: Exclusions: Success evidence: Observation window: Risk slices: Events and sources: Business owner: Data owner: Refresh cadence: Alert: Response: Known limitations: Version and change date:
For a hiring case, add this system to the AI product manager portfolio guide, check role coverage in the AI product manager role guide, or browse the AI PM topic.