What can Agent Designer build in Business Central, and what still needs a developer?

A consultant builds a working agent in the wizard with no AL code at all. Two published boundaries decide whether it becomes a system: the development toolkit is sandbox-only while the AL SDK reaches production from version 28.1, and nothing triggers a custom agent without developer work.

What can you build without writing code?

An agent that Business Central treats as a user, configured through four decisions.

Microsoft describes the wizard steps directly. You give the agent a Name, Display Name and Initials; then a Profile (role) that "determines what UI elements the agent can see and interact with"; then Permissions, framed as "important for ensuring that the agent operates within the boundaries of your organization's data security policies"; then Instructions, which "serves as the prompt that guides the agent's behavior."

There is a starting template as well as a blank canvas. You choose "Create agent from scratch", or the Sales Validation template, which "provides a starting point with predefined instructions and tasks focused on sales order validation."

Agents start switched off, deliberately:

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

And Microsoft is explicit about who this is for — the release plan names "partner personas like consultants, product owners, and domain experts, as well as developers and even power users." The wizard is not a developer tool with a friendly face. It is aimed at the person who knows the process.

What does the permission model actually give you?

More precision than most people expect, because the agent is a user.

"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 single sentence is the governance story. An agent does not get a special sandbox of its own — it gets permission sets, the same mechanism you already audit.

The profile control goes finer than permission sets do. You build profiles specifically for agents "using page customization properties to control visibility of actions, layouts, views, and operations like insert/delete."

Read the last two words. You can hand an agent a profile that can see a page and cannot delete on it. For anything that reads a record and proposes a correction, that is exactly the shape you want — and it is configuration rather than code.

Two permission sets gate the building itself: AGENT - ADMIN "gives you permission to design agents", and AGENT - DIAGNOSTICS "gives you access to see the execution cost and the serialized page in the agent task log entries."

Diagnostics is the one people skip and then need. Without it you cannot see what the agent actually did, step by step, when it does something surprising.

Where can a custom agent actually run?

This is the boundary that decides whether you are prototyping or deploying, and Microsoft draws it precisely:

"The AI development toolkit is available in sandbox environments only. The Agent SDK for AL is available in sandbox environments and, starting from version 28.1, also in production environments."

Two different things with two different answers. The wizard — the design experience a consultant uses — is a sandbox tool. The AL SDK is the production path, and it opened at 28.1.

So an agent designed in the wizard is a prototype by definition. That is not a criticism; Microsoft calls the experience "a low-risk environment for envisioning and prototyping." It is a statement about what you can promise.

⚠️ The status wording matters and it is not "preview". The page carries "[This article is prerelease documentation and is subject to change.]" and "This is a preview feature" — while the design capability itself is listed in Business Central under Production ready previews. Those are different labels with different commitments, and the release plan gives general availability as October 2026.

What still needs a developer?

Getting it to run when something happens.

"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)."

The built-in agents do not have this problem. Payables and Sales Order watch a mailbox through an internal dispatcher. A custom agent waits to be handed a task.

Microsoft offers a way to test around it in the meantime — 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." Simulating a trigger is a test, not a deployment.

This is the gap between a capability and a system, and it is the single most important thing to establish before promising a custom agent to anyone. It is documented, not discovered — the same boundary appears across all the built-in agents.

Is it worth prototyping now?

Yes, and the reason is that the expensive question is answerable cheaply.

The expensive question in any agent project is not "can it be built" — it is "will the reasoning hold on our actual process." That is exactly what the wizard answers, in a sandbox, with real data copies, in an afternoon. Finding out that an agent cannot reliably follow your rules is worth far more before the AL work than after it.

Four things to establish while prototyping:

1. Does the instruction set hold? Write the rules in natural language and see where the agent improvises.
2. What profile does it actually need? Start with the narrowest and widen only where it fails.
3. Where does it stop and ask? Every halt is a person's time, and that is the real running cost.
4. What would trigger it in production? Answer this before the prototype succeeds, not after.

And a note on timing. General availability is October 2026. If you are writing a statement of work now, use Microsoft's labels rather than rounder ones, and re-read the environment boundary before you commit to where the thing will run.

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 the prototype holds and the trigger is the missing half, that is the part we build. Bring the process and the event that should start it to a 15-minute call.

Sources

• Create and activate an agent (preview) — Business Central · ms.date 2026-05-03 · re-fetched and re-verified 2026-09-15
• Envision and design AI agents in Business Central — release plan · ms.date 2026-06-09