Before Letting an AI Agent Read Your ERP, Translate the Data into Business Language First

Consider a simple inventory example.

An ERP may contain fields such as:

qty_on_hand
forecast_qty
reserved_qty
available_qty

Now ask an AI agent:

“How much stock do we have left for Product A?”

Which number should it use?

A warehouse employee may mean the physical quantity currently on the shelf.

Sales may want the quantity still available to sell after reservations.

Procurement may care about projected stock after incoming purchase orders.

The correct answer depends on who is asking, why they are asking, and what decision they are trying to make.

That is business context.

A database schema alone does not explain it.

This is why modern data platforms increasingly talk about data products, semantic layers, metadata, governance, and business logic—not just tables.

AI agents need context, not simply access.

Many organizations have the same information stored in several places.

Customer Master Data may exist in the ERP, CRM, and a separate spreadsheet maintained by Sales.

Product codes in the POS may not match product codes in the ERP.

A dashboard may calculate sales from a data warehouse while an AI agent queries transactions directly from the ERP.

Before introducing AI, the organization needs a clear answer to a very basic question:

If two systems disagree, which one is correct?

If people inside the company cannot agree on the answer, the AI will not be able to determine it reliably on its own.

Many KPIs share the same name across an organization but are calculated differently.

Examples include:

• Revenue

• Gross Margin

• Active Customer

• Repeat Customer

• On-time Delivery

• Inventory Turnover

• Conversion Rate

Before an AI agent analyzes these metrics, the business should define how each one is calculated.

That includes:

• Which fields are used

• Which filters apply

• What time period is included

• Which records are excluded

• How exceptions are handled

This is where a semantic layer becomes especially important.

A semantic layer allows dashboards, analysts, and AI agents to use the same business definitions rather than recreating their own logic every time a question is asked.

If management sees Revenue of THB 28 million in the dashboard, the AI agent should not answer THB 31.5 million simply because it used a different definition.

A single ERP can contain hundreds or thousands of tables.

Customer connects to Sales Order.

Sales Order connects to Delivery.

Delivery connects to Invoice.

Invoice connects to Payment.

Product connects to Category, Supplier, Bill of Materials, and Inventory Movement.

An AI agent may have access to all these tables and still produce an incorrect result if it does not understand the relationships between them.

Custom modules and custom fields make the problem even more complicated.

A field may have started with one meaning when the ERP was implemented and slowly evolved into something else after years of process changes.

Sometimes the real business rule exists only in the heads of experienced employees.

Anyone who has worked on ERP implementations will recognize this problem.

AI cannot automatically turn bad operational data into good business data.

If the same customer exists as three separate records,

if product codes are inconsistent,

if purchasing uses boxes while sales uses pieces and the conversion logic is unreliable,

or if one branch updates data in real time while another updates only once per day,

the AI agent will inherit those inconsistencies.

There is another problem: AI is very good at communicating.

An incorrect Excel report often looks obviously suspicious.

An incorrect AI answer can sound polished, confident, and completely reasonable.

That can make poor data even more dangerous.

Once AI agents begin working on behalf of users, access control becomes much more important.

Should a Sales agent be able to see product cost?

Should an inventory agent have access to personally identifiable customer information?

Should an agent working for one branch be able to query data from every branch?

And who has the authority to decide that the definition of “sales” has changed?

Data Owners therefore have a broader role in an AI environment.

They are responsible not only for data quality but also for business meaning, appropriate use, and access rules.

There is another issue organizations should prepare for.

AI agents can query data much more frequently than people.

A human may open a dashboard a few times per day.

An agent may execute several queries to complete a single workflow.

When an organization runs dozens of agents, query volume can increase rapidly.

This affects:

• Performance

• Cloud cost

• Database load

• Data access controls

• Monitoring

• Governance

That is another reason why allowing every agent to query raw ERP tables directly is rarely a good long-term architecture.

A structured data layer makes it easier to manage both meaning and workload.

Data Story starts with Data Discovery to understand where information lives, how it is used, how reliable it is, and who owns it.

The next stage is Data Preparation—organizing, cleaning, connecting, and defining the information so it is ready for business use.

Prepared data can then be connected to Google Looker, giving executives and Key Users a visible and testable view of the information before AI is introduced.

Once the data foundation becomes reliable, the organization can move into AI Development, starting with use cases where the required data is available and the outcome can be measured.

Data Story works alongside client Key Users through an AI Activation Team to validate workflows, test data accuracy, measure business impact, and establish practical operating rules.

As successful use cases move into regular operations, Key Users can become Internal AI Champions, helping the organization maintain and expand AI adoption internally.

The overall path looks like this:

Data Discovery → Data Preparation → Business Definition → Looker / Data Visibility → AI Development → AI Activation Team → Internal AI Champions

AI is not the starting point.

It builds on a data foundation that the organization already understands and trusts.

Can an AI agent connect directly to an ERP system?

Yes. Technically, an AI agent can connect through databases, APIs, data warehouses, MCP, or other integration methods. However, connectivity alone does not give the agent a reliable understanding of business definitions or operational context.

What is business context for AI?

Business context is the information that explains what data actually means inside an organization. It includes KPI definitions, source-of-truth rules, data relationships, business logic, ownership, permissions, and exceptions.

Why is a semantic layer important for AI agents?

A semantic layer provides consistent business definitions so dashboards, analysts, applications, and AI agents can interpret metrics in the same way. It reduces the risk of different systems calculating the same KPI with different logic.

What is the difference between raw data and a data product?

Raw data is information generated by source systems. A data product is data that has been prepared for a defined purpose, including structure, metadata, business definitions, quality controls, ownership, and governance.

Does an organization need to replace its ERP before adopting AI?

Usually not. A better starting point is to assess the existing data, select a focused use case, identify the source of truth, define the business logic, and create a reliable data layer that the AI agent can use.

How does Data Story help prepare business data for AI?

Data Story starts with Data Discovery and Data Preparation, then connects prepared information to Google Looker for visibility and validation. From there, AI use cases are developed together with client Key Users through an AI Activation Team, with Internal AI Champions supporting continued adoption inside the organization.