When NOT to use an AI agent in Business Central

The built-in agents are no longer a preview you squint at. The Sales Order Agent and the Payables Agent went GA in November 2025, BC28 added the Expense Agent plus purchase-order matching with confidence-level prioritization, and there’s now an agent task pane sitting in Outlook. Agents are in production, and every partner conversation has converged on the same question: “Can an agent do this part of the process?”

It’s the wrong question. The interesting one — the one that separates a system you’ll still trust in two years from a pile of nondeterminism — is “should it?” And for a large, unglamorous slice of Business Central work, the answer is a flat no.

The thing nobody says at the keynote

An AI agent is a probabilistic actor. You hand it a goal and some context, and it decides what to do. That is genuinely powerful when the input is messy and no rule could ever capture it. It is also, for a deterministic process, a strict downgrade on the three things ERP actually cares about:

• Auditability. When finance asks “why did this posting happen,” a codeunit answers with a diff and a stack of records. An agent answers with a probability. In a regulated, money-moving system, “the model decided” is not an answer you want to give an auditor.
• Cost and latency. A codeunit processes a thousand lines set-based, in milliseconds, for free. An agent reasons per item, costs credits per item, and adds seconds of round-trip. Multiply that by your transaction volume and the “innovation” has a monthly invoice.
• Predictability. The same input through a codeunit produces the same output forever. The same input through an agent produces usually the same output — and the day it doesn’t is the day it touches a posted document you can’t easily unwind.

None of this is an argument against agents. It’s an argument against putting one where a rule already exists and replacing it for the demo.

Two axes decide it

Forget “can it.” Ask two questions about the work: how variable is the input, and how expensive is a wrong action. That’s the whole decision.

The left half of that grid — anything with low input variability — is codeunit territory, full stop. A recurring journal, a pricing rule, a posting-date validation, an approval threshold: these are already expressible as rules, which is exactly why an agent adds nothing but risk and cost. If you can write the rule, write the rule. Reaching for an agent here is theatre.

The right half — genuinely variable, unstructured input — is where agents earn their place. And notice the top-right cell: high variability and high cost of being wrong is not “no agent,” it’s “agent behind a hard human gate.” Which is precisely how Microsoft designed the GA agents: confidence levels, human review, and the new “Created by AI / Modified by AI” indicators so a person can always see what the agent touched. The agents are well-built because they were aimed at the right quadrant. The mistake is ours when we aim them at the left half to look modern.

Where this bites in real BC

A few calls I’d make without hesitation:

• Posting, applying, validating, scheduling → codeunit. The logic is known, the cost of a wrong action is high, the input is structured. An agent is the wrong tool by every axis.
• Turning a messy inbound email into a draft sales order → agent, with the human confirming before anything posts. The input is genuinely unstructured; no rule was ever going to parse “can you bump last month’s order by 20 and ship to the new site.” This is the Sales Order Agent’s actual job, and it’s a good one.
• Categorising unstructured vendor invoices / matching them to POs → agent with confidence gating. High variability, high cost — the top-right cell — so the confidence threshold and human approval aren’t optional polish, they’re the design.
• A “smart” approval that an agent reasons about case by case → almost always no. If the approval can be a rule, it should be a rule; you want that decision auditable and instant, not reasoned.

The heuristic to keep

Here’s the one line to carry out of this:

Use an agent where the work was previously manual because no rule could capture it — not where a rule already exists and you’re replacing it.

Code the predictable core. Reserve agents for the genuinely unstructured edge, and when the cost of a wrong action is high, never let one act without a human gate. That isn’t AI-skepticism; it’s the same instinct that made you put validation in a codeunit instead of trusting the user. The agent is a new, powerful actor on the team. Senior engineers are the ones who know which jobs not to give the new hire — especially the one that’s confident, fast, and occasionally, expensively wrong.