Where Microsoft's Copilot stops and purpose-built models start — and why the Dynamics channel's advice always ends at 'use Copilot, carefully'.
Copilot's boundary in Dynamics 365 is not a missing feature list. It is four engineering decisions — scope, data freshness, failure handling and cost — that Microsoft deliberately leaves to you.
Ordered by chapter. Each post stands alone but builds on the one before it.
Form tools in the Dynamics 365 ERP MCP server look like screen automation and are not. They drive the application through server APIs against its view model, with no browser, no screenshots and no pixel coordinates.
No — not through the administration forms. The Dynamics 365 ERP MCP server (generally available 27 January 2026) excludes the security, user, Microsoft Entra application and feature-management forms by name. The role you assign is still yours to scope.
Because it is reading the analytics surface, where Business performance analytics pre-transforms currently run twice daily and the pipeline behind them takes hours more. The rule — if the answer changes within 12 hours, it does not belong on the analytics server, and 12 hours is the floor.
Two documented failure modes make a Dynamics 365 ERP agent lie to you — a row cap on form state whose only mitigation is an instruction, and a fallback pattern where a failed write is reported using data the agent read instead. Both are in Microsoft's own starter instructions.
Your ERP AI budget has three meters, not one — Copilot Credits, invoice capture transactions, and AI Builder credits whose seeded entitlement ends on 1 November 2026. What each one counts, what a credit costs, and where the caps are.
Currently not for the identity itself, when the agent is built in Copilot Studio or reaches the ERP through the Dynamics 365 ERP MCP server. A security role that grants nothing marks the identity as licence-exempt — and every human who chats with that agent still needs their own licence.
Microsoft's documentation says that today, custom connectors, MCP servers and REST API tools added to an agent do not add API permissions to the Entra Agent ID. Control of an MCP-based ERP agent lives in three places, and none of them is the Entra connector-permission view.
Write an X++ class implementing ICustomAPI with the right attributes, wire an action menu item into a security role, and flush the cache. The descriptions you write are not comments — they are the interface the model reasons over.
Microsoft retires the original static Dynamics 365 ERP MCP server on 1 October 2026. Moving to the dynamic server is a rewrite rather than a port, because named business functions are replaced by generic primitives plus instructions.
Five supported paths, one decision tree. Choosing wrongly here is the most expensive mistake in an ERP AI project, and the choice turns on three questions — does it write, is it analytical, and is it entity CRUD.
Two surfaces, two jobs — and one combination that is explicitly unsupported. Adding the ERP MCP server as a tool inside the in-app finance and operations sidecar is not supported today, which decides more architectures than it should.
Microsoft publishes the list of supplier email scenarios the Procurement Agent cannot yet handle, and for a manufacturer the gaps are routine daily traffic — split deliveries, site changes and vendor changes.
Three tool families on the Dynamics 365 ERP MCP server, in the priority order Microsoft publishes: data tools for CRUD, form tools for what the app decides.
Tier 2 or above, or a Unified Developer Environment, and not a Cloud Hosted Environment. Plus three minimum versions and an allow-list your platform needs.
Form state carries at most twenty-five rows, and the warning is an instruction a builder can delete. The cap is on the form path, not the data path.
Microsoft names one recommended model for ERP MCP agents, one fallback and one to avoid. The recommended one is external, so an admin must approve it first.
Copilot inherits your permissions and returns a suggestion. An agent is a user of its own, with its own permission set, working in the background.
MCP publishes ERP data and actions as tools a language model can call, under an identity with its own permissions. What that buys, and what it does not.
Three words used interchangeably that mean three different things in Business Central. The distinction is the permission boundary, not the marketing.
An agent is treated as a user in Business Central, assigned permission sets that control what it can read and do. Here is what that means in practice.
Copilot is included with the licence; custom agents consume Copilot Credits as they run their steps. What Microsoft publishes about the consumption units.
What Microsoft documents the Payables Agent can and cannot do, taken from its own pages, including where a person still has to approve the work.
Agents and the MCP server carry version and environment requirements. Which release you need, and which deployment types are excluded outright.
The Sales Order Agent keys orders from incoming requests. What it reads, what it passes over, and where it stops and hands the work to a person.
The Expense Agent handles expense capture end to end within documented boundaries. What it covers, and the point at which a human stays in the loop.
The shipped agents cover defined ground and no more. Where the documented boundary falls, and what has to be built on the other side of it.
Agent Designer prototypes custom agents without a developer, up to a point. What it covers, and where an AL developer is still required.
A Business Central agent works through the same pages a person uses rather than through an API. Why Microsoft built it that way, and what follows from it.
Most of the cases that look like agent problems are not. The tests worth running before committing, and the cheaper mechanisms that usually win.