Copilot Studio Models: How to Choose for Your Agent
Copilot Studio lets you pick the AI model that powers your custom agent. Here's how to evaluate the options against a repeatable task and record the decision.
Updated 4 min read
Copilot Studio lets you choose the AI model that powers your custom copilot or agent. The available options differ in reasoning capability, speed, and the tasks they handle well. The right model depends on what your agent is actually supposed to do. Tools like fenbs keep the test brief, evaluation results, and the reasons behind your final selection, so the decision is documented and available to your team rather than lost in a chat thread.
Microsoft updates the models available in Copilot Studio periodically, and the best choice for your agent may change when new models are added. This guide covers how to evaluate the options systematically rather than just picking the newest or most powerful one.
What Copilot Studio model selection controls
In Copilot Studio, the model selection determines how your custom agent reasons about user inputs and generates responses. Different models vary in how well they handle complex multi-step reasoning, how fast they respond, and how they perform on specific task types like customer support, document analysis, or structured data extraction.
The model choice also affects cost: more capable models typically consume more capacity, which affects billing under Microsoft's Copilot Studio pricing. Check the current capacity and pricing documentation at Microsoft's Copilot Studio site (opens in a new tab) before committing to a model, since these details change with product updates.
How to evaluate model options
The most reliable evaluation method is to run the same set of test inputs through each model and compare the outputs against your criteria. Avoid testing on edge cases only: test on the inputs your agent will handle most often, because that's where the quality difference will matter most in production.
Define what "good" means for your use case before you start testing. For a customer support agent, good might mean: correctly identifies the issue, proposes an accurate resolution, and escalates when it doesn't know. For a document analysis agent, good might mean: correctly extracts specified fields, doesn't fabricate missing values, and handles edge-case formatting. Write those criteria down before you run the first test.
- Prepare 5-10 representative test inputs that cover the most common tasks your agent will handle.
- Run the same inputs through each model option you're considering.
- Score each output against your pre-defined quality criteria.
- Note response time for each model — even small latency differences matter in real-time customer interactions.
- Factor in the capacity cost per interaction so you can estimate the running cost at your expected volume.
Common reasons to use a less powerful model
A more powerful model is not always the right choice. For agents doing well-defined, structured tasks — extracting specific fields from a document, routing a support ticket to the right queue, answering from a fixed knowledge base — a simpler model often performs nearly as well and at lower cost.
Speed is also a factor. If your agent is customer-facing and users expect immediate responses, a faster model that answers in one second may deliver a better experience than a more capable one that takes five seconds, even if the second model's answers are slightly better. Test with actual end users when you can, not just on accuracy metrics.
When to use a more capable model
Complex reasoning tasks benefit from more capable models: agents that need to interpret ambiguous instructions, synthesize information from multiple sources, generate nuanced responses, or handle a wide variety of input types. If your evaluation shows the simpler model making errors on common inputs, that's the signal to move up.
Agents used internally by staff — where errors have visible consequences and the user population is smaller — may also justify higher capacity than a high-volume customer-facing agent where absolute accuracy on every interaction is less critical.
Model selection in other Copilot contexts is covered at /blog/github-copilot-models. For the broader Copilot Studio platform, see /blog/copilot-studio.
Consider your compliance and review requirements as part of the decision. Some organizations require a person to review AI output before it takes effect, regardless of which model produced it. In those environments, build the review step into the workflow first. The model choice then becomes a secondary optimization: which option produces the most accurate drafts within a workflow that already has human oversight at the right points.
Record the model selection and the evaluation behind it
In fenbs, Decisions and rules keeps the model choice, the task type it was evaluated on, the test criteria, the results, and who made the call. When a new model is released and the team needs to revisit the decision, the evaluation framework is already written. Update the decision record when the selection changes rather than losing the history.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
How to do this with fenbs
Use fenbs to document the model evaluation and record the decision. This is most useful when the agent is maintained by a team or when the choice may need to be revisited.
- Create a free account. Add a project for your Copilot Studio agent.
- Write the evaluation brief as a task: the agent's job, the test inputs you'll use, and the criteria for a good response.
- Run the evaluation across the model options and record the results in the task notes.
- Record the final model selection in Decisions and rules: the model chosen, the task type, the result that justified it, and who decided.
- Connect a supported assistant over MCP from Integrations. When the decision needs revisiting after a new model release, the evaluation framework and previous result are already in the project.