Why AI + ERP Pilots Stall: Root Causes
del.ai model of mid-market AI implementation failure modes, 2026
usedel.ai · Figures in USD thousands
Enterprise AI pilots usually fail at the data layer rather than the model layer. Be precise about the mechanism, because the popular version of it is wrong: agents on NetSuite can write. Oracle's MCP Standard Tools SuiteApp creates and updates records through SuiteTalk REST, which is a full create-read-update-delete interface. What an agent cannot do is operate outside the surface Oracle exposes and versions. Oracle documents that MCP tools run under the authorising user's role, never with Administrator or full permissions, cannot invoke elevated-privilege scripts or Suitelets, cannot make external HTTP calls, and share your account's integration concurrency limit with every other integration you run. Each additional application in the stack adds its own API and its own definitions of customer and product. The demo worked because it ran against clean exported data in one flat structure; production failed when the same agent met several systems that disagreed about what a customer is, inside a schema nobody on your side can correct.
Source: Oracle, "Available Tools in the MCP Standard Tools SuiteApp" and "Associated Risks, Controls, and Mitigation Strategies," NetSuite Help Center documentation, 2026. ↗
You know the meeting. The vendor brings in a demo environment. The AI reads invoices, summarizes open AR, drafts a variance report. Someone in the room says "this is what we've been waiting for." The CFO approves $75,000. Procurement signs the MSA in three weeks.
Then the pilot starts on your actual system.
Month one: the integration team is still mapping fields. Month two: the agent can read some data but can't write anything back. Month three: the ops lead is using the tool's summary outputs to build a spreadsheet manually, which she then uploads to NetSuite. At the board update, someone says the company is "exploring phase two." Everyone in the room knows what that means.
The AI tool isn't in production. The budget is spent. The pilot is dead.
The vendor says it's a data quality issue. The consultant says it's change management. Your team says the AI wasn't ready. None of them are right. This article explains what actually happened.
NetSuite is a vendor-hosted SaaS platform. Oracle controls the database schema. Your team cannot query it directly, and your agents reach it only through the surface Oracle exposes and versions.
This is not a criticism of NetSuite, and it is worth correcting a claim this page used to make. Agents on NetSuite are not locked out of writing. Oracle's own MCP Standard Tools SuiteApp ships ns_createRecord and ns_updateRecord, which create and update records through SuiteTalk REST — a full CRUD interface. If you have read anywhere, including on this site, that NetSuite's API is read-only or that agents can query but never act, that was wrong.
The real ceiling is narrower and does not move. Oracle's own risk documentation for the AI Connector Service states that MCP tools "can only access a subset of SuiteScript API actions": no elevated-privilege scripts, no Suitelets, no external HTTP calls, and never executed with Administrator or full-permission roles. The SuiteQL tool is documented as read-only. The connector shares your account's integration concurrency limit with every other integration on it, so an agent can be throttled mid-task, and that limit is set by your service tier and SuiteCloud Plus licence count. You cannot extend the schema and you do not hold the codebase.
Every additional application in the stack compounds the second half of the problem. Avalara, Celigo and FloQast each hold their own records behind their own API, with their own idea of what a customer or a product is. An agent asked to read open AR, check inventory availability, pull cash position and push a journal entry is not blocked from acting — it is reconciling several systems that were never reconciled with each other, and doing so against definitions nobody on your side owns.
That is why closed schema ai integration fails at the production stage even when the demo succeeded. The demo ran against clean exported data in one flat structure. Production put the same agent in front of contradictory records it could neither adjudicate nor correct.
When a COO or CFO looks back at a failed AI pilot, there are two distinct failure modes. They look identical from the outside. They have completely different causes.
An AI ERP pilot fails one of two structurally different ways. Failure Mode A is wrong tool or scope: the team bought AI for a poorly defined problem, or picked a vendor whose product didn't match the workflow. The agent worked technically but wasn't solving the right job — a strategy failure, fixable with better discovery or a different vendor. Failure Mode B is wrong infrastructure: the tool was correctly scoped, but the data layer underneath it made reliable action impossible, because the records the agent had to reason over contradicted each other and nobody on the buyer's side could correct the schema holding them. That is structural, and changing vendors does not fix it. del.ai has no deployment sample of its own to tell you how the two modes split in practice — we are pre-revenue and would be inventing the number. Gartner's analysis of generative AI project failures names poor data quality among the recurring causes, which is the diagnostic worth running first.
Source: Gartner, "Why Half of GenAI Projects Fail: Avoid These 5 Common Mistakes," 2025. ↗
The AI strategy was not wrong for teams in Failure Mode B. The substrate was wrong, and no amount of prompt tuning or model switching touches a constraint that lives in records the buyer cannot reconcile and a schema the buyer cannot change.
There is a macro-level analogy here, and it is worth stating precisely rather than stretching. Brynjolfsson, Rock and Syverson's productivity J-curve research found that their intangible-adjusted total factor productivity measure sat 15.9% above the official measure at the end of 2017 (American Economic Journal: Macroeconomics, January 2021). Three things that figure is not: it is a difference in a level at a point in time, not a growth rate; it is an aggregate exercise, not a firm-level result; and it measures hardware and software intangibles through 2017, so it is an analogy for AI rather than a measurement of it. What travels is the shape of the argument: gains from a general-purpose technology arrive after the complementary infrastructure is built, not alongside it. AI pilots underperform when the data model, the schema access and the writable system of record are not in place. Your ERP is that infrastructure question.
The reframe matters. The CFO who approved $75,000 for an AI pilot did not make a strategic error. The infrastructure that was supposed to support the AI was structurally incapable of doing so. Those are different problems with different fixes.
An owned, open-source ERP gives AI agents a second execution mode alongside the first. In probabilistic mode, the agent reads a fully accessible PostgreSQL schema through Odoo's ORM — seeing AR, inventory, cash position and general ledger through one database connection rather than several vendor APIs. In deterministic mode, a developer or an agent modifies the codebase so the task runs on a schedule with no model in the loop on each run: month-end close fires, reads the right tables, posts entries and logs the result at no inference cost. The second mode is the one a vendor-hosted platform structurally cannot offer a customer, because it requires holding and changing the code the ERP runs on. On NetSuite an agent is bound to the tool surface Oracle exposes and versions, however capable that surface is: you can act through it, but you cannot extend it, and you cannot compile your own behaviour into the platform. That is a difference in ownership, not in vendor competence.
Source: Odoo S.A., developer documentation on the ORM, 2026. ↗
On an open-source ERP with a fully accessible PostgreSQL schema, AI agents have two distinct execution modes. Understanding the difference explains why ai erp integration failure is not a model problem, it is an access problem.
Mode 1: Probabilistic execution. The agent reads the full data model, reasons over the actual relational structure of your data, and takes action. It can see open AR, inventory, cash position, and GL simultaneously, not because those modules share an API, but because they share a database. The agent writes a journal entry to the same table your controller sees. No intermediary API. No vendor permission layer. The agent and the human work on the same ontology.
Mode 2: Deterministic execution. This is the mode that closed SaaS cannot offer at all. A developer or an agent modifies the underlying code so that a task runs automatically on a schedule, without AI in the loop on each execution. The month-end close sequence fires at the right time, reads the right tables, posts the right entries, and logs the result, without calling a model. The AI was used to build the automation. The automation then runs deterministically, without AI cost or latency on every trigger.
Mode 2 is the one a tenant on a vendor-hosted platform cannot have, because it requires holding the code. SuiteScript automates inside NetSuite; each additional application in the stack still holds its own records behind its own API. An agent on NetSuite can act, and act on real records — it simply acts through a surface someone else defines, sizes and versions.
This explains why ai tools fail enterprise deployments even when the demo worked: the tool did not change between the sandbox and production, the infrastructure did. The demo ran against clean exported data in a flat structure the agent could reason over. The production failure happened when the ai agents erp integration met several systems that disagreed with each other. The model was the same. The infrastructure was the constraint.
For a detailed breakdown of how the two architectures compare across total cost, AI capability, and schema access, see how the two architectures compare. For the feasibility layer underneath this article, whether an agent can technically connect to your ERP and act on it at all, and what specifically blocks it on NetSuite, see AI + ERP Integration for Mid-Market: What's Actually Possible.
Oracle has shipped real AI into NetSuite, and more of it than the sceptical version of this argument allows. Intelligent Close Manager is generally available from 2026.1, creating and assigning close tasks and locking transaction types and periods. Text Enhance is live. The AI Connector Service is a bring-your-own-model service built on the Model Context Protocol. These are not slides.
Partly, and it is worth being exact about which part. NetSuite's AI features do settle the action-space question inside NetSuite: Intelligent Close Manager shipped in 2026.1 and writes close tasks, due dates and period locks, and the MCP Standard Tools SuiteApp creates and updates records. What they do not do is create a canonical model spanning systems Oracle does not own the meaning of, because that would require authoritative definitions of customer, SKU and account across products Oracle does not run. They also leave the buyer unable to extend the surface: the tool list, the role scoping and the concurrency limits are Oracle's, documented by Oracle, and versioned on Oracle's release cycle. So if your pilot died because an agent could not act, more NetSuite AI may well help. If it died because four systems disagreed about who a customer is, another feature inside one of them does not resolve the disagreement.
Source: Oracle, "Artificial Intelligence (AI)," NetSuite Applications Suite documentation, 2026. ↗
This is not a criticism, and it is not a claim about anyone's commercial motives — we do not have Oracle's numbers or its partners', and would not build an argument on a guess about them. It is a description of where a definition can live. An application vendor can define its own records authoritatively and cannot define anyone else's.
The board sees a failed pilot. They see $75,000 in sunk cost and a board slide that says "exploring phase two." The question you need to answer is why.
Here is the answer: the strategy was right. The infrastructure was wrong.
The AI budget was approved to generate ROI from existing software spend. That strategy is correct. The failure was not choosing the wrong AI tool. The failure was that the system the AI was supposed to work on, the ERP, was structurally incapable of letting AI agents operate inside it. That is not a failure of judgment. It is a substrate diagnosis.
There is also a measurement question, and this page previously got it backwards, so here is the correction. It is not true that GAAP prohibits capitalising internally generated intangibles. ASC 350-40 requires capitalising internal-use software costs incurred in the application development stage, and IAS 38 permits development-phase capitalisation when six criteria are met. GAAP is also an accounting standard, not a law.
The honest version is narrower and more useful to a CFO: work like this can qualify for capitalisation, many AI-workflow artefacts fail the asset definition anyway, and almost nobody does the stage-tracking that would tell them which is which. Note also that FASB's ASU 2025-06 removes the project-stage framework from ASC 350-40 for annual periods beginning after December 2027, so the test itself is changing. Ask your auditor what your own build qualifies for rather than assuming either answer — and be equally sceptical of the opposite overcorrection, which is that every AI workflow your team built is capitalisable. It isn't.
In plain English: the accounting treatment of the $75,000 is a real question with a real answer your audit firm can give you, and it is a different question from whether the pilot taught you something worth the money.
One sentence for the board: the AI strategy was right. The ERP was not AI-ready. Those are different problems with different solutions.
The infrastructure has to change before AI can work. That is the honest conclusion, and it is the only conclusion that leads somewhere useful.
An AI-ready ERP has four properties a tenant on a vendor-hosted platform cannot obtain: an open schema the agent reads directly, one canonical data model across the systems that were merged into it, both execution modes, and an agent surface that includes the codebase, the runtime logs, the configuration and the database itself.
For mid-market companies on NetSuite, getting to that means migrating to an ERP you own. Not because NetSuite is a bad accounting system — it is a capable one for what it was designed to do, and it is now shipping capable AI inside itself. The AI-ready ERP job is a different job from the accounting system job, and it turns on who holds the schema.
del.ai migrates mid-market companies off NetSuite to open-source Odoo on a 90-day model, funded by the NetSuite stack spend that gets deleted: licence, Alliance Partner retainer, SuiteApps, ETL tools and internal admin overhead. A status note we would rather you got from us than from a domain lookup: del.ai was founded in May 2026, is pre-revenue, and has completed zero customer migrations. Two agents are scoped into go-live — a month-end close agent and an FP&A draft agent — with full schema access and both execution modes. They exist as demos today. That is a commitment we will sign to, not an installed base.
The path forward is infrastructure change, not a new AI vendor. The AI vendor you tried was not the problem. The floor it was standing on was.
If you are a CFO or COO at a mid-market company on NetSuite, you approved AI tooling budget in the last 18 months and the pilot isn't in production, this is the math check, not a pitch.
30 minutes. No pitch. We run the numbers for your specific NetSuite spend.
Sources
1. Brynjolfsson, Rock, Syverson, "The Productivity J-Curve: How Intangibles Complement General Purpose Technologies," American Economic Journal: Macroeconomics 13(1), January 2021 — adjusted TFP 15.9% above the official measure at end-2017; aggregate, hardware and software intangibles through 2017, cited here as analogy rather than as a measurement of AI. NBER Working Paper w25148. ↗
2. Oracle, "Available Tools in the MCP Standard Tools SuiteApp," NetSuite Help Center documentation, 2026, listing ns_createRecord and ns_updateRecord. ↗
3. Oracle, "Associated Risks, Controls, and Mitigation Strategies," NetSuite AI Connector Service documentation, 2026 — "MCP tools can only access a subset of SuiteScript API actions." ↗
4. Oracle, "Artificial Intelligence (AI)," NetSuite Applications Suite documentation, 2026, covering Intelligent Close Manager availability in 2026.1. ↗
5. Odoo S.A., developer documentation on ORM and direct PostgreSQL schema access, 2026. ↗
6. Gartner, "Why Half of GenAI Projects Fail: Avoid These 5 Common Mistakes," 2025. ↗