AI Agent Evaluation and Assurance Field Guide
An AI agent should not enter production because it completes an impressive demonstration. Management needs evidence that the complete system can perform a defined business responsibility within its authority, recover from foreseeable failures and produce an outcome the organisation can verify. This field guide sets out the decisions and evidence required from evaluation scope to production review.
Begin with the release decision
State the exact responsibility proposed for the agent. A useful release claim identifies the business case, users, operating conditions, permitted actions and result. For example: "The agent may prepare and coordinate routine maintenance work for one asset family, but an authorised engineer retains safety decisions and closure approval."
The claim should also name the alternative. Management may compare the agent with the existing process, a simpler rules-based workflow or a recommendation-only assistant. Without that baseline, an evaluation can show that the agent sometimes succeeds without showing whether it improves the decision or process enough to justify its cost and risk.
Map the complete system before choosing measures
The model is only one component. The system may also contain instructions, retrieval, memory, orchestration, tools, permissions, deterministic rules, human approvals and downstream records. A failure in any component can produce the wrong business outcome even when the final answer sounds reasonable.
Map the path from the triggering event to verified completion. Identify the owner, authoritative evidence, permitted decisions, consequential actions, waiting states, exceptions and proof of closure. This map reveals what the evaluation must observe and prevents the team from selecting convenient text metrics for a problem that depends on operational state.
Translate business risk into evaluation requirements
Begin with the ways the proposed responsibility can fail. The agent may use stale evidence, disclose restricted data, select the wrong tool, exceed approval limits, lose an obligation during a delay or claim completion before the operating system changes. Each failure has a different consequence and requires different evidence.
Convert the material failures into explicit requirements. A maintenance agent, for example, may need to preserve the correct asset identifier, recognise a safety exception, assign a qualified technician and keep the work order open until verified restoration. Management can then distinguish critical release blockers from lower-consequence quality defects.
Build cases that represent the decision boundary
A useful test collection contains ordinary cases, difficult but valid cases, consequential failures, false alarms and combinations of conditions. Historical traces can reveal common work and past incidents. Policies, operating procedures, domain specialists and deliberate challenge design can add rare conditions that production history has not captured.
Keep part of the collection outside routine development. If developers repeatedly tune the agent against every known case, improved scores may reflect familiarity with the suite rather than stronger performance. Held-out cases test whether the revised system applies the intended rule to a new instance.
Reproduce the operational conditions that can change the result
Prompts and expected answers are sufficient only when the agent has no consequential interaction with external state. An agent that reads customer records, creates bookings or updates work orders needs a controlled environment containing representative records, permissions, tools and event sequences. The test-data collection and the operational dataset serve different purposes and should not be treated as the same asset.
Use a sandbox, mock services or isolated test systems to change the state deliberately. The environment may withdraw permission, delay an approval, return an uncertain write result, correct a source record or make an expected resource unavailable. The evaluator can then compare the observed final state with the limited states the business permits.
Define expected behaviour before examining results
Some cases have one required outcome. A payment must not exceed the approved amount, a booking must not be duplicated and a restricted record must not be disclosed. Deterministic checks should evaluate such conditions directly. Other cases allow several defensible responses and require a rubric or expert judgement.
Write the expectation before reviewing the run. State the evidence available to the agent, the actions permitted, the conditions that require abstention or escalation and the records that prove completion. This discipline reduces the risk that reviewers accept a persuasive output and invent the success criterion afterwards.
Validate every automated judge used for a material conclusion
An automated judge can assess qualities such as groundedness, policy adherence or communication at scale. However, the judge is another model with its own errors. The evaluation team should compare its decisions with expert-reviewed examples, examine disagreements and test whether it systematically favours a style, language, customer group or answer length.
Judge validation should match the intended use. A judge used to prioritise cases for human review may tolerate different errors from a judge whose score blocks a release. Where an operational fact can be checked directly, use the system record rather than ask a language model to infer it from the conversation.
Run experiments that expose variation and causal change
Agent behaviour can vary across repeated runs even when the input appears identical. Repeat important cases, preserve configuration and record model, prompt, tool, policy and data versions. Segment results by case type, consequence, language, permission level and operating condition rather than relying on one average score.
When comparing two versions, change one material design choice where possible and use the same cases and conditions. The comparison can then show whether a new prompt, tool contract, model or workflow actually corrected the failure. A higher overall score does not establish that the most consequential error improved.
Convert findings into release and restriction decisions
The scorecard should keep critical failures visible. Management may set a zero-tolerance rule for unauthorised payments or cross-customer disclosure while accepting a measured rate of recoverable wording defects. Thresholds should follow business consequence, evidence quality and the organisation's ability to detect and correct failure.
The conclusion should name the supported action boundary. The evidence may justify recommendation only, supervised action, autonomous action within a narrow limit or no release. It should also identify coverage gaps, unresolved uncertainty and the changes that require re-evaluation.
Preserve failures as regression cases
A verified failure becomes more valuable when the team can reproduce it. Preserve the initial state, triggering input, relevant policy and tool versions, observed trace, final operational state and expected correction. Remove or transform personal data according to the organisation's requirements before adding the case to a durable suite.
The regression case should fail the defective version and pass the corrected one. Test neighbouring conditions as well, because a narrow fix can solve one incident while damaging normal cases. Run the relevant suite when models, instructions, tools, policies or connected systems change.
Continue evaluation in production
Pre-release cases cannot represent every user, event or integration condition. Begin production with a bounded scope, monitoring and a named route for override, incident response and recovery. Sample completed cases across consequence and user groups, rather than reviewing only the easiest interactions or the cases already flagged by the agent.
Production traces are evidence, not automatic ground truth. A user may accept a poor result, an employee may override the agent incorrectly and an apparently successful transaction may fail later. Investigate material events, verify the operational outcome and add confirmed lessons to the offline suite.
Select platforms after defining the evidence
Evaluation platforms can store cases, run experiments, apply graders, display traces and integrate checks into release pipelines. Those functions are valuable, but they do not automatically reproduce the databases, permissions, tools and event streams that the agent will encounter. The client or implementation team may still need a business test harness around the platform.
Select a platform against explicit requirements for data handling, trace capture, custom checks, human review, judge validation, statistical analysis, sandbox integration, exports and continuous integration. The product should support the evaluation design. It should not determine which business risks deserve testing.
A maintenance example shows how the parts connect
Assume an agent prepares work for one family of cooling assets. The release claim permits it to retrieve alarms, recommend a task and coordinate an available qualified technician. An engineer retains safety judgement and approval to close the work order.
The suite includes common faults, similar asset identifiers, intermittent alarms, unavailable technicians, expired permits and a work-order call that succeeds but returns no acknowledgement. Deterministic checks verify asset, qualification, permit and final work-order state. Engineers review the diagnostic recommendation. Repeated runs reveal variable routing, while a restricted pilot tests whether the suite represents live maintenance. Management can then grant only the coordination authority supported by the evidence.
What Marketways delivers
Marketways defines the release claim, maps the operating system and converts business failures into a controlled evaluation programme. We design cases, test environments, expectations, judge-validation evidence, experiments, scorecards, regression suites and production-review plans around the client's actual decisions and systems.
The engagement gives management a defensible release or restriction decision and shows what evidence would justify greater authority later. Marketways may use suitable evaluation platforms, but the service remains independent of any single product. The evaluation design follows the business responsibility and its consequences.