Short answer: "autonomous agent" sounds like a binary property and is actually a scale with five practical positions. The right question is not "is your agent autonomous" but "at which step of this specific process must a person decide, and why there".
Why "full autonomy" is the wrong question
The picture of an agent independently running a section of the ledger is appealing and holds up badly in practice. The reason is not model reliability but the nature of the work.
An agent has no judgement about whether an action is sensible in context. It has a pattern and data. When a long-standing customer with a spotless history suddenly orders five times their usual volume, in the data that looks like demand growth. To a person who knows the market it might look like a warning sign — or like a competitor having closed. The agent cannot distinguish those readings, because neither is in the database.
So the useful framing is different: rather than asking how independent an agent can be in general, break a specific process into steps and decide which need judgement and which only need rules applied. It turns out most steps in any process are the second kind, and those are what gets automated.
Five levels of autonomy
The scale we use on projects. A level is assigned not to an agent overall but to each operation separately — one agent may sit at level 4 for data gathering and level 1 for decisions.
| Level | What the agent does | The person's role | Example |
|---|---|---|---|
| 0 | Reads and analyses only | Decides everything | Receivables analysis |
| 1 | Prepares a draft | Reviews and executes | Reminder text |
| 2 | Creates an unposted document | Reviews and releases | Purchase order |
| 3 | Executes and reports | Can reverse afterwards | Master data updates |
| 4 | Executes without notification | Reviews summaries periodically | Name normalisation |
The key observation: most of the value comes from moving from level 0 to level 1–2, not from pushing toward level 4. The time saving lives in gathering and preparing data, not in the final click. Companies that start with "we want it to run by itself" usually spend the budget on the most expensive and least valuable part of the journey.
Choosing a level for a process
Three questions per operation. They give the level almost unambiguously.
1. What does a mistake cost, and is it recoverable? An unposted document is corrected without trace — an argument for level 2. A posted one needs a reversal that stays in the audit trail. A payment that has gone out comes back through negotiation.
2. How quickly would a mistake be noticed? An error visible in tomorrow's report is safer than one surfacing next quarter. This is the main argument against level 4 for data nobody reviews regularly.
3. Is judgement required here? If the rule can be written down completely, with no "it depends", judgement is not required and the level can go up. If the description contains "usually", "as a rule" or "depending on the customer", it is.
The third question is the most useful in practice. When a process owner cannot state a rule without qualifiers, that is not a reason to demand precision from them — it is a signal that a person genuinely belongs at that step.
Safeguards at each level
The higher the level, the more mechanisms must work independently of whether the agent behaves correctly.
- Levels 0–1: the basics are enough — a separate identity and a read-only permission set. There is effectively no risk.
- Level 2: permissions to create without the right to post. This is the single most important safeguard in the whole scheme: it is a Business Central configuration and does not depend on the agent's behaviour at all.
- Level 3: plus volume limits — no more than N operations per run. Plus notifications. Plus a tested way to reverse.
- Level 4: plus periodic summary review and an automatic stop on anomalous volume. An agent that suddenly updates a thousand records instead of the usual twenty must stop itself.
Common to every level: a step limit, a separate identity per agent for audit, and mandatory testing of what the agent must refuse. The last takes longer than verifying correct behaviour and is what determines production readiness. Detail: AI security in Business Central.
How to raise the level
Not on a schedule, but on accumulated evidence. A pattern that works:
- Run the operation at level 1 or 2.
- For a month, record how much of the prepared work a person discards, and why.
- If rejections are a few percent and all about the same thing, that is either grounds to raise the level or grounds to refine the rule.
- If rejections are frequent and varied, the level must not go up: the agent does not understand the process, and autonomy would only accelerate mistakes.
Step 2 requires that rejections are recorded at all. Build that in from day one — otherwise a month later you will have a feeling that it "seems to work" and no basis for a decision.
What is never handed over
A short, firm list. Not for technical reasons, but because the cost of a rare mistake exceeds the total benefit of every correct run.
- Credit decisions. Limits, extended terms, shipping above a limit.
- Outbound payments. The agent prepares a proposal; a person confirms.
- Pricing and discounts outside policy. Margin is given away one approval at a time.
- Final revenue recognition and period close. This is about accountability, not convenience.
- Customer communication in a conflict. Technically an agent manages; the reputational cost of a mistake is not worth it.
This is not caution for its own sake. These are the places where the arithmetic does not favour automation, and knowing that in advance is cheaper than learning it once.
Frequently asked questions
Can an agent work entirely on its own?
On specific operations, yes — usually where the rule can be written down completely without qualifiers: master data normalisation, field completion, starting approvals. On operations needing commercial judgement, no, and that is a policy choice rather than a technical limit.
What if the agent makes a mistake at a high autonomy level?
That is exactly why levels 3 and 4 require volume limits, notifications and a tested reversal path. An agent that suddenly processes a thousand records instead of the usual twenty must stop itself rather than wait to be noticed.
How do we know a process is ready for a higher level?
By the share of prepared work a person rejects over a month. A few percent, all of the same kind, means you can raise the level or refine the rule. Frequent and varied rejections mean the agent does not understand the process.
Should staff be told that an agent does part of the work?
Yes. They will notice anyway, and they are the first to see when it starts going wrong — but only if they know what to look for. Hidden automation loses the best available feedback.
Can different operations of one agent sit at different levels?
Not only can they, they should. The level belongs to the operation, not the agent. A typical receivables agent runs at level 4 for data gathering and level 1 for anything customer-facing.
How long until a first autonomous process?
A first narrow agent at level 1–2 takes four to eight weeks after discovery. Raising the level happens later in operation, driven by rejection data rather than by a project schedule.