How to Spot Agent Washing in ERP: Five Questions to Ask Any Vendor Selling an Agent for Dynamics 365

Gartner's press release of 25 June 2025 predicted that more than 40% of agentic AI projects would be cancelled by the end of 2027, and named "agent washing" as one reason: vendors rebranding chatbots, assistants and scripted automation as agents. Sixteen months on, the Dynamics 365 market is full of products with the word agent on them, from Microsoft's own first-party agents to partner listings on Microsoft Marketplace to builds like ours.

In most software, agent washing is hard to test. In an ERP it is not. An ERP agent either reads live records through a governed surface, acts under an identity with defined permissions, and posts a document you can open afterwards, or it does not. Microsoft has published the mechanics for Finance and Supply Chain Management in enough detail that a buyer can check each claim in a sandbox. These are the five questions we would want asked of us, with the page that lets you check the answer.

1. Show me the record it will post, before it posts it

A demonstration that ends with "and then it updates the ERP" is not a demonstration. Ask to see the exact document the agent proposes to create or change, with its lines, before the confirm step, and then ask to open that document in Dynamics 365 afterwards.

Why this is checkable: Microsoft's ERP MCP server exposes three families of tools, data tools that read, form tools that open and drive application forms, and action tools that run a defined operation such as posting. A product that only uses data tools can summarise and advise; it cannot post. A product that posts should be able to show which action it calls and what that action creates. If the vendor cannot name the tool family, the agent is reading, not acting, which is fine as long as it is described that way.

What to listen for: a product receipt number, a credit note number, a journal number, read back from the ERP after the action. Not a chat message saying it is done.

2. Whose identity does it act under, and what can that identity do that I cannot?

Microsoft's design is that an agent reaching Dynamics 365 through the MCP server acts as a signed-in identity, either a user or a system agent identity, and can do no more through MCP than that identity can do in the application. The server adds no privileges. There is a System agent role that gives an agent an identity with no permissions of its own, to which the exact roles the job needs are added, and the Allowed MCP clients page controls which agent platforms may connect at all.

Ask which identity the demonstration ran under, and which security roles it held. Ask what happens when you remove one of those roles. A real agent fails the step that needed it and says so. A product that keeps working either has a service account with more rights than it admits, or is not going through the governed surface.

What to listen for: role names you recognise from your own security configuration, not "it has access to the ERP".

3. What happens when it is wrong?

Every agent is wrong sometimes. The question is what the design does with that. Three specific sub-questions:

• Does anything post without a named person's confirmation? If yes, under what rule, and who signed off that rule?
• Can it post into a closed period, over an outstanding quantity, or against a document that has changed since it read it?
• After it acts, does it read the record back and report what it could not verify?

For the first, the honest answer for most finance and supply-chain actions is "nothing posts without a yes", because that is what an auditor will ask to see. For the third, reading back is the difference between an agent and a script: a script assumes its write succeeded; an agent checks.

A useful variant: ask for the demonstration to be run against a record that has been edited by someone else between the read and the confirm. Watch what the agent does.

4. Where does it live, and who uses it who is not an ERP user?

Most of the people a finance or supply-chain process depends on are not in Dynamics 365. The plant supervisor who knows whether the delivery arrived, the sales rep who wants to know why an order is held, the credit manager who releases it: some are F&O users, most are not. An agent that only works inside the ERP client has solved the easy half.

Ask where the confirmation happens. Teams, Outlook, a SharePoint library, a Power Automate flow, the ERP client itself. Then ask whether that channel is built or on a slide. Vendors, including us, have designs for channels that are not yet built. The slide is fine; the word "live" on the slide is not.

A concrete example from Microsoft's own product: Dynamics 365 Finance holds a sales order on credit hold for one of nine recorded reasons and shows them in the credit management hold list, where a person with the right role releases the order with a release reason and a review date. The ERP has every fact. The rep who phones credit to ask why has none of them. The agent's job is the explanation to the rep and the trace of who released; it is not to release. Any product that releases the hold itself has answered question three as well, badly.

5. What did Microsoft change last, and what did you move?

The ERP MCP server has already had one generation retired. The original Build 2025 server, with thirteen fixed tools on the Dataverse connector framework, carried a retirement date of 1 October 2026 in Microsoft Learn; that date has passed, and Microsoft asked every agent to move to the dynamic server, which replaces fixed tools with data, form and action tools over the whole application. Agent-only security roles for Finance and Supply Chain Management are on the roadmap for preview in October 2026 and general availability in December 2026.

Ask the vendor which server generation their agent is on, what they moved when the first one was retired, and what they will change when agent-only roles arrive. A vendor who has been building on the platform has an answer with dates in it. A vendor who has not will describe their product as independent of all of this, which usually means it is not using the governed surface at all.

Our own answers, with their status words

Fairness requires that we answer the five ourselves.

1. The PO Receipt Chase Agent shows the product receipt it will post, waits for a yes, posts it through an action tool and reads the receipt number back. The Aged GRNI Investigation Agent does the same for a duplicate receipt it proposes to cancel. Both are built and demonstrated on request, on test data in a demonstration environment.
2. Each runs under a security role assigned to it, with no privileges from the MCP server. We have not yet run the limited-user proof on a customer's roles, so we say "works within the signed-in user's permissions", not more.
3. Nothing posts without a named person's confirmation. Neither agent writes to a closed period or beyond the outstanding quantity. Both read back.
4. The Teams confirmation card and the Outlook notice are designed and in build. They are not live. The Credit Hold Agent, our third, is a training build on Microsoft's demo data: it explains the hold and keeps the release behind the credit manager's role. It has not run on a customer's environment.
5. We build on the dynamic server. The static server's retirement date has passed; we track the agent-only roles item and will publish what changes when it ships.

No customer is using any of these in production. We offer a scoped, read-only pilot on your own data first, which is the sixth question a buyer should ask and the one we would rather be asked.