TL;DR
Most of the cases that look like agent problems are not. The tests worth running before committing, and the cheaper mechanisms that usually win.
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.
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 · fetched and read in full 2026-09-15 · public preview 6 February 2026, general availability October 2026
- Configure Business Central MCP Server · fetched and read in full 2026-09-15 · Last updated on 2026-05-03
- Payables Agent Overview — Business Central · fetched and read in full 2026-09-15
- Sales Order Agent overview — Business Central · fetched and read in full 2026-09-15 · Last updated on 2026-07-23
Sources and fact-check
| # | § | Claim | Tier | Primary source | Verdict |
|---|---|---|---|---|---|
| 1 | 1 | "Business Central agentic strategy intentionally separates deep, well controlled, in-context and transparent execution within the product from cross-system orchestration" | T1 — verbatim | Release plan | PASS — the spine of the article, and unpublished by us until now |
| 2 | 1 | "form the foundational layer inside the product"; "in the future will be possible to surface as MCP tools and consume by Declarative Agents in Microsoft Copilot Studio and Microsoft 365" | T1 — verbatim ×2 | Release plan | PASS |
| 3 | 1 | The tense flag — in the future is roadmap, not shipped | T2 — ours, and the article says so in its own voice | — | PASS — this is the §0 tense rule applied, not an inference about the product |
| 4 | 1 | "Business Central business processes are inherently multistep, stateful, and financially consequential" | T1 — verbatim | Release plan | PASS |
| 5 | 2 | "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)" | T1 — verbatim, parenthesis included | Release plan | PASS |
| 6 | 2 | "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" | T1 — verbatim | Release plan | PASS |
| 7 | 3 | "helps ensure that sensitive operations always require explicit user review and consent" | T1 — verbatim | Release plan | PASS |
| 8 | 3 | "The agent always involves designated Business Central users to review and approve all outgoing messages before it sends them to customers" | T1 — verbatim | sales-order-agent | PASS |
| 9 | 3 | An agent relocates the bottleneck to the reviewer | T2 — ours. A consequence of 7 and 8, framed as a question to answer rather than a measured result. We have measured no one's throughput | — | PASS |
| 10 | 4 | "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" | T1 — verbatim, **currently preserved** | configure-mcp-server | PASS |
| 11 | 4 | "The Payables Agent currently doesn't support the following features: Approval flows, Anomaly detection" | T1 — verbatim from the page's Limitations section, **currently preserved** | payables-agent | PASS |
| 12 | 5 | "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"; "adapt to dynamic business scenarios that can't always be anticipated" | T1 — verbatim ×2 | Release plan | PASS |
| 13 | 5 | Read backward, the same contrast disqualifies | T2 — ours, and labelled as a reading in the body: "Read that forward and it is a recommendation. Read it backward and it is a disqualifier." | — | PASS |
| 14 | 6 | "can also memorize relevant data during execution, use it in subsequent steps, and request additional instructions in natural language when user input is needed"; "provides a timeline view of all agent activities, allowing users to review what happened and why" | T1 — verbatim ×2 | Release plan | PASS |
| 15 | 6 | "the platform already has better answers" for uniform rule-expressible work | T2 — ours, a scoping opinion, and complement-never-compete: it points work back to the platform | — | PASS |
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:
| hit | was | now |
|---|---|---|
| never | "a sentence most people never read" | "Microsoft answers it directly" — we have measured nothing about who reads which Microsoft page |
| never · most | "the most common reason a sound agent disappoints… the constraint was never the drafting" | "This is how a sound agent disappoints… the constraint was not the drafting" — a superlative about deployments we have not seen, plus a universal. The corrected sentence describes one failure mode without ranking it |
| never | "a prototype that will never leave the sandbox" | "a prototype, and it stays one" — an absolute about a hypothetical, softened to a statement about the thing itself |
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.
Share this article
What Microsoft ships, what it does not, and the layer we build where a general assistant runs out.
