Disclosure: This article is written by del.ai, a company that migrates NetSuite customers to Odoo, so we have a commercial interest in the answer you land on. Read the argument with that disclosed, and check the math yourself before acting on it.
If you run finance or ops on NetSuite, you've probably already read the netsuite ai features 2026 announcements: SuiteAgents, generative text tools, a new connector layer. The question worth answering isn't whether NetSuite is shipping AI. It clearly is, and some of it is good. The question is where Oracle's own documentation says that AI stops — and whether the place it stops is the place your close actually breaks.
Here's the bet, named plainly. NetSuite ships AI features every release cycle, so the safest-looking move is to do nothing: read the notes, wait a year, maybe two, and let Oracle build the agent layer instead of migrating for one. Why wait for NetSuite AI instead of acting now? Because waiting costs nothing to decide today. That's the appeal, and it's also the flaw in the framing. The decision to wait isn't free. It's billed later, on your renewal.
This article isn't trying to answer "will NetSuite build AI agents." It already has. An agent pointed at NetSuite through the AI Connector Service can create records, update records, run reports and run saved searches. Anyone still telling you NetSuite's AI can only read is out of date, and you should discount the rest of what they say accordingly.
The real question is narrower, and it is the one Oracle answers in writing. The MCP surface an agent connects through is deliberately bounded: tools run at the authorising user's permission level and never as Administrator, cannot invoke Suitelets or scripts with elevated privileges, cannot modify schema or deploy code, and — the line that decides this whole argument — cannot perform HTTP requests to external destinations. That is not an oversight to be patched next release. It is the security model. An agent standing inside NetSuite is architecturally unable to reach the other systems your close depends on.
So the bar isn't feature velocity. It's whether anything in the stack defines "customer", "SKU" and "GL account" once, across every system that touches them, and has the standing to decide which system is right when they disagree. No in-app surface can supply that for data its vendor doesn't own, and NetSuite is not unusual in this — it is true of every application vendor shipping AI into its own app. The rest of this article walks through what actually shipped, where Oracle documents the boundary, what happens when an agent gets near your GL, and what the wait costs while you decide.
Three concrete items sit behind the 2026.1 AI messaging. Be precise about each before deciding what they mean for you.
NetSuite shipped real AI in 2026.1, and more of it than the sceptical version of this argument allows. Intelligent Close Manager is generally available: a dashboard portlet with AI-driven exception detection that creates and assigns close tasks, sets due dates, and can lock transaction types and periods. The AI Connector Service is a bring-your-own-model service built on the Model Context Protocol, so an external assistant can be pointed at NetSuite data, and its MCP Standard Tools SuiteApp includes tools documented as creating and updating records through SuiteTalk REST. Text Enhance drafts language inside NetSuite forms. Read together, these are genuine capabilities under NetSuite's own role permissions and concurrency governance. What none of them does is create a canonical model spanning systems Oracle does not own the meaning of: each acts on NetSuite's records, on NetSuite's terms, and that boundary is the subject of the rest of this article.
Source: Oracle, "Artificial Intelligence (AI)," NetSuite 2026.1 Release Notes and Applications Suite documentation, 2026. ↗
An earlier version of this page described Intelligent Close Manager as roadmap. That was wrong. It is shipped, it needs an account on 2026.1 or later with the feature enabled under Setup > Company > Enable Features > Accounting, and it does more than display: it creates close tasks, assigns them, sets due dates, and locks transaction types and periods. Evaluate it as a real product, not a slide.
What survives the correction is the scope pattern, and it is the only thing this article needs. Intelligent Close Manager runs against NetSuite's accounting periods and transactions. The MCP tools read and write NetSuite records. Text Enhance touches text fields. Not one of them creates a shared model that also understands your bank feed, your CRM pipeline or an inventory system that lives elsewhere. That isn't a criticism of execution — each does exactly what it was built to do, and does it well enough that the boundary is worth taking seriously rather than dismissing.
Evaluating NetSuite's roadmap on its own terms, "did a feature ship," misses the actual test. The better question is whether the underlying data model and API surface support what an agent needs to act reliably, and that's a structural question, not a feature-list question.
An agentic layer needs five things from the system underneath it: clean data, a unified ontology across every system it touches, an action space it is permitted to write to, evals that catch drift before production, and memory that persists what it learned. NetSuite's MCP surface supplies the action space inside NetSuite, and supplies it properly — ns_createRecord and ns_updateRecord write real records through SuiteTalk REST. Oracle then documents where that surface stops. MCP tools run at the authorising user's permissions and never as Administrator, cannot invoke Suitelets or scripts with elevated privileges, cannot modify schema or deploy code, and cannot perform HTTP requests to external destinations. That last limit settles the ontology question: an agent working through NetSuite's own tools cannot reach the CRM, the bank feed or the 3PL it would need to reconcile against. Adding features inside those walls adds action space. It does not add reach.
Source: Oracle, "Associated Risks, Controls, and Mitigation Strategies," NetSuite AI Connector Service documentation, 2026. ↗
Del.ai starts from a different premise, and it is a bet rather than a track record: rebuild the ontology once, during the migration, so every system an agent touches afterward speaks one model. Where NetSuite's surface is a filtered set of tools over one vendor's records, the destination we migrate to is a database and a codebase the customer holds — schema, source, configuration, logs and connectors all inspectable and extensible, because nobody's security model has to keep a multi-tenant estate safe from you. That is the whole of the architectural difference, stated without a claim about anyone's roadmap. It is why we think a cross-system agent has to be built on owned substrate. It is not evidence that ours works: del.ai is pre-revenue with no completed migrations, and the agents described later in this article are demo-stage.
If you came here cost-motivated, not feature-curious: the question that actually matters might be what staying on NetSuite costs you over five years compared to migrating. See the full math at Odoo vs NetSuite: The Full Cost Comparison.
This is the part worth checking yourself, because it is documented rather than argued. Four limits, all from Oracle's own help centre, define the shape of what a NetSuite-connected agent can be.
It is a filtered surface. MCP tools reach a subset of SuiteScript actions, not the API. "Run as role" is disabled, Suitelets cannot be invoked, and scripts running with elevated privileges are off limits. Of the standard tools, ns_runCustomSuiteQL is read-only; the write path is the record-level ns_createRecord and ns_updateRecord.
It is a rate-limited surface. The AI Connector Service draws on the same concurrent-request pool as your other integrations, sized by your service tier and your SuiteCloud Plus licences. If REST web services already hold two of five concurrent slots, your agent gets three — and a single MCP tool call is usually preceded by additional protocol requests, so the budget goes faster than the call count suggests.
It cannot extend the model or the code. No standard tool modifies schema or custom record definitions, and none deploys code. An agent that discovers it needs a field cannot create one; it files a ticket with a human.
And it cannot leave. Tools cannot perform HTTP requests to external destinations. Whatever else an agent does inside NetSuite, it does not fetch your bank feed, your CRM or your 3PL's count to check NetSuite against.
None of that is a criticism. It is a security model, and a defensible one: these are the constraints that keep one tenant's agent from becoming every tenant's problem, and any multi-tenant vendor arrives at something like them. We are not going to speculate about Oracle's commercial motives — we do not have their numbers, and the architecture is the stronger argument anyway.
But the consequence is structural. A cross-system ontology requires one place where "customer", "SKU" and "GL account" are defined once for every system in the stack, and one authority to settle which system is right when two disagree. A vendor can define those terms inside its own product and nowhere else, because outside its own product it neither controls the data nor its meaning. Buy ten vendor AIs across ten systems and you have ten integrations, ten setup projects and ten permission models, none of which can call each other. That is true of NetSuite and equally true of every application vendor shipping AI into its own app.
Will NetSuite eventually cross into other systems? We don't know, and neither does anyone outside Oracle. What we will say is that it isn't a backlog item: a canonical cross-system model is a different product shape from an application feature, and the isolation above is load-bearing for everyone else on the platform. Treat any promise that names a quarter as marketing rather than a commitment you can plan a migration around — from Oracle or from us.
What stops an AI agent from moving money it shouldn't is a permission model built around the type of action, not only the account it can see: read-only queries, writes to draft records, schema modifications and money-movement each need a separate gate, with money-movement requiring human sign-off before it posts and every action logged to a record nobody can quietly edit afterwards. NetSuite does govern its AI: Oracle documents that MCP tools inherit the authorising user's role permissions, never run as Administrator, cannot invoke elevated-privilege scripts, and sit inside the account's concurrency limits. That is role-based governance rather than action-class governance, and the difference matters when the action in question is a posting. Del.ai is building an action-class permission and audit layer on the ontology a migration produces. As of this writing that is a design commitment, not a shipped or audited product. Any agentic layer, ours included, has to clear this bar before touching a general ledger. Ask to see it in writing.
Source: Oracle, "Associated Risks, Controls, and Mitigation Strategies," NetSuite AI Connector Service documentation, 2026, for the documented MCP permission model. ↗ — the action-class layer described here is del.ai's own design commitment, not a shipped product.
This is the first question a Controller or CFO asks once an agent gets near production data, and it should be. Two things are true at once. Oracle has published a real permission model for its AI surface — role inheritance, no Administrator, no elevated-privilege scripts — but it is scoped by who the agent is, not by what class of action it is attempting, and a posting to the GL is a different kind of act from reading a saved search. And del.ai has not solved that either: what we have is a design document, not a shipped or audited control layer, and no migration behind it. Read it as a specification we are inviting you to hold us to — the four-class action taxonomy, the audit log structure and the approval routing, with the unbuilt parts marked unbuilt: How to Control AI Agents in ERP Finance: The Safety Model We're Building. Ask any vendor, us included, for the same document before trusting anything with a posting.
This is the netsuite ai agents vs migration question underneath the wait-and-see instinct: what if the alternative is missing something NetSuite already does? It deserves a short, direct answer rather than a deflection.
The way we structure it, the disqualifier list gets walked before signing rather than after. We are not going to give you a percentage for how much SuiteScript logic rebuilds cleanly in Odoo, because del.ai is pre-revenue with no completed migrations behind it, and any figure we published would be invented. What we will commit to is the process: every piece of custom SuiteScript in your instance gets a decision before the contract is signed — rebuild it in Odoo, drop it if it isn't load-bearing, or stay on NetSuite if it is. Nothing gets discovered mid-cutover, because discovery happens before the contract, not during the parallel run that follows.
Hard exclusions are listed publicly rather than found the hard way. NetSuite OneWorld is one of them today: multi-entity consolidation at that depth isn't something Odoo matches yet, and del.ai says so upfront instead of pitching around it. If your instance runs on OneWorld, nothing else in this article changes that migration isn't the right move for you right now.
For everyone else, the honest framing is this: migrating now doesn't mean betting against NetSuite ever shipping useful AI. It means not waiting on a roadmap to solve a problem it was never structurally built to solve, while the SuiteScript and customization gap gets closed the way it always does, evaluated line by line before anyone signs anything, not discovered after the fact.
Waiting has a dollar cost that runs whether or not NetSuite ships anything. del.ai's model uses an 8% annual escalator as its base case, the same figure behind our published ROI calculator, and it is a modelling assumption rather than a survey of anyone's contracts. At the $120,000-a-year floor where the migration math starts to work, 8% turns a $120,000 bill into $129,600 in year two and $139,968 in year three. No AI roadmap touches that increase, because escalators sit in the contract rather than in the release notes. The second number is what waiting defers, and it needs a bridge to be honest: migration off NetSuite starts ~$50k as a one-time fee, and hosting the resulting Odoo instance runs from ~$2k a month. Compare that recurring figure against the recurring stack spend it replaces, then net the one-time fee against year one.
Source: del.ai's own cost model and published pricing, 2026 — our modelled estimate, not independent corroboration. Re-run it on your own inputs at ↗
Run the math over a longer horizon and the wait gets more expensive, not less. Four more renewals at an 8% escalator take a $120k/yr contract past $163k/yr before any migration conversation even starts, and every year in between is a year the difference between the two run rates stayed unrealised. NetSuite's roadmap doesn't factor into either number. The escalator is contractual. The gap between run rates is arithmetic, and it is arithmetic you should do on your own invoice rather than on our example — the layers in your stack, not a stylised $120k.
None of this means migrate blind. It means the wait-and-see instinct deserves the same rigor as any other financial decision, priced out in dollars instead of left as a vague sense that the vendor will eventually catch up.
Some readers should wait, and saying so plainly here is more useful than a pitch that ignores it.
If your NetSuite stack spend is under $120k/yr, the five-year math in this article likely doesn't clear the bar yet. Migration has real cost and disruption, and a smaller contract doesn't generate enough escalator and stack savings to justify it on its own.
If there's no board AI mandate and no renewal in the next 12 months, there's no forcing function making this decision now. Waiting is a reasonable default when nothing is compelling you to act, not a mistake, and nobody should migrate an ERP just because an article told them to.
If you're on NetSuite OneWorld, the current hard exclusion applies regardless of everything above. Odoo doesn't match OneWorld's multi-entity depth today, and no AI argument changes that gap. See NetSuite OneWorld to Odoo: What Actually Transfers (and What Doesn't) for Multi-Entity Companies for the specific structural gap list, since not every OneWorld deployment actually uses the depth it's paying for.
For everyone else, renewal-triggered, board AI pressure live, spend at $120k/yr or above, the wait-and-see math in this article is the actual answer to "why not wait." It isn't close.
Built for mid-market companies on NetSuite spending $120k+/yr with a renewal in the next 12 months. Not for anyone still comfortably inside their contract term or shopping ERPs in the abstract.
Show me the math: cal.com/patrickxie/30min
30 minutes, no pitch. Bring NetSuite's 2026.1 release notes and we'll go through them together, feature by feature, and show you exactly what still can't act outside NetSuite for your close. If the math doesn't clear the bar for your stack, we'll say so on the call.
Sources
1. Oracle, "Artificial Intelligence (AI)," NetSuite Applications Suite / 2026.1 Release Notes, 2026, covering Intelligent Close Manager general availability, MCP enhancements and Text Enhance. ↗
2. Oracle, "Available Tools in the MCP Standard Tools SuiteApp," NetSuite Help Center documentation, 2026, listing ns_createRecord and ns_updateRecord. ↗
3. Oracle, "NetSuite AI Connector Service and Concurrency Governance," NetSuite Help Center documentation, 2026. ↗
4. Oracle, "Associated Risks, Controls, and Mitigation Strategies," NetSuite AI Connector Service documentation, 2026. ↗