--- title: "Agentic ERP for Dynamics 365" canonical_url: "https://cognilium.ai/agentic-erp" slug: "agentic-erp" section: "dynamics-365" page_type: "pillar" date_modified: "2026-10-20" description: "What agentic ERP means in practice: AI agents that read, write and act inside Microsoft Dynamics 365 through its own supported integration surface." publisher: "Cognilium AI" author: "Mudassir Marwat" person_same_as: - "https://www.linkedin.com/in/mudassir-marwat/" - "https://orcid.org/0009-0008-1927-2598" - "https://github.com/mudassirmarwat" - "https://medium.com/@mudassir-marwat" - "https://www.youtube.com/@mudassir-marwat" - "https://dev.to/mudassirmarwat" - "https://hashnode.com/@mudassirmarwat" - "https://huggingface.co/mudassirmarwat" - "https://bsky.app/profile/mudassir-marwat.bsky.social" - "https://substack.com/@mudassirmarwat" - "https://topmate.io/mudassirmarwat" - "https://fueler.io/mudassirmarwat" - "https://www.instagram.com/mudassirmarwat/" - "https://www.facebook.com/mudassir.marwat" - "https://www.reddit.com/user/mudassirmarwat/" - "https://www.f6s.com/member/mudassir-marwat" - "https://cognilium.ai/founder" answers: - "What is agentic ERP?" - "How is agentic ERP different from an ERP copilot?" - "How does an AI agent actually reach Dynamics 365 data?" - "What can an agent read, write and act on inside Dynamics 365?" - "How do you evaluate an agentic ERP build before committing to it?" - "Which ERP decision domains are worth handing to an agent?" entities: - name: "Microsoft Dynamics 365" id: "https://cognilium.ai/#entity-dynamics365" url: "https://www.microsoft.com/en-us/dynamics-365" same_as: - "https://www.wikidata.org/wiki/Q27556059" - "https://en.wikipedia.org/wiki/Microsoft_Dynamics_365" - name: "Microsoft Dynamics 365 Business Central" id: "https://cognilium.ai/#entity-businessCentral" url: "https://www.microsoft.com/en-us/dynamics-365/products/business-central" same_as: - "https://www.wikidata.org/wiki/Q58883729" - name: "Microsoft" id: "https://cognilium.ai/#entity-microsoft" url: "https://www.microsoft.com" same_as: - "https://www.wikidata.org/wiki/Q2283" - "https://en.wikipedia.org/wiki/Microsoft" - name: "Microsoft Azure" id: "https://cognilium.ai/#entity-azure" url: "https://azure.microsoft.com" same_as: - "https://www.wikidata.org/wiki/Q725967" - "https://en.wikipedia.org/wiki/Microsoft_Azure" - name: "Microsoft Power Platform" id: "https://cognilium.ai/#entity-powerPlatform" url: "https://www.microsoft.com/en-us/power-platform" same_as: - "https://www.wikidata.org/wiki/Q106253893" - "https://en.wikipedia.org/wiki/Microsoft_Power_Platform" - name: "Claude" id: "https://cognilium.ai/#entity-claude" url: "https://claude.ai" same_as: - "https://www.wikidata.org/wiki/Q118876059" - "https://en.wikipedia.org/wiki/Claude_(AI)" related: - "https://cognilium.ai/dynamics-365" - "https://cognilium.ai/dynamics-365/optimizers" - "https://cognilium.ai/dynamics-365/built-to-order" - "https://cognilium.ai/dynamics-365/ai-without-lock-in" --- # Agentic ERP for Dynamics 365 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. ## Read, write, act — the three tiers ### Read — 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* ### Write — 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* ### Act — 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* ## Copilot, agent and custom build compared | | 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 | ## How an agent actually reaches ERP data ### 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. ## How to evaluate an agentic ERP build ### 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. ## Decision domains ### 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. *Reads: [object Object],[object Object],[object Object],[object Object]* ### 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. *Reads: [object Object],[object Object]* ### 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. *Reads: [object Object]* ### 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. *Reads: [object Object]* ## Inside your tools. Beyond the ERP. Under your controls. Microsoft built the engine and the road. We build the agents that go where the ready-made ones do not: your process, your channels, your other systems, on the same governed road. ### Inside your tools — The agent comes to your people, not the other way round. Confirmations on a Teams card, notices in Outlook, evidence in SharePoint: designed on Microsoft-documented capabilities, chat demonstrations today. ### Beyond the ERP — Joins the ledger to the documents, emails and systems around it. Reads documents and non-Microsoft systems alongside Dynamics 365 data through governed connectors, under your data policies. ### Under your controls — Same permissions as the user. Approval before action. Read-back after. Microsoft’s security model, which adds no privileges; our agents never post without a yes and always read the record back. ## Doesn’t Microsoft already do this? For a few standard jobs, yes, and we are glad it does. We build on the same foundation, Microsoft’s own ERP MCP server. What no ready-made agent covers is your process: the person in Teams who confirms the delivery, the vendor letter in SharePoint, the approval in Outlook, the system that is not Microsoft. That is where we work, and we keep every action inside Dynamics 365’s own permissions, so your auditors see nothing new. If Microsoft’s agent already does the job, we will tell you. | Dimension | Microsoft ships | Cognilium adds | | --- | --- | --- | | Scope | A few defined jobs: reconciliation exceptions, supplier email follow-up and impact analysis, a supplier portal in preview, finance tasks in Excel and Outlook. | Your customer-specific process: your rules, your approval steps, your channel. | | Where it lives | Microsoft’s own experiences. | Teams, Outlook, SharePoint, your other systems. | | Who it talks to | Internal finance users, and suppliers by email or portal. | Plant and warehouse staff, approvers, carriers, subcontractors and customers, through mediated channels, because none of them is an ERP user. | | Data | Dynamics 365 and the vendor’s email. | Dynamics 365 plus documents, email, Dataverse workflow state and non-Microsoft systems. | | Status | Most first-party agents carry Microsoft’s label “production-ready preview”. | Scoped pilots with an owner, a monitor and a rollback plan, each with a status word. | | Customized environments | Standard scenarios on standard forms and entities. | Customized F&O, custom tables and your own X++ logic registered as action tools, messy legacy data. | ## Questions ### 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. --- Canonical HTML: https://cognilium.ai/agentic-erp