TL;DR
An agent is treated as a user in Business Central, assigned permission sets that control what it can read and do. Here is what that means in practice.
It is a named user that is not a person. It holds permission sets, it is assigned a profile that bounds what it can see, it is told what to do in natural language rather than code, and it arrives switched off. And it cannot hold more permissions than whoever created it.
What is it, plainly?
Microsoft's own sentence is the plainest one available, and it is worth reading twice:
"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."
That is the whole idea. Not a feature bolted onto a page, not a chatbot in a corner — an entry in the system's own model of who does things.
The consequences follow without any further explanation. Something that is a user can be given a role. It can be restricted. Its actions appear in logs attributable to it. It can work when nobody is logged in. A button that summons a suggestion has none of those properties in its own right.
What is an agent actually made of?
Four parts, and you configure all four.
| Part | What it is |
|---|---|
| Identity | A name, display name, initials and description — how it appears to people in the product |
| Permissions | "explicit permission sets that control what data and actions it can access" |
| Profile (role) | "determines which UI elements it can see and interact with" |
| Instructions | "natural language descriptions that define your agent's purpose and behavior" |
Permissions and profile are different boundaries and you need both. Permissions govern data; the profile governs what is on screen. Microsoft is direct about how to set the second one:
"To reduce contextual noise and increase accuracy, it's highly recommended to create custom profiles specifically for agents, using page customization properties to control visibility of actions, layouts, views, and operations like insert/delete."
Note the reason given. Not security — accuracy. A narrower profile makes the agent better at its job, because it reads the screen the way a person does and a cluttered screen is a worse input.
Instructions are prompts, and Microsoft says so: "Think of them as detailed prompts that guide how the agent interprets requests and interacts with the Business Central interface." Which means the skill it takes to configure one is writing, not development — at least until you need a trigger.
What are its limits, as a user?
Four published ones, and the first is the most important thing in this article.
"Permission inheritance: Agents can't have more permissions than their creating user."
So the ceiling is a person. An agent is its own identity, but not an escalation route — whoever creates it caps it. That single line settles the escalation question, and it deserves to be quoted in the meeting rather than paraphrased.
The other three are about what it can perceive:
- What is on screen bounds it: "UI interaction limits: Agents see only what their assigned profile allows."
- One list per page: "Agents can only interact with one list on any given page. If a page has multiple sublists (for example, sales lines and notes in a factbox), the agent can only access one of them."
- No shortcut navigation: "No Tell me: Agents can't use Tell me to find specific information. Navigation is limited to available actions and links."
The middle one catches people designing against document pages, where lines and a factbox sit together and both look equally reachable. They are not.
And Microsoft is explicit that this list belongs to a preview, listed under "Limitations (preview)" for the AI development toolkit — which is "available in sandbox environments only".
How does an agent get started?
By a task somebody creates, and only once it is switched on.
"Tasks are a way to trigger the agent. Tasks can only be added when the agent is active, and they help structure how the agent responds to different types of requests."
And it is not active when you make it. "An agent is by default in the Disabled state. You must activate the agent to use it, but you can only activate it after you have defined its purpose and tasks."
Note what that does not include: anything automatic. A task is created by a person — Microsoft's release plan says "You can invoke your agent by manually creating a task for it" — and there are "there aren't yet any built-in integrations to automatically trigger these custom agents", which is where the developer work starts.
Two small design decisions worth noticing. You cannot switch on an empty agent, and you cannot queue work for one that is off. Both prevent the same failure — a configured-looking agent that silently does nothing, or a backlog accumulating against something nobody enabled.
What is the life cycle Microsoft expects?
Six phases, and the fifth one is the honest part:
- "Create - Set up the agent with basic identity and profile" - "Configure - Define instructions and permissions" - "Activate - Enable the agent for testing, add tasks" - "Iterate - Test, refine instructions, and adjust permissions" - "Graduate - Export learnings to build production solutions using AL extensions" - "Clean up - Deactivate and remove the prototype agent"
Graduate means rewrite. The toolkit produces a prototype, and Microsoft's own path to production is an AL extension — which is development work with a developer's timeline.
Microsoft even publishes when not to use the toolkit, which is unusually direct: "Don't use the AI development toolkit when:" — "Compliance or security evaluation is the primary goal", "Final implementation is ready (graduate to AL extension instead)", "End-user training is the main objective (use production-ready Copilot features)".
Read the first item carefully. The prototyping environment is not where you satisfy a security review — a useful thing to know before scheduling one.
Where does the word "agent" mislead?
It suggests initiative, and the published design suggests something narrower.
An agent here does not decide what to work on. It is given a task, acts within a profile it did not choose, holds permissions capped by its creator, and hands its output to a person. That is closer to a well-supervised new starter than to anything autonomous — and the documentation reads that way throughout.
The useful mental model is a role, not a robot. You would not give a new starter every permission and an unfiltered screen and no review; the agent configuration surface exists because the same reasoning applies. Design it the way you would onboard someone, and most of the choices answer themselves.
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 about to configure one and are unsure how narrow the profile should be, that question is worth fifteen minutes before it is worth a sprint.
Sources
- Designing and coding agents (preview) — Business Central · fetched and read in full 2026-09-15
- Create and activate an agent (preview) — Business Central · fetched and read in full 2026-09-15
- Envision and design AI agents in Business Central — release plan · fetched and read in full 2026-09-15
Sources and fact-check
| # | § | Claim | Tier | Primary source | Verdict |
|---|---|---|---|---|---|
| 1 | 1 | "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" | T1 — verbatim | Agent-create page | PASS |
| 2 | 1 | The consequences of being a user — role, restriction, attributable logs, unattended work | T2 — ours, reasoning from claim 1 | — | PASS |
| 3 | 2 | Identity fields: name, display name, initials, description | T1 — from the wizard steps on the agent-create page | Agent-create page | PASS |
| 4 | 2 | "explicit permission sets that control what data and actions it can access"; profile "determines which UI elements it can see and interact with" | T1 — verbatim ×2 | Toolkit overview | PASS |
| 5 | 2 | "To reduce contextual noise and increase accuracy, it's highly recommended to create custom profiles specifically for agents…" | T1 — verbatim | Toolkit overview | PASS — note the stated reason is accuracy |
| 6 | 2 | Instructions are "natural language descriptions that define your agent's purpose and behavior"; "Think of them as detailed prompts" | T1 — verbatim ×2 | Toolkit overview | PASS |
| 7 | 3 | "Permission inheritance: Agents can't have more permissions than their creating user" | T1 — verbatim | Toolkit overview, Limitations (preview) | PASS — the article's spine |
| 8 | 3 | "UI interaction limits: Agents see only what their assigned profile allows" | T1 — verbatim | Same section | PASS |
| 9 | 3 | "Agents can only interact with one list on any given page… the agent can only access one of them" | T1 — verbatim, including Microsoft's sales-lines-and-factbox example | Same section | PASS |
| 10 | 3 | "No Tell me: Agents can't use Tell me to find specific information. Navigation is limited to available actions and links" | T1 — verbatim | Same section | PASS |
| 11 | 3 | These are preview limitations for a sandbox-only toolkit | T1 — verbatim, scope preserved from the page's own headings | Toolkit overview | PASS |
| 12 | 4 | "Tasks are a way to trigger the agent. Tasks can only be added when the agent is active…" | T1 — verbatim | Toolkit overview | PASS |
| 13 | 4 | "An agent is by default in the Disabled state… only activate it after you have defined its purpose and tasks" | T1 — verbatim | Agent-create page | PASS |
| 14 | 5 | The six-phase life cycle, quoted in full | T1 — verbatim | Toolkit overview | PASS |
| 15 | 5 | The three "Don't use the AI development toolkit when" items | T1 — verbatim | Toolkit overview | PASS |
| 16 | 6 | The word "agent" oversells the initiative involved | T2 — ours, argued from claims 7–13 and written as our reading | — | PASS |
| 17 | 6 | The onboarding analogy | T2 — ours, a mental model offered as one | — | PASS |
Tier summary: 13 × T1 (all verbatim), 4 × T2 — 0 × T4.
### 🔴 Claim 7 sent a correction back into ch17 of this cluster ch17 originally said an agent can be given "less access than you have, or different access" — and different leaves room for more. Microsoft's toolkit page rules that out: "Agents can't have more permissions than their creating user." ch17 was corrected before this article shipped, and the correction is recorded in its own fact-check. The page that settles it was not among the four ch17 first opened — which is the ordinary way this defect enters: not invention, but a page not yet read. Scope, stated plainly: this limitation is listed under Limitations (preview) for the AI development toolkit. It is quoted here with that scope and is not asserted of every agent Microsoft ships.
No unbounded absence claimed. No Tell me, only one list, can't have more permissions are all Microsoft's own sentences about its own product, quoted with their headings intact.
Status labels. Both toolkit pages carry "[This article is prerelease documentation and is subject to change.]" and "This is a preview feature." This article describes a preview capability and says so in §3, rather than presenting the design surface as generally available.
🔴 No pricing. Billing is not discussed. No rate, pack, total or currency.
No figures of ours. No volume, no accuracy, 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): only ×10, cannot ×5, is not ×4, no ×3, can't ×3, nobody ×2, most ×2, nothing ×1, does not ×1, every ×1, all ×1, none ×1. `description` carries: cannot, isn't — swept against the body.
Two hits were repaired rather than explained, per Rule 2c, and the second was a real over-claim:
| hit | was | now |
|---|---|---|
| most | "answers most of the security questions this subject raises" | "settles the escalation question" — narrower, and it is the question that line actually settles |
| none | "None of that is true of a button that summons a suggestion" | "has none of those properties in its own right" — the original was wrong. Copilot is restricted and its actions are logged — as you. What it lacks is a role, a restriction, a log entry and an unattended existence of its own, and that qualifier had to be there |
Every remaining hit is bounded or conditional. most of the choices answer themselves is hedged advice; every permission sits inside a hypothetical about onboarding; both uses of nobody describe states (nobody is logged in, nobody enabled) rather than claims about people.
`validate-voice` reports zero AVOID hits, zero filler, zero hedging.
Share this article
What Microsoft ships, what it does not, and the layer we build where a general assistant runs out.
