Your ERP records the decision. Agentic ERP makes it.
Agents that read the record, do the work and the judgement, and prepare the change for a person to approve — through Dynamics 365's own supported integration surface.
We don't touch your ERP core. We surround it with intelligence.
Three tiers, one is agentic
- Read
Reporting, restated
- Write
Drafting, with a human gate
- Actagentic
Prepared by the agent, approved by a person
Finance & Operations, Business Central
OData entities, custom services and Business Events.
Dataverse-native, on Power Platform
Runs in your own tenant, not ours.
MCP server, in development
The tool surface an LLM can hold.
A system of record is not a system of decisions
An ERP is very good at the thing it was built for: holding what happened, and enforcing the rules for holding it. Trade agreements, bins, reorder points, purchase agreements — all of it recorded, consistent and auditable.
What it does not do is derive the decision. Master planning is a calculation, not a judgement. The reorder point is a number somebody typed. The discount is a rule somebody wrote, applied the same way to a customer who would have paid full price and one who was about to leave.
The gap, plainly
Every decision the ERP records but does not derive is currently waiting on a person to have time.
Not because anyone chose that. Because the system was designed to store the answer, and somebody has always had to supply it.
Read, write, act — and only one of them is agentic
“AI in your ERP” covers three very different things. The distance between them is the whole buying decision, so it is worth being exact.
It can answer questions about the record
Retrieval over ERP data. The agent finds the order, the item, the agreement, and summarises it. Retrieval is the whole of it, and it is genuinely useful, but nothing in the system changes as a result.
Reporting, restated
It can put a value into a field
The agent drafts a quote line, proposes a reorder point, prepares a note for a vendor record. It writes back only what it created, and anything that moves money or stock is prepared for a person to approve. The integration surface has to be real by this point: an OData entity or a custom service, not a screen-scrape.
Drafting, with a human gate
It can carry a task to the point of approval
Chase the supplier whose date moved and prepare the revised schedule. Assemble the credit hold with the exposure behind it. Build the vendor-order change and show what it costs. The agent does the work and the judgement; a person approves anything that moves money or stock. That boundary is not a limitation we are apologising for — it is the reason an IT director says yes.
Prepared by the agent, approved by a person
| ERP copilot | Agentic layer | Custom build | |
|---|---|---|---|
| What it does | Answers questions about the record | Carries a task to the point of approval | Whatever you specify |
| Output | A summary on screen | A prepared change with the reasoning behind it | Depends |
| Who decides | The person reading it | The agent prepares; a person approves anything moving money or stock | The person who wrote the rules |
| Where it runs | Inside the vendor's product | Your tenant — Dataverse, Power Platform, Azure | Your infrastructure |
| Touches the ERP core | No | No — supported integration surface only | Often yes, and that is the risk |
| Your partner's support model | Unaffected | Unaffected — the seam is documented | Frequently voided |
| Good when | The answer exists and is hard to find | The decision recurs and is bounded | Nothing on the market fits |
| Bad when | You needed something to happen | Nobody can state the limits | You wanted to change it later |
Where the writing goes deeper
Through the surface Microsoft already supports: OData data entities, custom services and Business Events, with an Entra app registration mapped to a Finance & Operations service role. An MCP server sits in front of that as the tool surface an LLM can call — which is why the difficult questions turn out to be about tool design and permissions rather than about the model.
- Which environments run the ERP MCP server
- Does the ERP MCP server truncate results?
- ERP agent permissions are invisible in Entra
- Can an ERP agent escalate its own permissions?
- How should an AI agent read Dynamics data?
- Which model should an ERP agent run on?
- Copilot sidecar vs MCP agent
- Multi-agent architecture patterns
How does an agent actually reach ERP data?
Six decisions, in the order a build meets them. “It connects through APIs” is where the explanation usually ends. The specifics are where the outcome is decided.
- 01
The integration surface, before anything else
Dynamics 365 Finance & Operations exposes OData data entities, custom services and Business Events. Those three are the whole vocabulary an agent has, and the choice between them is the first real design decision: data entities for reads and simple writes, a custom service when the operation is a transaction rather than a row, Business Events when the ERP should tell you something happened rather than be asked. Screen automation is not on this list, and a build that reaches for it has usually skipped this step.
- 02
Identity, and the permission nobody can see
An Entra app registration mapped to a service role in Finance & Operations. The subtlety is that the ERP role, not the Entra app, is what actually bounds the agent — and the two are configured in different places by different people. An agent can hold a narrow Entra scope and a broad ERP role at the same time, and nothing in the Entra blade will say so.
- 03
Tool design — where most of the outcome is decided
An LLM does not call your ERP; it calls tools you define. Whether a tool returns data, fills a form, or performs an action changes what the model can do and what it can get wrong. Too coarse and the agent cannot be steered; too fine and it spends its context assembling a call it should have made in one step. This is the part that reads like plumbing and behaves like architecture.
- 04
MCP as the surface an LLM can hold
A Model Context Protocol server sits between the model and those tools, so the same tool definitions serve any client that speaks the protocol. The practical questions are unglamorous and decisive: which environment it runs against, what it does when a result set is larger than the context window, and whether truncation is visible to the model or silent.
- 05
State, memory and the limits of both
An agent completing a multi-step task needs to know what it already did. That is not the same as a chat history, and treating it as one is how an agent re-sends an order it already sent. What must persist is the decision and its justification, not the transcript.
- 06
Knowing when it failed
The failure mode specific to ERP agents is not an error — it is a confident report of success on a task that did not complete. A tool that returns 200 with an empty body, a write that was silently rejected by a validation rule, a line matched to the wrong item. Verification has to be part of the task, not part of the monitoring.
Where an agent changes the outcome
Not everywhere. These are the places where the decision is frequent enough to matter, bounded enough to delegate, and currently made by somebody reading a screen.
Quoting and RFQ
An inbound request becomes a priced, line-matched quote — and the hard part is not the pricing, it is deciding what a line actually refers to.
Procurement and supply
Chasing a confirmation is a decision problem, not a messaging one: the agent has to know when a date has moved and what that costs downstream.
Pricing and discounting
Dynamics holds trade agreements and price lists. What it does not hold is whether this customer, on this order, should get this discount.
Contract and procurement review
Master agreement review against a playbook — the one place in this family where we ship a product rather than a demo.
How do you evaluate an agentic ERP proposal?
Six questions worth asking whoever is proposing it, including us. If a proposal cannot answer them, that is the answer.
Can somebody state the limits?
Not the goal — the limits. What may the agent change without asking, what must it escalate, and what is it forbidden to touch. If nobody can answer that in a sentence, the build is premature regardless of how good the model is.
Does the decision recur?
A judgement made forty times a week is worth delegating. One made twice a quarter is worth writing down. The frequency, not the difficulty, is what makes an agent pay.
Is the underlying data good enough to carry it?
An agent inherits the quality of the record it reads. If item masters are inconsistent or lead times are stale, the honest recommendation is master data first — and that is a shorter, cheaper engagement.
Does it touch the ERP core?
It should not. Ask exactly which integration points a proposal uses, and whether your implementation partner's support model survives them. A build that needs core modification has moved your risk without telling you.
How will you know it was wrong?
Not whether it errored — whether it was wrong. Ask what the agent does when it cannot match a line, and whether that path was tested as carefully as the happy one.
Who runs it in a year?
Tool definitions, prompts and permissions all drift as the ERP changes. If the answer is a person who has left or a vendor with no handover, the thing works until the first schema change.
What an ERP agent cannot do, and when not to build one
An agent that acts confidently on an ambiguous record is worse than a queue somebody clears on Tuesday. Three conditions have to hold before the tier above “write” is worth reaching for: the decision has to recur, somebody has to be able to state the limits it operates inside, and the data underneath has to be good enough to carry the judgement.
Where those do not hold, the honest recommendation is usually better master data, a tighter rule, or a report nobody has built yet — and we would rather say so than sell the larger thing.
Failure modes, written up
- Why ERP agents report false success
- When AI quote automation is the wrong build
- What Copilot cannot do in Dynamics 365
- Why agents forget
- Multi-agent latency
- What a quoting agent can read and write
On status, in the exact words we use everywhere: Contract Review Copilot is shipped, running for a customer today as Paralegent AI. The Pricing, Pick-Path and Demand & Inventory Optimizers are built, demonstrated on request against your own data. Several domains are built to order. The MCP server and Copilot extension are in development.
The questions that decide it
What is agentic ERP?
An ERP that records decisions, paired with agents that compute them. Traditional ERP is a system of record: it stores what happened and enforces the rules for storing it. An agentic layer derives the decisions the ERP does not — what to reorder, what to quote, which discount to approve — and prepares each one through the platform's supported integration surface, with the reasoning attached. The ERP core is unchanged. Anything that moves money or stock is still approved by a person; what changes is that the analysis is already done when they look at it.
How is agentic ERP different from an ERP copilot?
A copilot answers questions about the record. An agent completes a task in it. The practical test is whether anything is different in the system after the interaction: if the output is a summary, that is retrieval; if the output is a staged change — a customer hold prepared, a vendor order amendment drafted, a delivery date put forward — that is agentic, and on the systems we build a person commits it. Both are useful and they are not the same purchase.
How does an AI agent actually reach Dynamics 365 data?
Through the platform's own supported surface: OData data entities, custom services and Business Events, with an Entra app registration mapped to a Finance and Operations service role. An MCP server sits in front of that as the middleware an LLM can call — which is why the interesting questions are about tool design and permissions rather than about the model.
Where do the apps run?
Inside the customer's own Microsoft tenant. They are Dataverse-native and run on Power Platform, with Azure carrying the model workload, and ship via AppSource where that suits procurement. This is not an “Azure tenancy” — Dataverse and Power Platform are the environment the apps live in, and we do not host customer data in a Cognilium-owned tenant.
Does this replace our Dynamics partner?
No, and the arrangement only works if it does not. The partner who implemented the ERP keeps running it. We do not touch the ERP core; we add a decision layer on top of it, through documented integration points, so the two pieces of work stay separable and the partner's support model stays intact.
Is any of this shipped, or is it a pitch?
Both, and the status words are exact. Contract Review Copilot is SHIPPED — running for a customer today, as Paralegent AI. The Pricing, Pick-Path and Demand & Inventory Optimizers are BUILT, DEMONSTRATED ON REQUEST: the software exists and is shown live against your own data. Several domains are BUILT TO ORDER — we have the engineering and build it for you, and there is no packaged app yet. The MCP server and Copilot extension are IN DEVELOPMENT. We would rather use five precise words than one vague one.
When is an agent the wrong answer?
When the decision is already correct and merely slow, when nobody can state the limits the agent should operate inside, or when the underlying data cannot support the judgement. An agent that acts on an ambiguous line item confidently is worse than a queue a person clears on Tuesday. The writing below goes into each of those failure modes.
Start with one decision
A scoped four-to-six week pilot on one workflow, with one success metric agreed before we begin. If the answer turns out to be better master data rather than an agent, that is a good outcome and a short engagement.