Agent evaluation strategy
Choose which evaluation evidence should govern the next release
A demonstration works but release criteria are still a collection of opinions. The decision is how to choose which evaluation evidence should govern the next release. The work begins with your actual workflow and looks for the evidence that separates intended behaviour from a consequential exception. It is particularly relevant to product and engineering leaders. A useful outcome is an explicit account of what was examined, what remains uncertain, and which decision the evidence can support.
The release evidence relationship
- Workflow requirements
Establish the basis for mandatory limits.
- Task strata
Separate easy requests from consequential exceptions.
- Coverage strategy
Retain the scoped finding and its unresolved dependencies.
Decision
Frame the decision around mandatory limits
Questions and the evidence they need
- Mandatory limits
- Inspect workflow requirements for the relevant constraint or observation.
- Task strata
- Inspect incident notes for the relevant constraint or observation.
- Decision criteria
- Inspect user groups for the relevant constraint or observation.
The decision is how to choose which evaluation evidence should govern the next release. This is relevant to product and engineering leaders when a demonstration works but release criteria are still a collection of opinions. Name the affected workflow, the consequence of a wrong decision, and the owner who can act on the result. The initial discussion should establish which evidence is already available and which uncertainty is material enough to investigate.
The specific failure hypothesis is that a high average score conceals a prohibited action on an important exception path. It remains a hypothesis until examined in the deployment. Existing internal tests or operating records may already resolve it; identify the uncovered question before commissioning additional work.
Mechanism
Critical exceptions need their own release evidence
Relationships within release evidence
- Mandatory limits
- Keep prohibited actions visible outside quality averages.
- Task strata
- Separate easy requests from consequential exceptions.
- Decision criteria
- Attach each measure to a release choice.
What this specialty examines
A strategy should say which decision each metric informs. Separate must-not-happen actions from graded quality preferences, then decide which task segments deserve independent reporting. Otherwise, a weighted average may let a large volume of easy cases outweigh an unacceptable exception.
The review should map each consequential requirement to normal, boundary and failure cases before choosing scoring methods. Identify the normal route, relevant exceptions and the authoritative record of the outcome. Inspect the relevant business-system record, enforcement event or process evidence alongside any reported status. Keep incomplete cases visible, with an explanation of what their absence prevents the owner from concluding.
The tradeoff to make explicit
For this decision, broad test coverage competes with deeper investigation of the few actions that create irreversible consequences. Compare the available design or operating choices against the same intended outcome. If one option removes a required control or changes the task boundary, describe that difference before treating its apparent simplicity, speed or lower effort as an improvement. The decision should expose the tradeoff instead of burying it in an aggregate score.
Preparation
Connect the working inputs to the boundary being examined
Evidence packet for mandatory limits
Illustrative working format
- Workflow requirements
- Confirm the applicable revision and who resolves disputed interpretation.
- Incident notes
- Check its relationship to the relevant workflow and expose missing context.
- User groups
- Name the custodian and the conditions requiring a refreshed version.
- Existing test inventories
- Separate required outcomes, consequential exceptions, and reviewer interpretation.
Start with workflow requirements, incident notes, user groups and existing test inventories. Identify the owner, revision and operating context of each source. Sanitised examples may support initial design, but differences from actual conditions should remain explicit. Where direct access is unsuitable, a customer-controlled evidence or execution route may be considered, with agreed handling and retention.
The scope also needs the release owner, agreed expectations for a representative task case, and the authority to inspect the relevant boundary. Specify what evidence would distinguish the failure in which a high average score conceals a prohibited action on an important exception path from acceptable behaviour. If stakeholders disagree about intended behaviour, resolve the interpretation before classifying the observed difference as a defect.
How the work proceeds
Carry mandatory limits through to an accountable finding
From the scoped material to a decision record
- Workflow requirements
Separate hard constraints from graded preferences.
- Task strata
Apply the scoped check to decision criteria.
- Coverage strategy
Record the evidence, open dependencies, and the owner’s next decision.
Prepare the evaluation cases
Work with product and engineering leaders to assemble workflow requirements, incident notes, user groups and existing test inventories. Select a normal task, a consequential exception and a case with insufficient information. Identify the relevant requirement and expected result for each, then mark which outcomes need human adjudication. The preparation output is a case packet that separates blocking behaviour from graded quality preferences before any comparison is run.
Run and review the comparisons
Before selecting a platform, define case ownership and how evidence changes a decision. A strategy may reuse an existing runner while adding a missing policy rubric or business-state check. Tool selection follows those requirements; it should not dictate what the organisation calls success.
Choose the release or evaluation change
Use the reviewed cases to produce a coverage strategy showing decision owners, case strata and unresolved evidence gaps. Distinguish a product defect from a missing test, an ambiguous requirement or an unreliable measuring method. For each, name the proposed correction and the case that would check it. The release owner can then decide whether to change the implementation, improve coverage or restrict the intended use while a specific gap remains.
Indicative artefact
Make the coverage strategy usable by its owner
Coverage strategy
Illustrative working format
- Coverage strategy
- Retain selection rationale, accepted alternatives, and unexamined task conditions.
- Decision owners
- Name the role, decision right, handoff, and unresolved ownership boundary.
- Case strata
- Retain selection rationale, accepted alternatives, and unexamined task conditions.
A useful decision artefact is a coverage strategy showing decision owners, case strata and unresolved evidence gaps. Supporting material may include selected cases, configuration or process records, evidence references, a disagreement log and prioritised actions. Retain the case selection rationale and material disagreements alongside the result; otherwise the result may be mistaken for complete coverage.
Illustrative scenario
Examine decision criteria through a constructed exception
A constructed case and its decision paths
Illustrative scenario
- Mandatory limits
An account answer is correct, but a requested amendment lacks authority.
- Task strata
Compare answering, proposing, and executing the amendment.
- Decision criteria
Hold write authority until the missing authorisation cases are covered.
Consider a fictional situation: a support assistant answers routine questions fluently, yet the team has never agreed when it may amend an account. The scenario is illustrative, with no client engagement, executed test or measured improvement implied.
For the support example, compare answering a policy question, recommending an amendment, and executing that amendment. Each introduces a different evidence requirement. The release owner could permit answers while holding write actions until authorisation and recovery cases are covered.
Scope and next action
Keep the conclusion within selected task cases
Confirm fit before the next commitment
- Mandatory limits
- This review is limited to selected task cases.
- Workflow requirements
- The relevant owner must confirm access and the intended operating conditions.
- Coverage strategy
- The customer retains the release decision.
A result applies to the recorded configuration and selected cases. It does not establish universal agent competence or authorise release. Any engagement depends on an agreed scope, qualified team, authorised access and confirmed availability. Bring the affected workflow, its current configuration or process, the triggering change and the evidence already available. The immediate scope question is prompted by the situation in which a demonstration works but release criteria are still a collection of opinions; confirm which missing observation would change the owner’s next action.
Ways to engage
Related engagement scopes
AI Agent Evaluation Evidence Diagnostic
Find the gaps between your release decision and the evidence behind it. Start with one agent workflow and a bounded set of questions.
AI Agent Evaluation Foundation
Turn scattered tests into a repeatable release discipline. Connect the behaviours that matter to datasets, evaluation criteria and evidence your team can maintain.
AI Long-Horizon Agent Evaluation
Examine what changes when an agent keeps working. Evaluate accumulated state, recovery and goal adherence across extended tasks.
Continue exploring
Related insights and resources
Engineer the harness, not just the prompt
Define the contracts around an agent's decisions: what state it trusts, which actions can execute, how interrupted work resumes, and what evidence an operator needs to recover safely.
What would justify releasing this agent?
Replace a single pass rate with a reviewable chain of requirements, cases, observations and judgements. Distinguish task quality, control failures and uncertainty before increasing an agent's exposure.
The evidence behind the go-live decision
A working paper for leaders who need to explain why an agent workflow is ready for its next release. Includes a proposed evidence-pack structure, decision table and review agenda.