Why did my ERP agent report success when the write…

Why did my ERP agent report success when the write actually failed?

Because two specific things happened, both of them documented, and both of them sitting in the starter instruction block Microsoft publishes for the Dynamics 365 ERP (enterprise resource planning) MCP (Model Context Protocol — the open standard an agent uses to call tools in another system) server [GA], generally available since 27 January 2026.

They are the two failure modes that separate an agent that demos well from an agent you can run a business on.

6 minute read.

Trap one: the row cap that truncates without saying so

Microsoft's published agent instructions state: "A tool call response can include up to 25 rows of data as form state." (build-agent-mcp)

Ask for more and you get 25. Microsoft documents no error and no partial-result marker on the payload — the mitigation it does publish is an instruction to the agent, below.

Now follow that through a real sequence. The agent filters a grid for open lines matching some condition, gets 25 rows back, and reasons over them as though they are the answer. If the real count was 25, it is correct. If the real count was 200, it has just given you a confident summary of the first eighth of your data.

Microsoft's own mitigation is an instruction, verbatim: "Generate a warning if the form state contains 25 rows of data." (build-agent-mcp) Microsoft gives no rationale. Ours is that the cap value is the only thing in the response that distinguishes a complete answer from a truncated one.

That is a sound mitigation and it is worth understanding what it is: an instruction to a language model, not a guarantee from a platform. It reduces the failure rate. It does not make the cap go away.

The design consequence is straightforward. Anything where completeness is part of correctness — counting, reconciling, "are there any…", "which ones haven't…" — should not be answered from form state at all. It belongs on the data tools, where you control the query rather than inheriting a view's row budget.

Trap two: the fallback read, and this is the dangerous one

Microsoft's instruction block contains a rule that reads oddly until you understand why it is there. Under Reasoning Instructions, verbatim:

When instructed to create new data, and the creation fails, DO NOT retrieve existing data instead.

(Build an agent with Dynamics 365 ERP MCP)

Microsoft publishes the rule and does not say why. Our reading: the pattern it forbids is a natural thing for a helpful model to do.

The agent tries to create a record. The create fails — a validation error, a missing mandatory field, a posting rule. The agent, trying to be useful, queries for the record.

It finds something similar, perhaps an older record with the same customer and item, perhaps the one it was meant to supersede. And it reports back that the task is done, with details, in the same confident tone it would use if it had worked.

Nothing in that sequence is a malfunction. Every individual step is a reasonable thing for a helpful assistant to do. The output is a false success report with plausible supporting evidence, which is the worst possible failure shape for a system of record — worse than an error, because an error gets handled and this gets filed.

Why this happens, and why it is not really a model defect

Our reading of why: a model has no built-in distinction between evidence that my action succeeded and data that looks like what my action would have produced. Both arrive as tool results. Both are text. Absent an instruction, using the second as the first is a small and very human inferential leap.

Which is exactly why the instruction exists, and why reading Microsoft's published instruction block properly is not optional busywork. It is a list of failure modes someone already found.

The rest of that block, and what each rule prevents

The whole thing repays a slow read. These are the load-bearing rules and the failure each one closes. Two acronyms carry most of them: CRUD (create, read, update, delete — the four basic data operations) and OData (Open Data Protocol — the web query syntax Dynamics 365 exposes its data entities through).

Prefer data tools over form tools for CRUD — More tool calls and worse performance — Microsoft: data tools give "better performance and requires fewer tool calls" than form tools
Get entity types and schema before using CRUD data tools, unless the task instructions say otherwise — The agent guessing entity names that do not exist
Use plural entity names in the OData path, pluralising before the version suffix — The wrong path. Microsoft's worked example is SalesOrderHeadersV2
Deep inserts are not supported — Creating a parent and its children in one call. Microsoft's data_create_entities description: "Deep inserts aren't supported for create"
Never ask the user for a menu item type — A dead-end dialogue, because discovery already groups them
Use names, not labels, for menu items, columns, controls and tabs — Breakage the moment someone uses a different language
Warn when 25 rows come back as form state — Silent truncation read as a complete answer
Do not fall back to retrieving existing data when creation fails — False success reports

The last two are the ones that decide whether this thing is production-grade.

There is one more limit worth carrying alongside them. Microsoft's known limitation 8, verbatim:

Advanced filters: The MCP server doesn't support advanced filters on grids. For example, it doesn't support the "before," "after," and "between" operators for date columns. It supports only the "matches" operator for filtering.

(Use Model Context Protocol for finance and operations apps)

And there is a documented exception, easy to miss because it sits on a different page. The starter instruction block, under Form Tool Parameter Filling Instructions, states that (lessThanDate(x:int)) "is a valid value for a grid date column filter." (build-agent-mcp)

So a single-bound date comparison on a grid is published and supported. A two-sided range is not: there is no "between" operator, so a real date-range question still goes to the data tools.

The counter-argument

"Microsoft is moving optimal tool sequencing into the server. Server-side path optimisation will take care of this class of problem."

Partly true, and worth designing for. Boost agent performance with optimal tool execution paths in Dynamics 365 ERP MCP [PLAN] sits in the 2026 release wave 1 plan with a public preview date of Jun 2026 and general availability Oct 2026 — and as of Microsoft's 28 July 2026 update to that plan, neither date carries the released check mark.

The problem it targets is real, in Microsoft's words: "large language models often have multiple options for tool-calling sequences to perform an operation or retrieve data. The orchestration can select the tool execution sequence and can include more tool calls than are required."

Microsoft states the enhancement "improves performance and accuracy of tool calls." That is stated intent for a feature whose own plan page carries the notice that "Some of the functionality described in this release plan has not been released." Expect hand-tuned prompt cleverness to be worth less over time. That is a good thing.

But it addresses sequencing, not verification. Choosing a better path to attempt a write does not tell you whether the write landed. The row cap is a response-shape limit, not a routing problem. Neither trap is on the sequencing axis, so neither is fixed by improving it.

What to do this week

Read Microsoft's published agent instructions end to end — not the summary, the block itself. It is one copy-paste code block on a single page, and it is a list of things that have already gone wrong for someone.
Test the row cap deliberately. Point an agent at a grid you know has far more than 25 matching rows and ask it a counting question. Whatever it answers is your calibration.
Test the false-success path deliberately. Ask for a record you know will fail validation and read the response carefully. If it tells you the task succeeded, you have found your most important design requirement before it found you.

Where we would draw the line

We would not put an agent write path into production without an independent confirmation step — the verification has to come from a different call than the one that attempted the write, because an agent's own account of what it did is exactly the thing under question.

We would not answer a completeness question from form state, whatever the row count looked like on the day.

And we would not treat an instruction block as a control: instructions shape behaviour and they are not a guarantee, so anything that must not happen belongs behind an approval gate, not behind a sentence in a prompt.

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/

Both traps in this article are worth testing before go-live rather than after. If you want the test cases walked through against your own agent, we will do it on a call. https://cognilium.ai

Why did my ERP agent report success when the write actually failed?