---
title: "How does a Business Central agent interact with pages instead of an API?"
canonical_url: "https://cognilium.ai/blogs/business-central-agent-drives-the-ui"
slug: "business-central-agent-drives-the-ui"
section: "blogs"
date_published: "2026-09-16"
date_modified: "2026-09-16"
word_count: 1230
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/when-not-to-build-an-erp-agent"
  - "https://cognilium.ai/blogs/what-is-agentic-erp"
  - "https://cognilium.ai/blogs/what-is-mcp-inside-an-erp"
---
# How does a Business Central agent interact with pages instead of an API?

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.

## Key takeaways

- Business Central agents do not call an API. They start at a Role Center, walk pages, select actions and enter data as a user does.
- They navigate by UI metadata — captions, tooltips and page properties. Your field labels are part of the interface an agent reads.
- Because the steps are not hardcoded, an agent reaches custom fields and actions that a conventional integration would need extending to see.
- A validation error is handled the way a person handles one — read the message, adjust the input, try again.
- The profile is the control surface, not a convenience setting. Removing an action removes that step from the agent's options.
- Every step is traceable, but seeing the detail requires the diagnostics permission, which is set before anyone knows they need 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](/blogs/business-central-agent-limitations) 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](/blogs/agent-designer-business-central-limitations).

**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](/erp-ai).

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](https://learn.microsoft.com/en-us/dynamics365/business-central/payables-agent) · `ms.date` 2026-05-03, updated 2026-07-08
- [Create and activate an agent (preview) — Business Central](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/ai/ai-development-toolkit-agent-create) · `ms.date` 2026-05-03 · re-verified 2026-09-15

## Fact-check

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

## Frequently asked questions

### What does an agent actually do, step by step?

Microsoft describes it plainly, and the sentence is worth reading slowly:

### Why would Microsoft not hardcode the steps?

Because hardcoding is what makes an integration brittle, and they say so:

### What happens when something goes wrong mid-task?

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.

### What does driving the UI mean for permissions?

It makes the profile a security boundary rather than a convenience setting.

### When is driving the UI the wrong shape?

Three cases, and being honest about them is what makes the rest credible.

---

Canonical HTML: https://cognilium.ai/blogs/business-central-agent-drives-the-ui