Which model should a Dynamics 365 ERP agent run on?

Microsoft names one: Claude Sonnet 4.5. It also names a fallback, and one model to avoid in Copilot Studio specifically — which is unusual, because vendors rarely publish a negative recommendation about a model they ship.

The catch is not technical. The recommended model needs an administrator's approval before anyone can select it.

What does Microsoft actually recommend?

Three positions in one passage, and all three are worth carrying:

"While you can use GPT-4.1 in other clients like Microsoft Visual Studio Code with GitHub Copilot and achieve good results, don't use it as the orchestration model for agents in Copilot Studio. The recommended model for agents using the Dynamics 365 ERP MCP server is Claude Sonnet 4.5. This model provides a better success rate in Copilot Studio over other default models like GPT-4.1. If Claude Sonnet 4.5 isn't available in your environment, use GPT-5 (Chat)."

Note how carefully the GPT-4.1 guidance is scoped. It is not a judgement on the model — Microsoft says it gives "good results" in Visual Studio Code with GitHub Copilot. The warning is about one role in one product: orchestration, in Copilot Studio. Carry that scope or the sentence becomes something Microsoft did not say.

Why does the choice matter this much?

Because orchestration is the job. Microsoft is direct: "This model is the primary model the agent uses for reasoning, orchestration, and responding to prompts and instructions. The model you select for your agent significantly affects the quality of responses in your agent."

On an MCP agent, orchestration means tool selection. The model decides which family to reach for, in what order, and when it has finished — and those decisions are the whole behaviour of the agent. There is no fixed script underneath: the server's "interaction surface and steps aren't hardcoded; instead, AI determines them based on the context of each step."

So a weaker orchestrator does not produce a slightly worse answer. It produces more tool calls, more wrong-family choices, and a different route every run — the routing problem solved badly, repeatedly.

This is also why model choice is a cost variable, not only a quality one.

What is the governance catch?

The recommended model is not a Microsoft-hosted one:

"Claude models are external models not hosted in Azure. Tenant administrators must approve them for use on the tenant."

That is an approval with an owner, a queue and a data-governance conversation attached — not a dropdown a maker changes on a Tuesday. Whether external model hosting is acceptable is a decision the same people make for every other data-residency question, and it does not resolve inside a build sprint.

Two practical consequences follow, and both belong on a plan at kickoff:

• Start the approval before the build, because the fallback is a materially different agent. Building on GPT-5 (Chat) and switching to Sonnet 4.5 later means re-testing the orchestration you tuned.
• Decide the fallback deliberately. Microsoft's "if it isn't available in your environment" covers both "not approved" and "not offered here" — and for a tenant that will never approve external models, GPT-5 (Chat) is not a fallback, it is the design.

Who pays for the orchestration?

Whoever runs it, and the split depends on the client. In Copilot Studio, tool calls "align with the Agent Action feature, which bills at a fixed rate per tool call", and that fixed rate "includes both the LLM cost for orchestration and the execution of the MCP server."

Outside Copilot Studio the two costs separate:

A chattier model costs more in both columns — more tool calls against the execution meter, more tokens against the orchestration one. Which is the practical argument for Microsoft's recommendation, and a better one than the success-rate sentence alone.

The full running-cost picture has more meters than these two.

How current is this guidance?

Check it before you act on it, and here is the specific reason. Microsoft's model guidance sits on the agent-building page, which carried a documentation date of 5 March 2026 when this article was written — while the MCP server's own page was updated in August 2026.

Model line-ups move faster than either page. A named model recommendation is the most perishable thing in this whole subject, and a six-month-old one is a starting point rather than an answer.

So treat the shape of the guidance as durable — pick the recommended orchestration model, have a fallback, get external models approved early — and re-read the page for the names. That is our position, not Microsoft's, and it is the one that survives the next model release.

About Cognilium Cognilium builds AI optimization apps for Microsoft Dynamics 365 — companion apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Dynamics is your system of record. Cognilium is your system of intelligence. https://cognilium.ai · https://www.linkedin.com/company/37180269/

Agentic ERP. We build turnkey AI optimization apps for Dynamics 365 — sidecar applications that run in your own Azure tenancy and solve the calculations a standard ERP is not built to compute. Built on Azure OpenAI, Microsoft Fabric and Copilot Studio. We build these on request, against your data and your environment.

More on the boundary between what Copilot does and what you build: Agentic ERP on Dynamics 365.

If external model approval is going to be the long pole in your agent project, it is worth knowing that in week one rather than week six. Bring your approval process to a 15-minute call.

Sources

• Build an agent with Dynamics 365 ERP MCP
• Use Model Context Protocol for finance and operations apps