Business Central ships with agents for sales orders, payables, and expenses, but until recently building an agent for your own process meant leaving Business Central for Copilot Studio or Azure AI Foundry. In this webinar, Bert Verbeek (4PS) shows how the new agent playground changes that. Tobias Fenster moderates the session, which runs through what an agent actually is, how to build one in the Business Central UI without writing code, and how to take it into AL once it is ready to ship. The session closes with a live Q&A.
What Separates an Agent from Ordinary Automation
Bert opens by defining what “agent” means in this context. An agent is software that performs tasks on your behalf: it listens to input, takes decisions, acts on data, and can learn from context. Unlike a fixed automation, an agent reasons over rules and logic using an AI model, so its exact path through a process is not scripted in advance. Agents can also collaborate with other agents and can be monitored, reacting automatically as new information arrives.
The Agents Already Shipping in Business Central
Business Central currently ships with three built-in agents:
- Sales order agent — reads an incoming customer email, checks inventory, creates a quote, and replies, without a human touching the process.
- Payables agent — picks up an incoming vendor invoice, captures and imports the data, and posts the invoice.
- Expense agent — the most recently released of the three, handling expense capture and processing.
Until now, these Microsoft-built agents were the only option. Custom agents change that, but they come with constraints: they only run in a sandbox environment (not production) on a recent enough version, and creating one requires the Agent – Admin and Agent – Diagnostics permission sets plus billing set up in the tenant. Microsoft provides a limited amount of free credit; once that runs out, agent execution stalls until a SKU is attached and the tenant starts consuming paid credits.
📖 Docs: Working with playground agents in Business Central (preview) — the official overview of prerequisites, permissions, and billing for custom agents.
Creating Your Own Agent in the UI
Bert switches to Business Central to show the agent list, which now includes an option to create a new agent alongside the built-in sales order and payables agents. A template (Sales Validation) is available as a starting point, or an agent can be built from scratch by configuring:
- Display name, initials, and description — the agent’s identity.
- Role (profile) — determines what the agent sees, the same way a role center determines what a user sees.
- Permissions — scopes what the agent can create or modify, exactly like a real user account.
- Instructions — natural-language guidance for what the agent should do and how.
- Model — left on Auto by default, or pinned to a specific model; Microsoft adds and deprecates models over time.
A built-in test mode lets you step through the agent’s execution before it goes live.
📖 Docs: Create and activate an agent using the agent playground (preview) — step-by-step guidance for the Create agent wizard shown in the demo.
Live Demo: The Inventory Check Agent
To show the framework in action, Bert built a lightweight custom agent: an inventory check agent. The scenario is a customer email asking whether a set of items is in stock. The agent checks the stock level, and if an item is short, it creates a purchase order and drafts a reply to the customer.
Walking through a real run in Business Central: an incoming email requests 4x Berlin Chair Yellow and 3x Conference Bundle 1-6. A notification tells Bert a task needs review; opening it shows the original email and a Continue / Decide later choice. Once approved, the agent searches inventory and finds the Conference Bundle short by 3 units, but the record on hand does not have a vendor number, so it stops and asks for one.
Bert supplies the vendor (Fabrikam) as an instruction back to the agent and continues. Every interaction — the confirmation, the instruction given, who gave it, and when — is logged as part of the task’s audit trail.
The agent then creates the purchase order for the missing quantity and drafts a reply email summarizing what was found. Opening the purchase order shows a note added by the agent flagging that the conference bundle was out of stock and had to be ordered — visible to anyone who opens the document afterward, not hidden in a log somewhere.
Bert reviews and sends the outgoing reply, closing the loop from inbound email to purchase order to customer response, with a human checkpoint at each step that needed one.
Messages as Triggers
Agents can be triggered manually from the agent’s own page (adding a message or running a task directly), but the more common path is programmatic: through AL. Microsoft’s own sales order agent illustrates the pattern — a job queue entry periodically checks a mailbox for unread messages and feeds them to the agent as tasks.
Three codeunits handle this: Agent Task, Agent Task Builder, and Agent Task Message Builder. The task builder initializes and creates the agent task; the message builder constructs the message content, including attachments and an external message ID used to correlate replies. A reply on an existing email thread carries the same conversation ID, so the framework appends a new task message to the existing task instead of starting a new one.
How Agents Really Run: Tasks, Orchestrator, and Asynchronous Execution
Bert sketches the execution model behind the scenes. An external orchestrator, running outside Business Central, continuously polls for tasks that are ready to run. When it finds one, it executes the task’s steps, interacting with the Business Central environment the same way a real user would — opening pages, running searches, invoking actions — and writes results back into the task data.
Because this runs as a session against the environment, multiple tasks can execute in parallel, and execution is asynchronous: the orchestrator picks work up when it is ready rather than blocking on it. AL code can check a task’s status (started, completed, or not) and needs to verify conversation references before appending to an existing task versus creating a new one.
Writing Instructions: Prompt Your Agent Like a Junior Employee
The instructions are, in Bert’s words, the most important part of setting up an agent. They combine a high-level description of the agent’s capabilities and responsibilities, tone and communication guidelines (including an email signature), and step-by-step task instructions.
Looking at the inventory check agent’s instruction file, the steps read almost exactly like onboarding notes for a new employee: open the item list page, search for the requested item by number or description, note the current inventory level, note the reorder point. Because functional consultants already know how to explain a process in Business Central to a new colleague, Bert argues that skill transfers directly to writing good agent instructions.
A few additional mechanisms are available inside instructions:
- Human-in-the-loop triggers — for example, “if items are not found, ask for assistance” causes the agent to pause and request a review, exactly as seen in the demo.
- Memory — the agent remembers actions it performed (not state), but instructions can tell it explicitly to store and later recall a value, such as a vendor invoice number.
- Tools — each page type exposes its own set of tools the agent can call, such as sending a message, searching, selecting a row, or invoking an action.
- Page-specific instructions — conditional instruction blocks scoped to a specific page ID, useful when the general instructions get too long.
Limiting the Agent: Role Center, Page Customization, Permissions
An agent with unrestricted access to Business Central is a liability, so Bert dedicates a section to constraining it. For the inventory check agent, he built a dedicated role center that exposes only the Items and Purchase Orders tiles the agent needs — nothing else is visible to it, including Tell Me search, which agents cannot use at all.
Page customization narrows individual pages further: on the purchase order card, only vendor number, document number, description, quantity, and price remain visible to the agent, reducing the chance it acts on or is confused by irrelevant fields. The same customization mechanism can hide sub-form fields such as location code while keeping quantity visible.
Permissions provide the last layer of control. The agent runs under its own permission set, scoped the same way a restricted user account would be. If an instruction requires an action outside the agent’s normal permissions, the user reviewing the task can grant a one-off elevation, which is combined with the agent’s own permissions just for that action.
Troubleshooting: Consumption, Task Steps, and What the Agent Saw
Business Central tracks agent credit consumption per action, visible on a dedicated inventory/consumption page, which is useful both for monitoring spend during prototyping and for estimating cost per action before shipping an agent to a customer.
Every task is broken down into logged steps. Opening a task shows the full sequence: the input message, any user intervention requested, navigation to the items page, a search invocation, a request for assistance, and so on. Each step can be inspected in detail, including a JSON representation of exactly what the agent saw on a page — not the developer-facing field description, but the actual tooltip text, since that is what the agent reads to understand a field. The same detail view lists which tools the agent had access to on that page.
Bert’s practical takeaway: tooltips and error messages are not just for end users anymore. If a tooltip is unclear or an error message is vague, the agent will misread it, retry, and eventually escalate to the user — so cleaning up UI text and keeping error messages precise directly improves agent reliability.
Building the Agent from AL
Once an agent has been prototyped in the UI, it can be rebuilt in AL for distribution as an extension. Two codeunits matter most: the agent factory, which sets the display name and default profile, and the agent metadata provider interface, where the page ID, instructions, and summary are defined.
Every AL agent needs a setup page using PageType = ConfigurationDialog, with a temporary source table that includes a User Security ID primary key (Bert notes this is required — without it, the page errors). The page follows the same lifecycle as any other configuration dialog: initialize state in OnOpenPage, and persist changes in OnQueryClosePage.
Like any other Copilot capability in Business Central, an AL agent must register its capability, choosing an availability level (early preview, preview, or production) and a billing type. Bert points out the billing type must be set to Custom Billed so consumption is metered correctly against the tenant’s credit bundle or pay-as-you-go plan. Creating the agent instance itself is a matter of calling the create/activate function and setting its instructions, whether hardcoded, delivered with the extension, or pulled from Azure Key Vault.
A KPI page can also be added to surface statistics such as emails received, replies sent, and tasks created — the same kind of “time saved” metrics shown for the built-in sales order and payables agents. As with the setup table, the KPI data table also requires a User Security ID field.
📖 Docs: Coding agents in AL (preview) and Configure agents programmatically (preview) — the AL interfaces, codeunits, and setup page requirements referenced in this section.
📖 Docs: A new Agent template is available via the AL: New Project command in VS Code, giving a ready-made skeleton for a custom agent extension — raised during the Q&A as a shortcut worth knowing about.
AL Agents vs. Copilot Studio
Bert closes the main content with guidance on when to reach for AL instead of Copilot Studio. Copilot Studio integrates well with other Microsoft products, supports advanced dialog management, and is low-code, but it is typically built for one customer at a time and requires exposing APIs out of Business Central. AL agents stay entirely inside Business Central’s existing context: no APIs to expose, full reuse of the functionality already in the app, and the same AppSource distribution and version control workflow used for any other extension. On the roadmap, Bert notes, Copilot agents and AL agents are expected to be able to interact with each other, which isn’t possible yet.
Development considerations he flags for teams building AL agents today: this is prototyping-only functionality restricted to sandbox environments, agents need to be tested against a range of input variance the way any other code would be, and a model change is itself a reason to re-test an agent’s behavior.
Q&A Highlights
A few points raised during the live Q&A are worth calling out:
- Production availability: Microsoft has not published a date for moving custom agents out of sandbox-only preview into production environments.
- Attachments from external sources: the agent playground supports attachments in the task itself, but pulling attachments from email, Azure Blob Storage, SharePoint, or similar requires a custom integration that you build and pass in via the task message builder — there’s no built-in connector for this yet.
- Agent-to-agent calls: one agent cannot currently call another directly; each agent is only aware of its own context. To hand work to a different agent, you create a separate task message for that agent instead.
- Prompt injection: Bert recommends adding explicit security guardrails in an agent’s instructions (for example, rules against modifying prices) and testing specifically for prompt injection. Microsoft applies its own meta-prompt on top of custom instructions, though its exact contents aren’t published.
Further Reading
📖 Blog series: Bert Verbeek has written up this same material in more depth on his own blog, covering the architecture, writing the prompt, limiting the agent, troubleshooting, and creating an agent from code.
This post was drafted with AI assistance based on the webinar transcript and video content.