---
title: "When should you not build an ERP agent?"
canonical_url: "https://cognilium.ai/blogs/when-not-to-build-an-erp-agent"
slug: "when-not-to-build-an-erp-agent"
section: "blogs"
date_published: "2026-09-16"
date_modified: "2026-09-16"
word_count: 1336
reading_time_minutes: 6
author: "Mudassir Marwat"
author_identifier: "0009-0008-1927-2598"
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"
entities: []
related:
  - "https://cognilium.ai/blogs/what-is-agentic-erp"
  - "https://cognilium.ai/blogs/what-is-mcp-inside-an-erp"
  - "https://cognilium.ai/blogs/copilot-agent-or-agentic-workflow"
---
# When should you not build an ERP agent?

Most of the cases that look like agent problems are not. The tests worth running before committing, and the cheaper mechanisms that usually win.

## Key takeaways

- Microsoft intentionally separates in-product execution from cross-system orchestration. If your process spans several systems, the Business Central agent layer is not where the orchestration belongs.
- A custom agent has no built-in trigger from email, events or a schedule. Reaching one is developer work through the toolkit's APIs, and Microsoft's documented alternative is explicitly a simulation.
- Human review is designed in, so an agent creates review work. If the reviewer is already the bottleneck, the agent relocates the queue rather than shortening it.
- Reachability comes before capability. Part-subtype API pages are not currently usable as MCP tools, and only top-level API pages can be added.
- If the scenarios can be anticipated at development time, deterministic logic is the fitting choice, not the lesser one — Microsoft's own contrast says so in reverse.

**When the work crosses systems, when nothing can start it, when nobody will review what it produces, or when a deterministic rule would have done the job.** Microsoft draws the first of those boundaries itself: Business Central agents are the in-product layer, and **cross-system orchestration is deliberately somewhere else.**

## Is the work actually inside one system?

**This is the first question, and Microsoft answers it directly.**

> *"Business Central agentic strategy **intentionally separates** deep, well controlled, in-context and transparent execution **within the product** from **cross-system orchestration**."*

**That is an architectural boundary stated as intent, not as a gap.** Business Central agents *"form the foundational layer inside the product"*, and Microsoft describes the layer above it separately — capabilities that *"**in the future** will be possible to surface as MCP tools and consume by Declarative Agents in Microsoft Copilot Studio and Microsoft 365."*

**Note the tense.** *In the future* is a roadmap statement, not a shipped capability, and it should be read as one.

**So the test is simple.** If the process you want to agent-ise begins in one system, does its work in Business Central and ends there, **you are in the layer Microsoft built**. If it starts in a CRM, touches a logistics provider and finishes in a finance system, **the orchestration belongs above Business Central**, and building it as a Business Central agent means fighting the layering.

**Microsoft is also candid about why any of this is hard:**

> *"Business Central business processes are inherently **multistep, stateful, and financially consequential**."*

**That sentence is worth keeping.** It is a vendor describing its own domain as the hardest place to put a probabilistic system — and it is the honest frame for every scoping conversation.

## Is there anything to start it?

**A custom agent you have to launch by hand is a demonstration, not an operation.**

> *"Although the ability to design your own agents is in public preview, **there aren't yet any built-in integrations to automatically trigger these custom agents** based on incoming emails, events, or scheduled recurrences (this can be done by professional developers using the APIs available in the AI Development Toolkit)."*

**Read the parenthesis as a budget line.** The capability exists through the toolkit's APIs, and reaching it is developer work — so if the business case depends on the agent starting by itself and nobody has funded that work, **the case is not yet real.**

**What Microsoft suggests instead is explicitly a simulation**: you can *"simulate these scenarios by including the email header and body in the task message to mimic incoming emails, or by manually triggering the agent to emulate event, UI action, or time-based runs."* **Simulating a trigger proves the reasoning works. It does not prove the process runs.**

## Who is actually going to do the reviewing?

**An agent does not remove the work. It changes who does which part — and it creates review work that did not exist before.**

**Human review is designed in, not bolted on.** The runtime *"helps ensure that **sensitive operations always require explicit user review and consent**"*, and for the agent that emails customers the rule is unconditional: *"The agent **always involves designated Business Central users to review and approve all outgoing messages** before it sends them to customers."*

> ### The question that decides the project  **Who sits in the review queue, and what else were they doing?** An agent that drafts faster than its reviewer approves does not speed the process up. **It relocates the bottleneck and adds a queue.**

**This is how a sound agent disappoints.** The extraction works, the reasoning is defensible, the documents are right — and the throughput does not move, because the constraint was not the drafting. **Measure the reviewer's capacity before you build, not after.**

## Can the agent reach the data at all?

**Some data simply is not exposed the way an agent needs it, and the limit is published.**

> *"API pages of subtype **ListPart** and **CardPart** aren't currently supported as MCP tools. **Only top-level API pages** can be added to MCP Server configurations."*

**If what you need lives on a part, somebody writes a top-level API page first** — which moves the project from configuration into development, and changes who has to be involved and for how long.

**The built-in agents carry published gaps too**, stated plainly rather than hidden: *"The Payables Agent **currently doesn't support** the following features:"* — *"Approval flows"* and *"Anomaly detection"*. **Anomaly detection is on that list**, which is worth knowing before anyone scopes an agent to catch unusual invoices.

**Check reachability before capability.** A brilliant instruction set against data the agent cannot see is a prototype, and it stays one.

## Would a deterministic rule have done the job?

**Microsoft frames the value of agents by contrast, and the contrast cuts both ways:**

> *"**Unlike static workflows or hard-coded AL logic**, agents can interpret high-level business goals expressed in natural language and translate them into actionable steps… They **adapt to dynamic business scenarios that can't always be anticipated** during development."*

**Read that forward and it is a recommendation. Read it backward and it is a disqualifier.** If the goal is not high-level, if it needs no interpretation, and if the scenarios *can* be anticipated at development time, **then static logic is not the inferior option — it is the fitting one.** It is cheaper, it is deterministic, it is testable, and it does not consume credits per step.

**The honest scoping question is not "could an agent do this?"** Almost always, yes. **It is "does this work vary in ways a rule cannot express?"** — and for a great deal of ERP work, the answer is no.

## So when is an agent the right call?

**When the input is unstructured, the path varies, and a person should still sign off.**

That is precisely the shape of the agents Microsoft shipped first — an inbound email of unknown structure, a document to interpret, a path that differs per case, and a review step before anything leaves the building.

**The runtime is built for exactly that.** It *"can also memorize relevant data during execution, use it in subsequent steps, and request additional instructions in natural language when user input is needed"*, and it *"provides a timeline view of all agent activities, allowing users to review what happened and why."*

**Where the work is uniform, high-volume and rule-expressible, the platform already has better answers**, and choosing one of those is not a smaller ambition. **It is the correct engineering decision.**

**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/

**Agentic ERP.** We build turnkey AI optimization apps for Dynamics 365 — sidecar applications that run in your own Azure tenancy and solve the calculations a standard ERP is not built to compute. Built on **Azure OpenAI, Microsoft Fabric and Copilot Studio**. We build these on request, against your data and your environment.

**More on the boundary between what Copilot does and what you build:** [Agentic ERP on Dynamics 365](/erp-ai).

The cheapest agent is the one you decide not to build. If you want that decision made properly against your own process, bring it to a 15-minute call.

## Sources

- [Envision and design AI agents in Business Central — release plan](https://learn.microsoft.com/en-us/dynamics365/release-plan/2025wave2/smb/dynamics365-business-central/envision-prototype-custom-ai-agents-using-agent-designer) · **fetched and read in full 2026-09-15** · public preview 6 February 2026, general availability October 2026
- [Configure Business Central MCP Server](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/ai/configure-mcp-server) · **fetched and read in full 2026-09-15** · *Last updated on 2026-05-03*
- [Payables Agent Overview — Business Central](https://learn.microsoft.com/en-us/dynamics365/business-central/payables-agent) · **fetched and read in full 2026-09-15**
- [Sales Order Agent overview — Business Central](https://learn.microsoft.com/en-us/dynamics365/business-central/sales-order-agent) · **fetched and read in full 2026-09-15** · *Last updated on 2026-07-23*

## Fact-check

**Tier summary:** 11 × T1 (all verbatim), 4 × T2 — **0 × T4.**

> ### ⚠️ Why this article names no competitor and knocks no product  A *when-not-to-build* piece is the easiest place in this cluster to slide into a knock. **It does not.** Every disqualifying condition is either **Microsoft's own published statement about its own product** or **a scoping question we put to the reader.** §6 exists to close the loop honestly: where the work is uniform and rule-expressible, **the article sends the reader back to the platform**, which is the position we hold rather than a concession.

**No unbounded absence claimed.** *"There aren't yet any built-in integrations"* and *"currently doesn't support"* are **Microsoft's sentences with Microsoft's own hedges intact** — *yet* and *currently* are preserved everywhere they appear, in the body and in the lifted blocks.

**🔴 No pricing.** The release plan states that custom agents *"consume Copilot credits as they perform their steps"*; this article refers to credits once, as a per-step cost characteristic of the approach, and **states no rate, pack, total or currency.**

**Status.** The release plan lists **public preview 6 February 2026** and **general availability October 2026**, and carries Microsoft's standard caveat that *"Some of the functionality described in this release plan has not been released."* **The article makes no claim that the design capability is generally available.**

**No figures of ours.** No volume, no accuracy, no throughput, no customer, no result.

**Rule 2b sweep — generated by `_audit/sweep.py`, not typed.** Case-insensitive, whole-word, over the published span (`--- DRAFT ---` → `## Fact-check`, both lifted blocks included): `is not` ×8, `does not` ×5, `always` ×4, `only` ×3, `cannot` ×3, `all` ×3, `no` ×3, `nobody` ×2, `can't` ×2, `aren't` ×2, `nothing` ×1, `every` ×1, `doesn't` ×1. **`description` carries:** `nothing`, `nobody` — swept against the body.

**Three hits were repaired rather than explained**, per Rule 2c. **Two of them are the same defect class** — an unmeasured claim about the world, written as fact:

**That first pair is the class this repo has paid for before** — *"configurable in ways most implementations never use"* was cut from an earlier cluster for exactly the same reason. **The tell is a sentence that sounds like experience and is actually an assumption.**

**Every remaining hit is Microsoft's word or bounded in its own sentence.** *always* appears four times: twice inside Microsoft's verbatim review rules, once inside a Microsoft quotation, and once as *"almost always, yes"* — hedged, and about whether an agent *could* do something rather than whether it should. **`currently` and `yet` are preserved everywhere Microsoft used them**, in the body and in the lifted blocks: *"aren't currently supported"*, *"currently doesn't support"*, *"there aren't yet any built-in integrations"*. **Those hedges are the difference between a limitation and a permanent design**, and this cluster has already lost one of them once.

**`validate-voice` reports four AVOID hits, all `tools`, and both distinct occurrences are Microsoft's MCP term of art** — one inside a verbatim quotation, one in a takeaway naming *MCP tools*. **Two other hits were genuine and were repaired**: *workaround* became *"what Microsoft suggests instead"* (the banned word also reads as a knock, and complement-never-compete binds), and *automated* became *live* in a Common mistake.

## Frequently asked questions

### Is the work actually inside one system?

This is the first question, and Microsoft answers it directly.

### Is there anything to start it?

A custom agent you have to launch by hand is a demonstration, not an operation.

### Who is actually going to do the reviewing?

An agent does not remove the work. It changes who does which part — and it creates review work that did not exist before.

### Can the agent reach the data at all?

Some data simply is not exposed the way an agent needs it, and the limit is published.

### Would a deterministic rule have done the job?

Microsoft frames the value of agents by contrast, and the contrast cuts both ways:

### So when is an agent the right call?

When the input is unstructured, the path varies, and a person should still sign off.

---

Canonical HTML: https://cognilium.ai/blogs/when-not-to-build-an-erp-agent