ERP in the Agentic Era: How to Prepare
AI agents that autonomously operate ERP systems are real in 2026. This is what your ERP architecture needs to support agents that make decisions on their own.
Companies sitting on years of dirty data in their ERP. The real business cost isn't what you think. Here's how to fix it without blowing up your system.
Abhi Asok
Founder & CEO, Arvension Technologies
A manufacturing company I worked with had been using SAP for eight years. They had everything in SAP: orders, inventory, financials, suppliers. On the surface, the system worked fine. Reports generated. Orders shipped. Money moved.
But when the CFO started asking specific questions—"What's our inventory actually worth?" "Which suppliers are we overpaying?"—the finance team couldn't answer. Not because they didn't know how to run reports. But because the data was wrong.
Inventory showed stock that didn't exist. SKUs were duplicated with inconsistent naming. Supplier data had multiple entries for the same company. Historical costs were all over the place. Eight years of patches, workarounds, and decisions by people who no longer worked there.
The cost of fixing it? Two million dollars over six months. The cost of not fixing it? That's harder to quantify, but also massive: wrong pricing, excess inventory, operational inefficiency, bad decision-making.
This is the story I see repeatedly, and it's almost never about the ERP system itself. It's about data.
How does this happen? I've traced it through dozens of companies, and the pattern is consistent.
It starts innocuously. Someone enters a supplier name as "ABC Manufacturing Co." Later, someone enters the same supplier as "ABC Mfg." Now you have two records. It's fine. The system still works. You have redundancy.
Then a data import happens. Maybe you're integrating with a new warehouse system. The mapping isn't perfect. Some fields don't align. You leave them blank or fill them with defaults. You tell yourself you'll clean it up later. You don't.
Then a process change happens. Accounting switches from tracking cost-per-unit to tracking total cost. The data model doesn't change. People work around it. They add fields. They create workarounds. Each workaround lives forever.
Then someone leaves the company. They took the only copy of the mapping between your old system and your new system. Nobody else understands why certain fields are calculated the way they are. You're afraid to touch anything.
After eight years, you have data that's internally consistent but externally nonsensical. The system works. Reports generate. But the data doesn't represent reality.
Here's what this looks like in practice.
First, operational cost: bad data means inefficient operations. A logistics company has duplicate customer records. They're paying for duplicate memberships. They're sending shipments to multiple addresses. They're generating duplicate invoices. Nobody notices because the amounts are small. But multiply across thousands of records, and it's hundreds of thousands of dollars a year.
Second, decision cost: leaders make decisions based on reports that are subtly wrong. A retailer analyzes their slow-moving inventory to optimize. But the inventory data is stale. They discontinue products that are actually selling. They keep stock of products that nobody buys. Margin suffers. Growth stalls.
Third, opportunity cost: your finance team spends half their time reconciling and explaining data instead of analyzing it. They can't answer strategic questions because they're too busy debugging data. You can't move fast on new initiatives because the data foundation is unstable.
Fourth, integration cost: every time you want to add a new system or reporting tool, you're blocked by data quality. You want to integrate with Tableau. You discover that the chart of accounts is inconsistent. You want to feed data to a forecasting AI. The historical data is too noisy. Projects stall.
The obvious question: why don't people just fix this? Why let it compound?
The answer is that fixing data is painful and invisible. When you fix code, you ship a feature. When you fix data, nobody notices. Everything still works. The only visible benefit is that reports are a bit more accurate. The cost is immediate and real: you need people, you need time, and you need to be careful not to break anything.
Plus, most data quality work is unglamorous. It's not building features. It's not strategic. It doesn't look good on a résumé. So it doesn't get done until the pain becomes acute.
By then, the cost of fixing it has grown. You now have years of bad data. You can't just delete it. You need to understand what caused it. You need to trace the impact. You need to rebuild derived records.
I've also seen companies try to fix it without a plan. A new executive arrives and says "we need clean data." They mandate a data cleanup project. Six months later, they've spent a million dollars and the data is still broken. Why? Because they tried to clean everything at once. You can't. You need to be surgical.
If you're sitting on bad data, here's what actually works.
Start by understanding the scope. Don't assume you know where the problems are. Audit your data. Run queries that find inconsistencies. Look for duplicates, missing values, data drift. Quantify the problem.
Second, prioritize. You can't fix everything. Fix the data that impacts decisions and operations. Fix supplier data if you're making pricing decisions. Fix inventory data if you're managing logistics. Fix customer data if you're shipping to them. Leave historical data alone if it's not impacting current operations.
Third, build a data quality process. You can't fix data once and assume it stays fixed. Data decays continuously. Bad processes create bad data. Fix the processes that create data. Make sure new records follow standards. Make sure integrations have validation. Add monitoring that flags anomalies.
Fourth, implement governance. Assign responsibility. Someone needs to own supplier data. Someone owns customer data. Someone owns inventory. These people need authority to enforce standards and fix problems.
Fifth, use automation. Manual data cleanup doesn't scale. Build ETL processes that standardize and validate data. Use tools that detect duplicates. Use matching algorithms that consolidate records. Make machines do the boring work.
Fixing data looks expensive. Two million dollars, six months. But calculate the ROI:
Operational efficiency: you identify waste, you eliminate it. For most companies, that's five to ten percent of relevant spend. For a five-hundred-million-dollar company, that's twenty-five to fifty million dollars.
Decision quality: leaders make better decisions because data is reliable. This is harder to quantify, but the impact is real. Better pricing, better inventory, better hiring.
Process speed: your systems work faster when data is clean. Integrations run faster. Reports generate faster. Everything downstream is more efficient.
For a two-million-dollar investment, the payback is usually six to eighteen months. This is real, valuable work.
The companies that will win over the next five years are the ones that take data seriously. They'll clean it up. They'll build processes to maintain it. They'll treat data as an asset to protect and optimize.
The ones that don't will slowly get stuck. They'll be unable to integrate new systems. They'll be unable to implement AI. They'll be unable to answer strategic questions. Their technology will become a liability.
I think data quality becomes a differentiator by 2022. The companies with clean data move faster. They make better decisions. They can be more agile. The companies with messy data are stuck maintaining systems instead of building them.
If you're running a company and you haven't looked seriously at your ERP data lately, do it. You'll probably find things that concern you. Good. That's the first step to fixing it.
The cost of ignoring it is higher than you think.
AI agents that autonomously operate ERP systems are real in 2026. This is what your ERP architecture needs to support agents that make decisions on their own.
Most companies automate the wrong processes first. Here's what I've learned about prioritizing automation, which patterns work, and the mistakes everyone makes.
Clients always ask: should we build or buy ERP? My framework for this critical decision—the key questions I ask and what answers truly reveal.