Do AI agents in Business Central need a clean data foundation?

Yes, decisively. An AI agent acts on your data. If it is clean, it accelerates reliably. If it is not, it scales your errors, only faster and in higher volume. The data foundation is thus not preparation, but the real point of control on which an agent works viably at all.

Who owns data quality internally is a question of its own: Who is responsible for ERP data quality?

Why does the data foundation decide everything?

An agent does not distinguish between a clean record and one that has grown over the years. It applies its rule to both alike. With clean data that relieves measurably; with unclean data it automates the chaos. So the agent does not improve your data quality, it makes it visible and quickly effective, for better or worse.

The difference from manual work lies in volume and speed. An employee who sees an unusual customer number pauses and asks. An agent does not pause. It processes the transaction by rule, and if the rule rests on wrong data, hundreds of consistently wrong transactions arise instead of one conspicuous case.

That is why the data foundation is not preparation but the actual control layer. Microsoft frames the AI capabilities in Business Central accordingly: they work on the existing company data. The quality of that data remains your responsibility.

Source: Microsoft Learn: Copilot FAQ

Which weaknesses slow an agent down?

Four weaknesses slow things down most often in practice. Duplicates among customers and vendors lead to wrong assignments that an agent does not question. Inconsistent item master data makes quantity and pricing logic unreliable. Repurposed fields, where something other than intended has been maintained for years, are unreadable for an agent. And exceptions without a documented rule mean it applies the standard rule where an exception belonged.

These four can be measured before an agent is set up: duplicate rate, share of complete mandatory fields, share of inactive master records and the age of the last maintenance. Four figures per data object are enough to decide whether the base holds.

What follows is an uncomfortable order: cleanse and define the rules first, then automate. Reversing the order is paid for with a loss of trust in the business, and that costs more than the cleansing would have.

What is the right order?

The right order has three stages, and it cannot be shortened. First the data foundation: name owners per object, define rules, cleanse. Then the processes: decide how a transaction should run in future, rather than automating the grown state. Only then the agent, and on a process with high volume and clear rules.

In terms of time this is more achievable than it sounds. Master-data rules, cleansing and ownership can be settled in weeks to a few months depending on the starting point, and this work runs in parallel with operations. A readiness check shows beforehand where you stand and turns gut feeling into a work list.

Control stays on your side throughout, with Business Central as home. AI works on your data foundation, not in its place, and that distinction decides whether agents relieve you or create risk.