TL;DR
A Business Central agent works through the same pages a person uses rather than through an API. Why Microsoft built it that way, and what follows from it.
It opens them. Microsoft's agents start at a Role Center, walk through pages, select actions and enter data the way a person does. They are not calling an endpoint, and because the steps are not hardcoded, an agent reaches custom fields that a conventional integration would need extending to see.
What does an agent actually do, step by step?
Microsoft describes it plainly, and the sentence is worth reading slowly:
"Conceptually, the agent interacts with Business Central features like a Business Central user. The agent gets general instructions in natural language that outline how to handle vendor invoices. It uses UI metadata, like captions, tooltips, and other properties, along with data on Business Central pages and its own instructions, to decide each step needed to finish the task. Starting from the designated Role Center, the agent goes through pages, selects UI actions, and enters data as a user does."
Three things in that paragraph are easy to skim past.
It reads captions and tooltips. The agent is navigating by the same labels a person reads on screen. Your field captions are part of the interface the agent uses — which means a cryptic caption is a worse instruction to an agent than it is to a colleague, because the colleague can ask.
It starts from a Role Center. Not from a table, not from an endpoint — from the same landing page a user gets, which is determined by its profile.
It decides each step. The sequence is not a script. The agent works out what to do next from what it can see.
Why would Microsoft not hardcode the steps?
Because hardcoding is what makes an integration brittle, and they say so:
"This approach lets the agent stay flexible and adaptable because its interaction surface and steps aren't hardcoded. Instead, AI decides them based on the context of each step. This flexibility lets the agent find and interact with relevant custom fields and actions."
### This is the consequence that matters, and it is unusual. An agent inherits your customisations without anyone extending it. If an ISV or a partner added fields to the vendor card, an agent walking that page can see them — because it is reading the page, not a contract that had to list them. A conventional integration behaves the opposite way. A new field is invisible until somebody maps it. The extension work that normally follows a customisation is, for this one path, not required.
The trade is legibility for coverage. An API contract tells you exactly what will be touched. An agent reading pages might touch anything its profile lets it see — which is precisely why the permission design below carries more weight here than in a normal integration.
What happens when something goes wrong mid-task?
It reads the error message and tries again.
"It can also try to automatically fix validation errors by processing displayed error messages and adjusting the input."
That is the same loop a person runs. A validation error appears, you read it, you change the field it complained about. The agent does that from the message text.
And the whole sequence is inspectable. The runtime "provides a timeline view of all agent activities, allowing users to review what happened and why", with "every step taken by an agent… traceable" and operating "strictly within the access boundaries (permissions) assigned during configuration."
So a surprising outcome is not a black box — but you need the diagnostics permission to see the detail, which is a configuration decision people make before they know they need it.
What does driving the UI mean for permissions?
It makes the profile a security boundary rather than a convenience setting.
Start from the foundation: "The agent is considered as a user in Business Central, so it can be assigned permission sets to control what data and actions it can access."
Then add the profile, which for an agent is doing something a profile does not normally do. You can build one "using page customization properties to control visibility of actions, layouts, views, and operations like insert/delete."
For a human, hiding an action is tidiness. For an agent, it is the control surface. An agent decides its next step from what it can see — so removing an action from the profile does not just declutter the page, it removes that step from the agent's option set.
Three practical consequences:
- Design the profile before the instructions. What the agent can see bounds what it can be told to do.
- Narrow first. It is a profile change, not a code change, so widening later is cheap and starting wide is not.
- Audit it the way you audit a user, because that is what it is.
The same principle runs through every agent on the platform — the built-in ones stop at the same boundary for the same reason.
When is driving the UI the wrong shape?
Three cases, and being honest about them is what makes the rest credible.
When you need a guarantee about what was touched. A page-walking agent's surface is what its profile exposes. If a control requires proof that only specific fields can ever change, a contract-bound integration states that in a way a profile does not.
When volume is the point. Walking pages is how a person works, and it carries a person's shape of cost — one document at a time. For bulk movement of records, the established integration paths exist and are better suited.
When the process has no UI. An agent navigates what a user could navigate. A step with no page is a step the agent cannot reach, and that is developer work against the AL surface rather than a configuration problem — which is the same boundary the design experience runs into.
None of that makes the approach wrong. It makes it a specific tool: good where the work is document-shaped, judgement-heavy and irregular, and poorly matched to high-volume, contract-bound movement. Most ERP work that people want an agent for is the first kind.
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.
If you are deciding between an agent and an integration for the same process, the answer usually turns on whether the work is document-shaped or bulk. Bring the process to a 15-minute call.
Sources
- Payables Agent Overview — Business Central ·
ms.date2026-05-03, updated 2026-07-08 - Create and activate an agent (preview) — Business Central ·
ms.date2026-05-03 · re-verified 2026-09-15
Sources and fact-check
| # | § | Claim | Tier | Primary source | Verdict |
|---|---|---|---|---|---|
| 1 | 1 | The full "like a Business Central user" paragraph — UI metadata, Role Center, selects actions, enters data | T1 — verbatim, long quotation | payables-agent, General agent operations | PASS — the article's spine |
| 2 | 1 | "a cryptic caption is a worse instruction to an agent" | T2 — ours, a reading of claim 1 | — | PASS |
| 3 | 2 | "its interaction surface and steps aren't hardcoded"; reaches "custom fields and actions" | T1 — verbatim ×2 | Same page | PASS — load-bearing |
| 4 | 2 | An agent inherits ISV customisations without being extended | T2 — ours, the consequence of claim 3, stated as our reading and not as a Microsoft claim | — | PASS |
| 5 | 2 | A conventional integration needs a new field mapped | T2 — ours, general integration knowledge, no vendor or product named | — | PASS |
| 6 | 3 | "can also try to automatically fix validation errors by processing displayed error messages and adjusting the input" | T1 — verbatim | Same page | PASS |
| 7 | 3 | Timeline view; "every step taken by an agent is traceable"; "strictly within the access boundaries (permissions)" | T1 — verbatim ×3 | Release-plan runtime description, quoted on the agent pages | PASS |
| 8 | 4 | "The agent is considered as a user… assigned permission sets" | T1 — verbatim | ai-development-toolkit-agent-create, re-verified 2026-09-15 | PASS |
| 9 | 4 | Profiles control "visibility of actions, layouts, views, and operations like insert/delete" | T1 — verbatim | Same page | PASS |
| 10 | 4 | "removing an action from the profile… removes that step from the agent's option set" | T2 — ours, reasoned from claims 1 and 9 — the agent decides from what it can see, so hiding an action removes an option | — | PASS — a logical consequence of two quoted facts, not an asserted absence |
| 11 | 5 | The three cases where this is the wrong shape | T2 — ours, engineering judgement, no benchmark, no figure and no competitor named | — | PASS |
| 12 | 5 | "the established integration paths exist and are better suited" for bulk | T2 — ours, deliberately unnamed and unquantified | — | PASS — no product comparison claimed |
Tier summary: 7 × T1 (all verbatim), 5 × T2 — 0 × T4.
🔴 No pricing, per the founder ruling of 2026-09-15. §5 mentions that page-walking "carries a person's shape of cost" — a statement about work pattern, not a rate. No credit figure, no currency and no total appears.
### On claim 10, which is the one a hostile reader would attack We do not say Microsoft documents that hiding an action removes it from the agent's options. Microsoft documents two things: the agent "goes through pages, selects UI actions" and decides "each step needed to finish the task" from what it can see; and profiles control "visibility of actions." The consequence follows from putting those two sentences together, and the fact-check says so. It is not an absence claim — we are not reporting that Microsoft is silent on something. It is an inference from two quoted presences, which is a different and much safer shape.
§5 exists to make the rest credible. An article that only lists advantages of an approach is marketing. The three cases where page-walking is the wrong shape are stated plainly, and none of them is softened.
No figures of ours. No throughput, no accuracy, no customer, no benchmark.
Share this article
What Microsoft ships, what it does not, and the layer we build where a general assistant runs out.
