AI Agents in Business Central
When Microsoft first introduced Copilot features into Microsoft Dynamics 365 Business Central, many developers saw it as a productivity enhancement layer — smarter suggestions, assisted text generation, improved user experience.
But the introduction of the AI Development Toolkit signals something much bigger.
This is no longer about suggestions.
It is about agents that can act.
From Automation by Code to Automation by Behavior
Traditionally, automation in Business Central meant writing AL code. You subscribed to events, manipulated records, controlled transactions, and enforced business logic. Everything was deterministic and explicitly programmed.
Now imagine a different approach.
Instead of writing a codeunit that posts documents based on predefined logic, you create an agent. You give it instructions such as:
“Review open sales quotes older than 30 days and notify the responsible salesperson if no follow-up activity exists.”
The agent operates like a user. It logs in (as its own identity), reads data it has permissions for, navigates pages, and performs actions.
No event subscriber.
No page extension.
No codeunit trigger.
This shift moves us from “automation by procedure” to “automation by intent.”
Enter the AI Development Toolkit
Microsoft introduced the AI Development Toolkit as a controlled playground where developers can experiment with such agents.
The toolkit is available in Business Central Online, starting from version 27.2, and only in Sandbox environments. It is currently marked as preview. That detail matters.
You cannot use it:
- In Production
- In On-Premises deployments
- Outside Business Central Online
If you run Business Central OnPrem, this capability simply does not exist today.
The fact that it is sandbox-only tells a story: Microsoft wants partners and developers to explore, experiment, and learn — not yet deploy mission-critical agent logic into production systems.
What Actually Happens Behind the Scenes?
An AI agent in Business Central is not a magical background service.
It is created as a separate user with:
- Its own profile
- Its own permission set
- Its own security boundaries
That means something important:
Agents cannot bypass Business Central’s security model.
If the agent does not have permission to read Customer Ledger Entries, it cannot read them. If it cannot post sales documents, it will fail.
In many ways, this is reassuring. The agent operates inside the same guardrails as human users.
From a developer’s perspective, that introduces a new responsibility: permission modeling becomes even more critical. An under-permissioned agent will behave unpredictably. An over-permissioned agent becomes a risk.
Iterating Instead of Coding First
With the toolkit, the workflow changes.
Instead of opening Visual Studio Code and scaffolding an AL extension, you:
- Create an agent in the sandbox.
- Define its instructions in natural language.
- Assign permissions.
- Activate it.
- Observe its behavior.
Then you refine.
Perhaps the instructions are too vague.
Perhaps the agent misinterprets a condition.
Perhaps it needs a narrower permission scope.
You iterate.
This is closer to training than programming.
And that is a fundamental conceptual shift for AL developers.
A Simple Example Scenario
Let’s compare a classic AL approach with an agent-based exploration.
Traditional AL Approach
You might write something like:
codeunit 50100 "Quote Follow-up Check"
{
trigger OnRun()
var
SalesHeader: Record "Sales Header";
begin
SalesHeader.SetRange("Document Type", SalesHeader."Document Type"::Quote);
SalesHeader.SetFilter("Document Date", '..%1', CalcDate('<-30D>', Today));
if SalesHeader.FindSet() then
repeat
// Custom follow-up logic
until SalesHeader.Next() = 0;
end;
}This is precise. Deterministic. Controlled.
Agent-Based Exploration
With an agent, you might instead define:
“Check for open sales quotes older than 30 days and create a reminder task if no interaction log exists.”
You observe how it navigates data. You test edge cases. You refine instructions.
Only once the business behavior is validated do you decide:
- Should this become structured AL logic?
- Should this remain agent-driven?
- Or should it become a hybrid solution?
The toolkit becomes a validation layer before engineering investment.
Why On-Premises Is Not Supported
The absence of On-Prem support is not accidental.
AI agents rely on:
- Cloud-based AI services
- Managed orchestration
- Integration with Microsoft’s cloud infrastructure
On-Prem environments lack that service layer.
This reinforces a broader strategic direction:
advanced AI capabilities in Business Central are cloud-first.
For partners still heavily invested in OnPrem, this is an important signal about long-term roadmap alignment.
What This Means for Developers
For years, Business Central development was centered around:
- AL language mastery
- Event-driven architecture
- Performance tuning
- Upgrade-safe extensions
Now we add something new:
- Prompt engineering
- Behavioral modeling
- Iterative validation
- Security-aware agent design
It does not replace AL.
But it changes how and when we use it.
Instead of immediately coding every requirement, we might prototype behavior with an agent first. We validate business value earlier. We reduce unnecessary engineering effort.
This introduces a new development rhythm.
Is This Production-Ready?
Not yet.
The AI Development Toolkit is:
- Sandbox-only
- Preview
- Subject to change
But that does not make it irrelevant. Quite the opposite.
This is the phase where early adopters gain understanding. By the time production support arrives, those who experimented will already know:
- What works
- What fails
- What is safe
- What is risky
The Bigger Picture
If we zoom out, we can see what is happening.
Business Central is evolving from:
A system where users operate software
To:
A system where software can also operate itself — within controlled boundaries.
AI agents are the first visible step in that direction.
And while today they live only in sandbox environments, they represent something much larger:
the beginning of agent-based ERP.