An AI agent demo usually runs once with a carefully chosen question and healthy tools. Real operations contain ambiguous inputs, expired permissions, slow APIs, and different outputs for the same request.

A successful PoC is not one polished demo. It asks whether quality, consistency, human workload, cost, permissions, and recovery remain inside predefined limits across representative repeated tasks.

Define the Evaluation Unit

Anthropic’s guide to agent evaluations provides a useful vocabulary:

Task: One assignment and its starting state
Trial: One attempt at the same task; multiple trials are required because results vary
Grader: An automated rule, model, or person that judges success
Trace: The answer plus tool calls, approvals, errors, retries, and intermediate state
Evaluation set: A collection of tasks representing real work and failures

An initial set may begin with 20–50 real tasks. That is a starting point, not proof of sufficient coverage. Include past failures, ambiguous policies, long context, missing permissions, tool outages, and hostile input rather than only easy examples.

Write the Experiment Contract Before Seeing Results

Item	What to Record
Problem and user	Who is trying to improve what work
Current baseline	Time, quality, cost, errors, waiting, satisfaction
Evaluation population	Period, work type, difficulty, exclusions
Success definition	Grader, evidence, acceptable tolerance
Trial count	Repetitions per task and execution settings
Risk limit	Failures or actions that are never acceptable
Comparators	Current process, simple automation, AI candidate
Go threshold	Pre-agreed threshold and decision owner

There is no universal “90% accuracy means pass.” Thresholds depend on the industry and the harm of the workflow. The important discipline is not lowering the threshold after the results arrive.

The 100-Point Scorecard

Evaluation Area	Weight	Core Metrics	Decision Question
Outcome quality	25	Task success, accuracy, policy compliance	Is there evidence of actual success?
Consistency and robustness	15	pass@1, pass^k, variance by difficulty	Is it stable across repetitions, exceptions, and attacks?
Human workload	15	Review minutes, intervention, approval wait, rework	Is new supervision lower than the time saved?
Latency and usability	10	p50/p95 latency, abandonment	Does it fit the real workflow?
Cost per verified success	10	Fully loaded unit cost	Is it economical after retries, tools, and review?
Security and permissions	15	Unauthorized actions, exposure, approval bypass	Do least privilege and pre-action approval work?
Operations and recovery	10	Observability, MTTR, rollback, vendor failure	Can failure be detected, stopped, and recovered?

Score each area from one to five, then calculate score ÷ 5 × weight. Critical failures never disappear into the total.

Automatic Fail Conditions

Access or transmission to an unapproved system, dataset, or recipient
Secret or personal-data exposure, or cross-user and cross-tenant mixing
Irreversible high-impact action without approval
No log capable of reconstructing outputs, tool calls, and approvals
No way to stop or recover from failure
Evaluation contamination because test tasks were repeatedly used in development
No regression test after changing the model, prompt, or tools

If any occurs, an average score of 92 is irrelevant.

Calculate the Metrics

Quality and Consistency

Task success rate = successful tasks ÷ all tasks
pass@k asks whether at least one of k attempts succeeds
pass^k asks whether all k attempts succeed consistently

If a task succeeds 75% of the time, the probability of three consecutive successes is about 42%. This is why an average success rate does not describe repeat operational reliability.

Human Workload

Human intervention rate = tasks with human intervention ÷ all tasks
Net time saved = current handling time - AI wait - review - correction - exception handling

Count the time required to read and judge an approval, not just the number of approval clicks.

Cost

Cost per verified success = model + tools and APIs + infrastructure + retries + evaluation and monitoring + human review + recovery, divided by verified successful cases

Cost per token is an engineering metric. Cost per verified success is a management metric.

Operations

p50 and p95 latency
Tool and API error rate
Rollback success rate
Mean time to detect and recover
Regression score before and after model, prompt, or tool changes

Starting Mix for the Evaluation Set

Group	Starting Share	Example
Normal representative tasks	40%	Most common workflows
Long-tail and exceptions	20%	Rare policy and ambiguous request
Past failures	15%	Real rework and complaint causes
Tool and environment failure	10%	API timeout, expired permission, partial failure
Security and hostile input	10%	Prompt injection and target substitution
Boundary and refusal	5%	Prohibited request and human escalation

These shares are not a standard. Adjust them to the actual operating distribution and potential harm.

Keep the Results Report to One Page

Baseline and comparison candidates
Evaluation-set mix and number of trials
Seven area scores plus raw metrics
Distribution by difficulty and workflow type
Critical failures and near misses
Human workload and cost per verified success
Known limitations and untested scope
Go, Revise, or Stop recommendation and next owner

A common PoC mistake is looking only at the final answer. If the answer is right but the agent queried the wrong system, attempted a permission bypass, or required more human correction than the original process, it is not ready for operation.

A PoC score is not a number for celebrating a launch. It is a mechanism for producing evidence to stop as well as proceed.