Enterprise AI Evaluation

AI Agent Evaluation Launch Checklist

A practical checklist for Copilot Studio, RAG, document AI, and enterprise AI agents before production.

Before launching an agent, verify that it completes the approved task, respects identity and tool boundaries, supports its answers with evidence, and fails honestly when a dependency breaks. Record the evidence and the person who can stop the release. The checks below are readable here; the blank plan and filled example are direct downloads.

Before Launch

What should you check before an agent goes live?

Use these checks as an evidence review, not a promise that one score proves readiness. A confidentiality breach or an unauthorized action blocks release even when average task quality is high. The LLM Evaluation Framework explains the broader evaluation layers.

  1. 1. Fix the task and its boundaries. Name the user, permitted decisions, tools, data sources, and explicit non-goals. For an expense query agent, reading an employee's own status does not imply permission to approve or pay a claim. Assign an owner who can accept residual risk.
  2. 2. Freeze a representative golden set. Include answerable tasks, ambiguity, expected no-answer behavior, important user segments, and known regressions. Write expected outcomes before seeing the candidate's answers. The golden test set guide shows how to make cases reviewable and repeatable.
  3. 3. Prove authorization outside the prompt. Test missing authentication, another user's record, another workspace, and read-versus-write requests. Adapters must enforce the verified caller's permissions. A polite refusal after a tool already retrieved confidential data does not pass the access test.
  4. 4. Inject tool and API failures. Exercise timeouts, rate limits, unavailable dependencies, malformed responses, and partial results. Set retry and total-response budgets. Verify that failed calls produce an honest unavailable outcome, never a fabricated status or a success message for an action that did not happen.
  5. 5. Check evidence and citations separately. Confirm that a cited source exists, is an approved version, and supports the actual claim. Test a nonexistent identifier and an irrelevant but valid document. Missing support should produce a justified no-answer or escalation. Use the RAG evaluation guide to separate retrieval from answer quality.
  6. 6. Validate the output contract. Reject missing or extra fields, invalid types, unsupported enum values, and contradictions between structured fields and prose. Check both normal responses and safe error envelopes. An invalid model response must not become a valid-looking downstream instruction.
  7. 7. Challenge untrusted instructions. Put conflicting directions inside user input, retrieved documents, and tool results. Confirm that they cannot widen permissions, select an unapproved tool, disclose other records, or trigger a write. Record attempted tool calls as well as the final answer.
  8. 8. Compare repeated runs with a baseline. Pin model, prompt, tool, schema, retrieval, and knowledge versions. Repeat important cases and inspect results by severity and segment. Run the fixed regression suite after each substantive change; do not repair a score by silently weakening its expected answers.
  9. 9. Calibrate human review. Define what reviewers grade, which cases require specialist judgment, how disagreements are adjudicated, and what blocks approval. Reviewers need the authorized evidence and trace, not just the final sentence. Track agreement before using their labels as a release gate.
  10. 10. Rehearse monitoring and rollback. Name the on-call owner, alert route, manual fallback, stop conditions, and previous accepted bundle. Test that routing can be disabled and recovery checks can run. A canary without enough traffic or working monitoring has not earned a pass.
Decision Rules

Turn the checks into explicit release gates

Freeze thresholds before evaluation and state their denominators. In the synthetic employee expense query example, the candidate needs zero critical failures across 900 attempts, all 150 permission checks passing, at least 95% functional success across 465 attempts, and at least 90% success in each functional slice. Source identifiers must resolve 100% of the time; at least 98% of sampled policy citations must support their claims. These are illustrative choices for that fictional scope, not universal benchmarks.

The same example requires a response p95 of at most four seconds in a defined load test, a rollback drill within five minutes, and a small canary with enough observations before expansion. Any unauthorized disclosure, mutation, fabricated reimbursement status, or nonexistent citation stops the rollout immediately. Sustained latency or dependency failures use predefined windows and minimum sample sizes; small samples do not count as success.

A candidate that misses a critical boundary stays blocked regardless of its mean score. A candidate with safe task-completion misses needs a documented decision from the named owners, with follow-up cases and a clear residual-risk record. See release gates for Copilot agents for the surrounding evaluation workflow.

Open Resources

Start with a plan and a completed example

The blank AI Agent Release Test Plan provides sections for scope, isolated environments, golden sets, negative cases, dependency and permission failures, schemas, regression, human review, gates, rollback, monitoring, and sign-off. The filled employee expense Agent plan completes every section and connects each important failure to a measurable decision.

All people, claims, policy rules, dates, test results, and approvals in the example are invented. Use it to understand the structure, then replace assumptions and thresholds with those approved for your own system. Neither download requires an email or account. The resource library also includes a CSV golden-set template and YAML review rubric.

Also available on GitHub: yml-blog/agent-evaluation-templates contains the blank plan, the filled example, the golden-set template, and the review rubric.

Audience

Who this is for

Review Evidence

What belongs in the release evidence packet?

Attach the immutable candidate and baseline versions, test-set version, per-case outcomes, critical traces, deterministic validation results, human-review decisions, failed-case owners, and the rollback drill result. Keep expected behavior separate from observed behavior. A reviewer should be able to explain why each required gate passed and which residual misses were accepted.

After Launch

Keep the same failure categories in operation

Track task outcomes, permission denials, citation failures, tool errors, escalation, latency, and active versions by the segments used in evaluation. Review a minimized sample of authorized traces and turn confirmed incidents into regression cases. Use application observability with appropriate access and retention; this checklist does not require adding website trackers or storing unrestricted user records.

Next Step

Ready to evaluate your agent before launch?

Download the AI Agent Evaluation Checklist