Why is my ERP agent answering with yesterday's numbers?

Because it is almost certainly reading the analytics surface, where the data is pre-transformed on a published schedule rather than read live. This is not a model failure and no amount of prompt work will fix it. It is a grounding decision, and it was made before anyone wrote a prompt.

Two servers, and they answer different questions

Microsoft ships two Model Context Protocol servers over the ERP, and confusing them is the most consequential architecture mistake available on this stack.

Status — Dynamics 365 ERP MCP server: [GA] since 27 January 2026 — the date is on the release plan, not the product page · ERP Analytics MCP: [PP] since 29 January 2026; the release plan puts general availability at September 2026 [PLAN]
Reads — Dynamics 365 ERP MCP server: Data entities, form view models and X++ action classes, live · ERP Analytics MCP: Business performance analytics dimensional models
Writes — Dynamics 365 ERP MCP server: Yes — data tools create, update and delete; action tools invoke X++ classes · ERP Analytics MCP: No write tool is published
Freshness — Dynamics 365 ERP MCP server: Live · ERP Analytics MCP: Pre-transforms "currently run twice daily (12-hour intervals)" — and the full pipeline can take "4-5 hours or more" on top of that
Tools — Dynamics 365 ERP MCP server: Data, form and action families · ERP Analytics MCP: get-bpa-dataset-schema, execute-dax-query
Security — Dynamics 365 ERP MCP server: The security roles assigned to the agent's identity filter every call — the view model returns only objects those roles reach · ERP Analytics MCP: Row-level security enforced automatically on every DAX query

The analytics server is a good product. It answers analytical questions in natural language over a proper dimensional model, across three value chains — Record-to-Report, Procure-to-Pay and Order-to-Cash — and it enforces row-level security without you wiring anything. It is [PP], so it is pilot-only, and it should not carry a go-live commitment before general availability, which the release plan puts at September 2026.

What it cannot do is tell you what is true right now, because the heavy dimensional transform runs on a cycle and the agent generates its query on top of whatever that cycle last produced.

The rule, in one line

If the answer changes within 12 hours, it does not belong on the analytics server. And 12 hours is the floor, not the ceiling.

That is the whole design principle, and it sorts questions cleanly.

Microsoft schedules the refresh at "12:00 AM and 12:00 PM (Coordinated Universal Time)", and states that "the full pipeline (data sync, transforms, and refresh) can take 4-5 hours or more, depending on your data volume" (technical details).

Add the pipeline to the interval and the number your agent reads can be well over half a day old. Ask in the morning, on a fixed UTC clock, and that is yesterday's number.

The failure this rule prevents is specific and nasty: the agent does not error, hedge or flag staleness. It answers confidently with the last completed refresh, which is worse than refusing, because a wrong answer delivered with confidence gets acted on.

Sorting your questions takes about ten minutes

Can we promise this delivery date? — Which surface owns it: Transactional · Why: Changes with every order and reservation
Is this item available now? — Which surface owns it: Transactional · Why: The canonical wrong-answer question
Which exceptions are open right now? — Which surface owns it: Transactional · Why: Changes continuously through the day
Has this purchase order been confirmed? — Which surface owns it: Transactional · Why: State changes on receipt of one email
Which vendors have the best on-time delivery this quarter? — Which surface owns it: Analytics · Why: A quarter of history does not move in an afternoon
What is our average payment cycle time by vendor? — Which surface owns it: Analytics · Why: Aggregate over a long window
What is inventory turnover by product category? — Which surface owns it: Analytics · Why: Same
Where is our customer concentration risk? — Which surface owns it: Analytics · Why: Structural, slow-moving

The pattern is visible once it is on a page: anything a person would phone someone about goes to the transactional server; anything a person would put in a monthly review goes to analytics.

What to ground an availability agent on instead

If your scenario is "can we promise this?", neither MCP server is the first answer — the Inventory Visibility Add-in [GA] is. Microsoft calls it a "first-party microservice", not an AI feature, and it exists precisely because availability has to be real-time: soft reservations posted from any order channel to prevent overselling, and available-to-promise (a delivery date derived from projected stock) calculated forward, exposed over REST to any caller including non-Microsoft channels.

That makes it the cleanest grounding source for a promise agent. The agent reads availability from Inventory Visibility, then acts through the ERP MCP server. Two surfaces, each doing the thing it was built for.

Microsoft's own combined patterns are the right shape

Rather than choosing one server, Microsoft documents pairing them, and both patterns are worth copying:

Insights to action. Find the problem in analytics — the vendor whose performance has drifted, the category whose turns have collapsed — then act through the transactional server.
Action informed by insights. Start a task in the ERP, then consult analytics to make the decision better. Microsoft's example is "requisition management with vendor performance analysis".

Both work because they use the stale surface for the thing staleness does not damage — pattern and history — and the live surface for the thing it does.

The counter-argument

"Then point everything at the transactional server and stop worrying about it."

Tempting, and wrong for three reasons. Analytical questions over a transactional surface still cost more. Microsoft moved the ERP MCP data tools from OData to SQL in April 2026 because OData had "limitations with data aggregations and query operators, leaving much of the data aggregation to the agent's large language model" (release plan). That is better; it is still not a semantic model.

Second, the dimensional model exists because someone already solved the joins, the conformed dimensions and the measures — throwing that away means rebuilding it inside prompts. Third, row-level security is enforced automatically on the analytics side; on the transactional side you inherit the filtering of the roles assigned to the agent, which is correct but is a different control that you have to reason about separately.

The right answer is not one surface. It is knowing which question is on which, and being able to say so out loud.

What to do this week

List the ten questions your users most want to ask the ERP. Mark each changes within 12 hours or does not. That single column is your agent architecture.
For every agent already running, write down which surface it is grounded on. If any agent answering an operational question is grounded on analytics, that is today's finding.
If availability is in scope at all, check whether the Inventory Visibility Add-in is installed. Grounding a promise agent on anything else is a decision you should be making deliberately, not by default.

Where we would draw the line

We would not ship an availability or promise answer off a pre-transformed surface, whatever the demo looked like — that is the one case where being confidently wrong costs a customer relationship rather than a report. We would not build a production commitment on the analytics server while it is [PP]; pilot on it, design for it, keep it off the critical path until GA. And we would not build one agent that reads both surfaces without stating in its response which one an answer came from — if the freshness differs, the reader deserves to know which they got.

About Cognilium Cognilium is the AI optimization layer for Dynamics 365 — complementary apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Built on Power Platform, Dataverse and Azure. https://cognilium.ai · https://www.linkedin.com/company/37180269/

Sorting your questions by surface takes ten minutes and decides your architecture. If you want a second pair of eyes on the split, we will do it with you on a call. https://cognilium.ai

Sources

Key takeaways

An agent answering with old numbers is usually grounded on the analytics surface, where data is refreshed on a pre-transform cycle rather than read live. It is a grounding decision, not a model problem.

The rule that sorts it: if the answer changes inside the pre-transform window, it does not belong on the analytics surface — and that window is wider than the refresh interval, because the pipeline that fills it takes hours of its own.

The failure is silent. The agent does not flag staleness or hedge — it answers confidently with the last completed refresh, which can be most of a day behind.

Availability and promise questions belong on Inventory Visibility, a real-time service built for exactly that, with the agent acting through the transactional server afterwards.

Pairing the surfaces beats picking one: find the problem in analytics, act through the ERP.

Common mistakes to avoid

Grounding an "is it available now?" agent on analytics because that is where the data was easiest to reach.

Assuming an agent will tell you its answer is stale. Nothing in the path knows that it is.

Building a production commitment on the analytics server while it is in public preview.

Solving a freshness problem with prompt engineering. No instruction makes a pre-transformed figure current.

Treating the refresh interval as the ceiling on staleness. The pipeline that produces each refresh takes hours of its own, so the data is older than the interval alone suggests.

Why is my ERP agent answering with yesterday's numbers?