Copilot Studio Evaluations: Test an Agent Before Release

Copilot Studio evaluations run a collection of test cases against an agent and assess its responses using the methods you select. Start with real user requests, define what should pass or fail, and inspect individual results before a person decides whether the agent is ready for release.

The run produces evidence; the team still needs to retain what it learned. fenbs can keep the resulting lessons, repair tasks, and human release decisions so the same failure does not disappear into a private review conversation.

How do you run a useful first evaluation?

Microsoft documents different agent experiences, so check which instructions match your agent. The following path follows its single-response test set guide↗ (opens in a new tab): a single-response case tests an independent question rather than a complete conversation.

1. List the requests your agent must handle, the requests it must refuse, and the situations it must hand to a person. Choose a representative example of each.
2. Write an expected outcome for each case before seeing the answer. Specify the necessary information, prohibited behavior, and any action or reference that must appear.
3. Open the agent’s Evaluation page, select New evaluation, and choose Single responses. Add cases manually, import them, or review generated cases before using them.
4. Select suitable test methods and review the signed-in account’s connections. Run the set against a known agent version with controlled data.
5. Inspect failures and a sample of passes, fix the cause, and rerun the same cases. Save the results and the person’s release decision.

Treat this as a starting loop rather than a score to chase. Keep a small, stable set for comparison while adding cases that expose new risks. If the interface differs, follow Microsoft’s documentation for your agent experience instead of assuming every evaluation screen has identical options.

Which cases belong in the test set?

Use the agent’s actual job as the organizing principle. A hypothetical equipment-request assistant should find the approved request process, ask for missing details when needed, and avoid inventing purchasing authority. Include those ordinary behaviors alongside the uncomfortable cases that reveal its boundaries.

Microsoft’s evaluation checklist↗ (opens in a new tab) recommends defined acceptance criteria, a baseline, failure analysis, and broader coverage over time. Translate that into examples your business owner can judge. Include paraphrases, follow-up messages, and out-of-scope requests as the set grows.

Generated cases can help you start, but they cannot know every missing policy or real user misunderstanding. For the product background, see Copilot Studio; keep this test set specific to the agent you are releasing.

How do you choose a scoring method?

Choose the method that reflects the requirement. Microsoft’s single-response documentation describes checks for meaning, exact text, keywords, tool use, general quality, and custom criteria. Availability depends on the evaluation experience, so use the current method descriptions in your agent’s interface.

For a policy explanation, correct meaning may matter more than identical wording. For a required phrase, a stricter text check may be appropriate. For an action, fluent prose cannot prove that the correct tool ran with acceptable inputs; inspect the action evidence and resulting record as part of review.

Define must-pass cases separately from the overall pass rate. A generally helpful assistant could still make one unacceptable disclosure or claim a change succeeded when it failed. Have the business owner set release criteria based on consequences, and preserve that choice in fenbs Decisions and rules.

What should you verify about accounts and test data?

Review the signed-in identity and its source connections before running a test. Microsoft’s test set documentation says evaluations use the signed-in user’s access, and generated cases can contain sensitive information available to the connected account. A test run is therefore a real data-access activity, even when its purpose is quality assurance.

Prefer approved sample records where possible. Separate accounts with different access when testing permission boundaries, and verify each session uses the intended identity. Do not conclude that ordinary employees get the correct result because the builder’s powerful account answered successfully.

Keep credentials and private records out of shared repair tasks. A useful failure note can identify the case, agent version, expected behavior, and controlled evidence location without copying a sensitive transcript. Review who may access exported results before passing them around.

How do you investigate failures without hiding regressions?

Open the individual result and compare the expected outcome with the response and available activity details. Microsoft’s results guide↗ (opens in a new tab) describes reviewing test cases, comparing runs, and exporting results. Do not reduce the review to the summary pass rate.

• If the answer is wrong, check whether the approved source is missing, outdated, or contradictory.
• If an action is wrong, check the selected tool, its inputs, the connection identity, and the returned result.
• If a correct answer fails, check whether the expected answer or scoring rule is too narrow.
• If a bad answer passes, strengthen the acceptance criteria and add a case that demonstrates the gap.

Change one likely cause at a time and rerun the original set. Keep cases that previously failed so they can detect a regression, a problem returning after a change. If you revise an incorrect test, record why; silently loosening a test to improve the score removes useful evidence.

When should you rerun checks and ask for human review?

Repeat the relevant tests after changes to instructions, models, source information, or connected actions. Run the broader release set before expanding the audience. Recheck the actual user channel too, because an automated answer test does not prove every part of the user journey works.

For the newer agent experience, Microsoft’s evaluation results documentation↗ (opens in a new tab) is marked preview and describes reviewing conversation results. Confirm current behavior there if your agent uses that experience. Preserve the run details rather than assuming results remain available forever.

Your release record should name the tested version, cases that matter most, unresolved failures, limitations, and reviewer. The Microsoft Copilot agents guide gives broader building examples; the release decision should stay anchored to your own evidence.

How to preserve evaluation lessons with fenbs

1. Create a free account and add the agent project. Use a team kanban board when colleagues need access to the review work.
2. Add a repair task for each distinct failure cause. Put the expected behavior, safe evidence link, proposed fix, and verification steps in the task’s plan.
3. Record reusable findings in Lessons learned and human release choices in Decisions and rules. Leave a missing approval open for the responsible person.
4. Connect a supported assistant using Integrations. Have it read the project context before the next repair and save Where we left off with the next test to run.

fenbs does not run Copilot Studio evaluations or calculate their scores. Use Microsoft’s evaluation tools for execution; fenbs fits the lessons and shared work that need to survive between reviews.

For learning resources, see Copilot Studio training. Find related guidance on reviewing workplace AI in the AI governance hub.