Short answer: an AI agent in Business Central runs a loop — choose a tool, look at the result, decide the next step, repeat until a defined stopping point. Some of those tools write. That loop is the source of both the value and the risk, and the whole project is built around it.
What an AI agent is in an ERP
The word "agent" is used so broadly it has nearly lost meaning. In a Business Central context one definition is useful, and it is technical: an agent receives a goal rather than an instruction, and decides the sequence of steps itself.
Compare two phrasings. "Show overdue invoices above €10,000" has one unambiguous answer and needs executing once. "Deal with overdue debt above €10,000 and prepare reminders" is a goal requiring you to find the invoices, check each customer for an open dispute, look at open orders, group documents by customer and draft text. The number of steps is unknown in advance because it depends on what each step finds.
The first is an assistant's work. The second is an agent's. The difference is not model intelligence but the decision loop that now sits between the system and your data, running without a person.
Agent, assistant and Power Automate
Three technologies often offered as alternatives to each other, covering different problems. The difference is clearest through who decides the sequence.
| Who decides the steps | What it changes | When it fits | |
|---|---|---|---|
| Assistant | No steps, just a query | Nothing | Questions not known in advance |
| Power Automate | You, at design time | What you configured | Fixed, repeatable process |
| AI agent | The system, at run time | Permitted operations | Process with variation |
The practical conclusion matters more than it looks: if your process is genuinely fixed, an agent is the worse answer. It costs more, behaves less predictably and is harder to debug. Agents win only where the sequence depends on what turns up in the data and cannot reasonably be specified in advance.
This is one of the most common reasons we recommend against an agent during discovery. A company describes a process, we ask whether there are exceptions, and it turns out the process is identical 95% of the time. The right answer then is a flow plus human handling of exceptions.
Which actions to trust an agent with
Technically an agent can perform any operation you permit. The question is not capability but what a mistake costs and how quickly it is noticed.
| Action | Cost of a mistake | Sensible control |
|---|---|---|
| Draft a document for review | Wasted minutes | Unattended |
| Create or update a master record | Bad data, visible later | Unattended, logged |
| Create a purchase order | Recoverable while unposted | Review before release |
| Start an approval | Low — a person still approves | Unattended |
| Release or post a document | Reversal, audit trail noise | Person commits |
| Change a credit limit | Direct financial exposure | Person decides, always |
Read the right-hand column as a starting position, not doctrine. A distributor with thousands of small orders and a manufacturer with fifty large ones will draw the line differently, and both will be right. What matters is that the line is drawn deliberately and written down. The worst case is nobody knowing exactly what the agent is permitted to do because it was "configured somehow".
Three layers of constraint
Agent security is layered, and each layer holds independently of the others.
The tool list
The agent can call only operations explicitly built and exposed to it. There is no general write access; there is a list. If "post journal" is not on it, no phrasing produces it. This is the most important and cheapest layer.
The Business Central permission set
The identity the agent runs as is an ordinary Business Central identity. The platform refuses anything outside its rights, exactly as it would for a person. Company scope applies too. Wider context: security, permissions and data residency.
Approval workflows
If a purchase above a threshold requires approval, the agent's request enters the same workflow. It does not bypass it, because the platform enforces it and the agent is just another requester.
What is not in this list: the model's instructions. A prompt defines behaviour under normal conditions and is not a control. An agent talked into attempting something forbidden is stopped by Business Central, and the attempt stays in the log.
Where agents work best
Successful scenarios share one trait: many similar cases with small differences, each requiring you to look in several places.
- Preparing collections work. Find overdue balances, check for disputes, cross-reference open orders, group by customer, draft reminders. A person reviews and sends.
- Processing inbound orders from email. Parse, match lines to items, check prices and availability, create a draft order.
- Reacting to supply delays. Notice a receipt slipping, check which customer orders are exposed, prepare a supplier query and a list for sales.
- Preparing a payment schedule. Collect invoices due, factor in early-payment discounts, match against expected receipts.
- Master data maintenance. Completing contact records, normalising names, finding duplicates.
Note that in four of five cases the output is prepared work rather than a completed action. That is not caution for its own sake: this split gives the best ratio of value to risk on early projects.
Where agents fail
- The process is actually fixed. Then you need a flow, not an agent. The most common cause of failed projects.
- Data is in poor shape. An agent relying on inconsistent dimensions makes decisions on wrong inputs — quickly and at scale.
- Undefined terms. If "active customer" or "overdue" are not written down, the agent will use its own reading.
- Too broad a first scope. Trying to cover a whole process doubles testing and blurs the success criterion.
- No business owner. Someone has to decide what is correct. Without that, the project stops at the first disputed case.
Cost and timelines
Agents start from $6,000, agents around a specific business process from $10,000, after a discovery from $750. Model usage and hosting are separate running costs.
The difference from an assistant is almost entirely testing. Checking that a system answers correctly means comparing its output against figures computed by hand. Checking that a system refuses what it should refuse means inventing the scenarios where it might fail and walking through each. The second takes longer and determines whether this can go to production.
A realistic timeline for a first narrow agent is four to eight weeks after discovery, roughly a third of which is edge-case testing.
How to start
- Describe one process that genuinely has variation. Not "automate finance" but a specific recurring chain.
- Count how often it runs per month and how long it takes. Under ten times a month, an agent will not pay for itself.
- Mark the step after which a person must decide.
- Check whether the data the process depends on is in order.
- Write down the definitions the process uses.
- Build the agent up to the marked step, no further.
- Test separately what it should refuse to do.
- Widen the scope once the first cycle runs without surprises.
Step 7 is skipped most often, and it determines whether the agent is still in production six months later. What this looks like as a service: AI agents for Business Central.
Frequently asked questions
How is an AI agent different from an AI assistant?
An assistant answers questions and changes nothing. An agent receives a goal and decides the sequence of steps to reach it, including steps that write data. Different classes of system with different risk profiles, tested differently.
Can an agent work with no human involvement?
Technically yes, within the permissions granted. In practice most finance processes are configured so the agent prepares and proposes while a person commits. Which steps run unattended is a policy choice per process, not a limit of the technology.
What happens if the agent gets it wrong?
It depends entirely on which actions it can take, which is why the action list is the key design decision. An agent limited to drafting produces a bad draft somebody discards. An agent with posting rights creates an entry that has to be reversed.
Is this the same as Power Automate?
No, though they overlap and often work together. Power Automate runs a flow you defined, with fixed steps in a fixed order. An agent decides which steps to take based on what it finds. If your process is genuinely fixed, a flow is cheaper and more predictable.
How many processes can we hand to an agent?
Start with one. Each subsequent process is significantly cheaper because the integration layer, authentication and logging already exist, but the first scope should be narrow — otherwise testing stretches and the success criterion blurs.
How do we tell what the agent did?
From the Business Central change log, provided the agent has its own identity rather than a shared service account. Decide this at design time: separating several agents' actions under one account after the fact is hard.