In a June 11 post updated September 15, Microsoft says its data science team validates Copilot Studio’s automated “graders” with purpose-built datasets, including synthetic conversations in which otherwise good answers are deliberately degraded. The platform then measures whether a grader catches the injected defect while accepting responses that meet the defined quality bar.
That is a more defensible approach than simply asking an AI model whether another AI model’s answer “looks good.” But it does not remove the need for local validation. Microsoft’s public documentation confirms that makers can run generated or imported test sets, apply several grading methods, compare results across iterations, and export results. It does not publish the grader-specific thresholds, test-set compositions, model configurations, or failure-rate targets underlying the company’s own validation process.
The gap matters because those omitted details determine whether a score is suitable for a minor prompt edit, a knowledge-source update, or an agent that can trigger actions through enterprise systems.
Microsoft’s Method Is Meta-Evaluation, Not Agent Evaluation
The Microsoft Copilot Blog post by Data Science Manager Dikla Dotan-Cohen is about meta-evaluation: testing the quality of the mechanism that evaluates an agent. Copilot Studio graders generate scores and labels intended to help makers judge dimensions such as correctness, completeness, clarity, coherence, and tone. Microsoft says it separately tests whether those graders measure the intended dimension, distinguish meaningful response differences, behave consistently, and produce stable, interpretable results.
The notable part is the proposed ground-truth construction. Microsoft starts with a narrowly scoped test agent, generates plausible user queries and high-quality responses, then introduces controlled faults into selected answers. A response might be altered to omit key information, assert an incorrect fact, become irrelevant, or fail a safety expectation. Because Microsoft controls the alteration, it can label the result as intentionally defective and assess whether the grader flags it.
This converts an ambiguous language-quality problem into a conventional classification problem. Microsoft says it tracks true positive rate, or how often the grader correctly flags the deliberately damaged responses, and true negative rate, or how often it correctly leaves satisfactory responses alone.
Those are legitimate measures, but they answer a bounded question: can this grader recognize the faults the test designers chose to create? They do not by themselves establish that the grader will reliably spot unexpected defects caused by live retrieval, changing permissions, tool failures, tenant-specific policy, or a new model behavior.
That limitation is not unique to Copilot Studio. Research presented at ACL has documented position bias, verbosity-related preferences, and other systematic vulnerabilities in LLM-as-a-judge systems. A 2025 study, Judging the Judges, found that position bias varied by judge, task, and candidate. Another study of LLM and human evaluators found both can be influenced by irrelevant presentation cues. Microsoft’s focus on controlled degradations is a useful response to that problem, but an enterprise should verify that its own graders detect the failure patterns it actually fears.
Copilot Studio Offers Several Signals, Not One Definitive Score
Microsoft Learn documentation shows that Copilot Studio’s evaluation tool supports materially different methods: general-quality scoring, meaning comparison against an expected answer, tool-use checks, keyword matching, text similarity, exact matches, and custom pass/fail criteria. A maker can apply multiple methods to the same test set.
That matters because a single overall pass rate can hide the source of a regression. An agent may produce semantically correct answers while selecting an unauthorized connector, calling the wrong tool, failing to abstain when its knowledge is incomplete, or taking long enough to be unusable in a support workflow. A high-quality language score cannot compensate for an action taken under the wrong identity.
Microsoft’s results documentation says each run simulates conversations using the connected user account, records responses, assigns individual Pass, Fail, Invalid, or Error outcomes, and calculates a test-set pass rate. It also records end-to-end response time, including reasoning, tool calls, connector calls, queries, and workflow steps. That makes the platform more useful than a basic prompt-and-response benchmark, particularly for agents whose behavior changes according to user permissions.
But it also means that test identities are part of the test specification. An evaluation conducted with an administrator-like connection can conceal failures that ordinary employees encounter, while a test account with insufficient access can make an otherwise valid workflow appear broken. Microsoft’s guidance instructs makers to choose user profiles and verify their connections before running tests; administrators should extend that practice by maintaining named, least-privileged test identities for each meaningful role.
Synthetic Tests Need a Production Counterweight
Microsoft argues that generated data is an intentional design choice rather than a second-best substitute for real conversations. It can be created before publication, scaled quickly, targeted at a specific capability, and used where production records are unavailable because of compliance or governance restrictions. Those are sound operational reasons to use synthetic tests.
Generated prompts also address a common weakness in agent projects: testing only the clean, representative questions that the project team expects users to ask. Microsoft says its generation options can cover single-turn prompts, multi-turn conversations, questions grounded in a knowledge source, and broader topic- or instruction-based prompts. The latter categories are especially valuable for finding reasonable questions that fall outside an agent’s carefully designed happy path.
Still, synthetic data inherits the assumptions of whoever defines the scope, prompts, source material, and planned degradations. If a help-desk agent is tested only against pristine policy documents, it may score well while failing on contradictory documentation, stale pages, scanned PDFs, short user follow-ups, partial account context, or a user who asks for an action the agent should refuse.
Microsoft’s own remediation guidance acknowledges the evaluation layer can be wrong. Its documentation identifies outdated expected answers, overly rigid graders, unrealistic test cases, unsuitable evaluation methods, grader factual errors, systematic grader bias, and ambiguous acceptance criteria as distinct problems. The recommended sequence is important: fix the evaluation setup first, rerun it, and change the agent only if the failure persists.
That is a necessary safeguard against the most expensive evaluation mistake: “improving” the agent to satisfy a flawed test. Teams should preserve that separation in their change process. A failing result needs a classification before it becomes a work item against prompts, grounding, tools, or workflows.
What a Defensible Regression Suite Looks Like
For a Copilot Studio agent that reaches production users, the minimum useful suite should combine generated coverage with a controlled set of approved real-world cases. The latter need not mean unrestricted ingestion of customer transcripts. Organizations can sanitize, redact, and curate incidents into reusable tests, then add each confirmed production failure to the regression set.
A practical suite should include the following:
- It should test the same business task under every materially different identity, permission level, and connector state the agent supports.
- It should use deterministic checks for deterministic requirements, such as required keywords, exact data formats, mandatory tool selection, and prohibited actions, rather than relying only on an AI judge’s qualitative assessment.
- It should reserve custom or general-quality graders for judgments that genuinely require interpretation, with clear examples of acceptable and unacceptable answers embedded in the grading criteria.
- It should include deliberately broken knowledge, unavailable tools, stale expected answers, contradictory source documents, incomplete user requests, and multi-turn changes of intent.
- It should record a baseline by test method and scenario category, not merely one combined pass rate, so a better score in one area cannot mask a worse score in another.
- It should require a human review of a sampled set of passes and failures after major changes to the model, system instructions, knowledge sources, authentication configuration, or action tools.
Microsoft’s documentation also says evaluation results remain available in Copilot Studio for 89 days unless exported. That retention period is short for an enterprise change record. Teams that use evaluations as release evidence should export raw results and preserve the agent version, test-set version, grader configuration, test identity, connector state, and knowledge-source snapshot alongside them.
The Missing Number Is the One Buyers Need
Microsoft’s post is valuable chiefly because it frames graders as fallible systems requiring their own validation. The controlled-degradation model is a credible way to verify whether an evaluator recognizes known classes of failure, and the platform’s mix of conversation tests, expected-answer comparisons, tool-use checks, custom criteria, and user-profile simulations gives makers several ways to avoid relying on a single score.
What Microsoft has not disclosed is how often its graders fail, what kinds of degradations they miss, whether their behavior is stable across domains and languages, or what thresholds must be met before a grader reaches customers. The company also has not tied its internal true-positive and true-negative measurements to the pass-rate scores that Copilot Studio displays to makers.
Until that evidence is published, organizations should read Copilot Studio evaluation results as a decision aid with an audit trail, not proof that an agent is ready to act unattended. The immediate operational step is to version and test the test harness with the same discipline applied to the agent itself—because a bad grader can turn a dashboard full of green checks into the fastest route to shipping a regression.