Set AI agent pilot success criteria before development begins: define one unit of work, its accepted outcome, the errors that stop launch, the human effort allowed and the commercial threshold required to continue. Record the baseline and evidence source for each measure. Give one owner authority to scale, revise or stop the pilot.
This turns a pilot into a decision instrument. The team learns whether a bounded agent workflow improves the operating result under real conditions, while cost and risk remain contained. A demo proves that a model can produce an output. A pilot must prove that the organisation can accept, govern and repeat the outcome.
Start with a workflow unit the business can verify
“Improve customer support” gives builders no stable denominator. “Resolve a billing query that does not require a refund above £100” defines a case segment, authority boundary and outcome that the support platform can verify.
Choose a unit already represented in an operating system. Examples include one qualified opportunity accepted in the CRM, one invoice matched and posted in the ERP, one reviewed pull request merged without regression, or one support case resolved without repeat contact inside the agreed window.
Write four fields before discussing architecture:
- Input: the event or case that starts the workflow.
- Terminal state: the observable condition that ends it.
- Evidence system: the CRM, ERP, ticketing tool, repository or other source that confirms the result.
- Exclusions: cases the pilot will route to a person.
OpenAI’s practical guide to building agents recommends agents for workflows involving complex judgement, brittle rules or heavy unstructured data, and advises teams to validate that fit before committing. That filter matters commercially. A deterministic automation will beat an agent when the path is stable, because it offers lower variance, simpler testing and cheaper operation.
Capture the baseline before the agent changes the work
A pilot cannot show improvement without a credible before state. Sample recent cases from the same segment and record the measures attached to the decision you expect to make.
For an internal research workflow, the baseline may include preparation time, reviewer time, acceptance without revision and time from request to accepted brief. Support adds resolution, escalation and repeat-contact rates. Revenue workflows need accepted pipeline movement or realised margin alongside activity.
Use the same measurement definitions for baseline and pilot cases. If the team changes the case segment, acceptance rubric or timing window halfway through, preserve the old cohort and begin a new one. Blended figures hide whether the agent improved or inherited easier work.
OpenAI’s enterprise AI report combines usage data with a survey of 9,000 workers across almost 100 enterprises. Its reported time savings show that productivity can be measurable, while its case studies connect AI to revenue, customer experience and development cycles. A local pilot needs the same separation: time saved is one result; accepted business output is another.
Define acceptance outside the agent
Task completion describes what the system claims. Acceptance records whether the workflow owner can use the result.
For each case, capture one of four decisions:
- accepted without changes
- accepted after minor correction
- returned for material rework
- rejected or escalated
Attach the reason and active review time. A high completion rate paired with heavy correction creates work that the agent dashboard will miss. The acceptance record exposes whether labour disappeared, shifted into review or increased through reconstruction.
Anthropic’s guide to agent evaluations distinguishes the transcript from the outcome. An agent can state that a flight was booked while the reservation database shows no booking. The same principle applies to business pilots: inspect the final state in the operating environment, then use the trace to explain how it happened.
Build the first acceptance set from representative work. Include normal cases, common exceptions and rare failures with expensive consequences. Domain experts should write the rubric because they carry the judgement the pilot is trying to reproduce. Technical owners can encode and automate parts of that rubric after the business standard is explicit.
Copilot Studio agent evaluation offers a deeper treatment of test sets, rubrics, transcripts and release gates.
Separate quality gates from commercial gates
One average score lets strong performance in a cheap dimension conceal failure in an expensive one. Use independent gates so the pilot cannot trade a critical safety failure against faster handling time.
Quality gate
Measure accepted outcomes, material corrections and performance by case segment. Set the minimum acceptance rate and maximum material-rework rate before the first live run.
Safety and authority gate
Name the prohibited outcomes: restricted retrieval, unapproved external communication, approval bypass, incorrect financial action or another consequence specific to the workflow. A single critical event can stop expansion even when average quality remains high.
OpenAI’s building guide identifies exceeded failure thresholds and high-risk actions as triggers for human intervention. Give those triggers operational force through a named reviewer, a response window and a stop path.
Adoption gate
Measure repeat use among the intended operators, abandonment and work completed outside the pilot. Interviews explain the behaviour; system events establish its scale. Low repeat use can reveal weak utility, poor interface fit, missing trust or a pilot that adds review without removing another step.
Commercial gate
Compare full cost per accepted outcome with the baseline. Include model and tool usage, licences, implementation allocation, review, exception handling, rework and recovery. Then connect the accepted outcome to the operating consequence the sponsor values.
The AI agent unit economics guide sets out the run-level economic record required for that calculation.
Use a scorecard that forces a decision
Write thresholds as operating statements rather than aspirations. The exact numbers depend on the workflow, risk and baseline; the scorecard structure stays consistent.
| Dimension | Measure | Evidence | Decision rule |
|---|---|---|---|
| Outcome | Accepted cases ÷ eligible cases | Reviewer decision plus operating-system state | Clear the agreed threshold in the named segment |
| Quality | Material rework and rejection | Rubric, correction reason and transcript | Stay below the agreed ceiling |
| Safety | Critical prohibited outcomes | Audit log, permission record and incident review | Zero within pilot scope |
| Human effort | Active review and exception time | Review events and operator sample | Improve against baseline without moving work elsewhere |
| Adoption | Repeat use and workflow abandonment | Product events plus operator interviews | Show sustained use by the intended group |
| Economics | Full cost per accepted outcome | Run cost, labour and outcome record | Beat the agreed baseline or strategic investment threshold |
| Recovery | Time and work required to contain and correct failure | Incident and case record | Remain inside the authority boundary agreed for the pilot |
Each row needs an owner, review cadence and source definition. Record thresholds before results arrive. Otherwise, the team can reinterpret weak evidence as learning and keep an unproductive pilot alive.
NIST’s Generative AI Profile frames risk management through governance, mapping, measurement and management. A decision scorecard puts those functions around one workflow: accountability is named, impact is mapped, behaviour is measured and authority changes according to evidence.
Set case thresholds and review dates
Calendar duration alone gives a poor stopping rule. Twenty quiet cases over eight weeks provide less evidence than 200 representative cases containing the workflow’s normal variation.
Define:
- a minimum number of eligible cases
- required coverage across important segments
- the edge cases that must be tested deliberately
- a date for interim review
- a maximum spend and operating exposure
- the person authorised to pause the run
Run several trials for variable tasks during offline evaluation. Anthropic notes that model outputs vary and recommends multiple trials to produce more consistent evaluation results. Live pilots also need segmentation: aggregate performance can conceal a failure concentrated in one customer type, source condition or action path.
Avoid widening scope to rescue a weak result. New tools, sources and permissions change the system under test. Close the first cohort, document the finding and open a revised pilot with its own version and thresholds.
Choose scale, revise or stop
The final review should end with one of three decisions.
Scale when the defined segment clears every gate and the evidence can be reproduced. Expand volume or authority one step at a time. Keep the new boundary measurable.
Revise when the workflow has valuable demand but a specific mechanism blocks performance. Common causes include poor source quality, ambiguous policy, weak tool design, an oversized case segment or a review packet that lacks evidence. Change the mechanism and rerun the affected tests before reopening live scope.
Stop when a simpler automation handles the work, users reject the changed workflow, recovery remains disproportionate or full cost exceeds the value of accepted outcomes. Ending the pilot protects engineering time and management attention for a stronger use case.
This decision discipline also protects trust. Teams can support further investment when the sponsor shows where value appeared, which authority was tested and how failures were contained. Ambiguous success leaves every expansion request open to debate.
A one-page pre-build brief
Before anyone builds the pilot, approve a brief containing:
- workflow owner and sponsor
- defined unit, segment and exclusions
- baseline period and measures
- authoritative sources and permission boundary
- acceptance rubric and domain reviewers
- critical errors and stop conditions
- adoption and commercial thresholds
- case count, review dates and spend cap
- scale, revise or stop decision owner
- evidence retained for the final review
Model Operator uses this operating discipline to map a recurring workflow, connect authorised company evidence and define the accepted artefact, approvals and measurement events around it. The first commercial wedge is a governed Product × GTM Planning Room: one repeated, evidence-backed artefact with acceptance, revision, provenance and repeat-use measures established from the start.
For a pilot that currently has activity metrics but no decision gate, start a Model Operator build conversation or email alexander@modeloperator.io.