AI agent connected to ERP – what it really does, where it breaks and what messy data costs

A conversation about an AI agent in ERP only becomes concrete once someone asks about the scope of permissions. The question is not „do we connect an agent to ERP”, but what exactly it is allowed to do with a record. Three levels – read, propose, write – are three different projects under one name.

Level one is read. The agent queries ERP and answers in sentences instead of tables: what is the status of an order, how much stock is left, when the last invoice was issued to this customer. Risk is limited to exposing data to someone who should not see it – so the permissions layer matters here, not business logic. This is the cheapest and fastest starting variant.

Level two is propose. The agent prepares a document but does not confirm it: a draft order, a draft correction, a preliminary match of payments to invoices. A human sees the finished record, checks it and approves with one click. This level usually delivers the best ratio of effect to risk, because it removes 60–80% of the work while keeping control over every write.

Level three is write. The agent changes system state on its own – creates a counterparty, changes an order status, generates a warehouse document. This is where integration ends and an engineering project begins: you need limits, pre-write validation, an operation log, a rollback path and a regression test for every change to the source system's API. Most deployments that cause trouble jumped from level one straight to level three, skipping level two.

First: taking in customer orders. An order arrives by email, in a PDF or in a spreadsheet – a different format every time. The agent reads the document, matches line items to codes in ERP, flags whatever it cannot match unambiguously, and produces a draft order. The salesperson approves instead of retyping. The biggest saving comes not from typing but from searching for the right item code.

Second: statuses and dates. Questions like „what is happening with the delivery for customer X” consume tens of minutes a day per person in trading and manufacturing companies, because answering means checking two or three systems. A read-only agent answers in one place and cites the source of every number. This is the simplest starting variant with an immediately visible effect.

Third: consistency checks between records. The agent compares data across systems and reports mismatches: a counterparty with a different tax ID in CRM and ERP, an order with no cost assigned, a delivery with no warehouse document. Published market examples show account reconciliation shrinking from several days of work to hours. Here the agent does not write – it only points to where a human should look.

Fourth: matching payments to documents. A classic process in which rules cover 70–80% of cases and the rest needs judgement. The agent handles the rest: reads the transfer description, recognizes an abbreviated company name, spots a single payment covering several invoices, and proposes an allocation for approval.

Fifth: preparing data for a sales conversation. The agent pulls purchase history, open orders, overdue receivables and recent complaints into a single note before a meeting. It changes nothing in the system and saves a salesperson fifteen minutes before every visit.

The most dangerous fault of an agent in ERP does not look like a fault. The agent neither refuses to answer nor invents a non-existent customer – it returns a number that is computed correctly, just from a different definition than the one the person had in mind. „How many active customers do we have” has three answers if the system holds three status fields: a flag on the record, the absence of an end-of-cooperation date, and a purchase within the last twelve months. The model picks one and never signals that a choice was made at all.

The second form of the same problem is non-standardized coding. If the same product exists under three item codes because three people entered it over the years, an agent matching order lines will generate documents against the wrong code. The difference from a human error is that a human errs once, while an agent repeats the same pattern across the entire volume – hundreds of documents before anyone notices.

The third form concerns free-text fields. Order notes, call summaries, complaint comments – often the only place where a commercial arrangement was recorded, and simultaneously the field with no formatting discipline whatsoever. An agent reading such a column can extract a conclusion that was true two years ago.

The practical conclusion for planning: before you start comparing vendors and models, check how many unambiguous definitions exist for the five concepts the agent will use most often. That is a one-day task for someone who knows the data, and the best-spent day in the whole project.

A data audit sounds like a separate consulting engagement; in practice, for a mid-sized company it is three to ten days of work and four questions asked of every area the agent will touch.

Question one – definitions. For every concept the agent will use (active customer, completed order, available stock, overdue receivable) you write down one binding definition and point to the field it must be computed from. If an area cannot name one, that is a project decision rather than a technical one, and the process owner has to make it.

Question two – completeness. What share of records have the fields populated that the agent will rely on? A customer file where 30% of entries have no industry assigned is unfit for segmentation, however good the model is. This measurement is a simple query and immediately makes the first-stage scope realistic.

Question three – duplicates and coding. How many counterparties appear more than once, how many item codes describe the same product, whether units of measure are consistent. Question four – permissions. Who is allowed to see the data the agent will return, and whether the permission model can be reproduced in the agent layer. That last one surprises people: many ERP systems enforce permissions in screens rather than in data, so an agent reading straight from the database bypasses them entirely.

An agent with write access needs three mechanisms that a classic integration never required, because an integration does exactly what it was programmed to do while an agent makes a decision.

The first is a volume and value limit. The agent may issue twenty documents an hour, not two thousand, and may not independently confirm an operation above a threshold the company sets. A limit is not a statement of distrust in the model – it reflects the fact that every system errs in series, and a limit turns a series into a single incident you can fix.

The second is logging and a rollback path. Every agent operation must be marked in the system as performed by an agent, with a record of the basis on which it was taken. Without that you can neither reconstruct the cause of an error, nor reverse a series of documents, nor answer an auditor asking who approved the write.

The third is a written split of responsibility between human and agent. According to Capgemini Research Institute research, only 48% of organizations have one – and it is exactly the document whose absence surfaces at the first serious error, when it turns out nobody can say who was supposed to check. One page with the decision split, thresholds and a named owner of the results review is enough.

The ranges below reflect published rates for the Polish market and line up with what we see in our own estimates. The core observation: price is driven neither by the model nor by user count, but by how many systems the agent talks to and whether it is allowed to write in them.

Running cost matters more here than in a classic IT project, because an agent lives at the seam between systems that change independently of it. An ERP API change after an upgrade, a new field on a record, a revised permission scheme – each requires work on the connector and a pass through regression tests. Companies that budget for implementation but not for upkeep end the year with an agent that has quietly stopped handling part of its cases.

It is also worth separating two items often lumped together: model cost and integration cost. In a typical operational deployment, the cost of model calls is a smaller line than connector maintenance and monitoring. It does grow quickly on poor design decisions, though – over-long instructions, retrieving a dozen documents for every query, or using the most expensive model for a classification the simplest one would handle.