On November 2, diginomica published an interview featuring Ryan King, CIO of hydraulic components manufacturer Brennan Industries. He said he used Claude Code and OpenAI Codex to build a sales inquiry screen in NetSuite, completing it in one afternoon.
What this screen does isn't complicated: when customer service takes a call, they check price and lead time while casually writing the context of this interaction back into the CRM. In the past, these conversation details were often lost because they had to jump through several extra pages to enter them afterward. Now data entry has become part of the act of answering the call itself.
What made me pause wasn't 'finish it in an afternoon,' but one of the reasons he gave—controlling token consumption. He didn't have the agent run through the operations for customer service every time; instead, he had AI help write the tools, which were solidified into SuiteScript and kept in the ERP, and afterward what ran repeatedly was just ordinary code.
This is a very pragmatic judgment. In the same week, several major tech companies were talking about hundreds of agents and AI-native workbenches; on the other side, a manufacturing CIO was calculating whether every call was worth paying for. Both sides are right; they just place AI at different layers of the system.
1. Build Tools, or Run Operations
Putting these two routes side by side, the difference is quite clear.
AI run operations
Have the model make a judgment every time a business event occurs; this is flexible and covers the long tail, but costs scale with transaction volume, and every output must be reviewed.
AI builds tools
The model participates in one-time development, and the output is deterministic scripts or modules, which then run under existing permissions with almost zero marginal cost
I’m not trying to negate the previous point. For long-tail processes like supplier confirmation and exception reconciliation, where the rules cannot be fully written out, having the agent read and judge as it goes is indeed more suitable. But handing over high-frequency, stable actions that run thousands of times a day to the model as well may not be cost-effective, and each time adds another uncertainty that someone has to watch.
King also mentioned that directing these coding tools still requires very specific NetSuite process knowledge. I resonate strongly with this. Between generating a working interface and delivering a maintainable application lies a series of questions no one can answer for you: which records this script can modify, how inputs are validated, who can use it, and how to run regression tests for the next version upgrade. Oracle now provides support for both Codex and Claude Code in the SuiteCloud plug-in, and the documentation also ties together permissions, secure coding, and deployment, which precisely shows that 'writing fast' does not equal 'being able to go live'.
In Workday's November 5 Gartner Magic Quadrant for Cloud ERP for Service-Centric Enterprises (Leader for the fifth consecutive year), there is a phrase I really like: agents lawful by design: agents inherit the policies, permissions, and approval chains already running in the organization, and their actions occur within existing business controls rather than setting up a separate set. This is actually the same idea as King putting scripts into SuiteScript and having them managed by existing NetSuite roles—the output of AI must land within the original power structure.
After several years of implementation work, I increasingly feel that judging whether an AI feature is reliable starts with whether the original permission system can stop it when something goes wrong. If it can be stopped, it is a feature; if it cannot, it is another system.
II. Separate business logic from the UI
On November 5, Epicor announced that it had entered the Leaders category of the 《IDC MarketScape: Worldwide AI-Enabled Manufacturing ERP 2026 Vendor Assessment》 (number US54115426, published in October). IDC's comment was 'vertical breadth paired with sub-industry depth'; I usually just skim over this kind of talk and move on, but its product composition is worth breaking down.
Kinetic is the foundational cloud ERP; Prism embeds industry agents into workflows, enabling natural language queries, anomaly detection, and automated actions; Lux is a governed agent design system; Agent Foundry lets customers and partners build, validate, and share agents. The really interesting part is the last item: headless ERP, which decouples business logic from the interface, so external AI tools can connect via open MCP and directly access the ERP's data and rules.
Why is this more important than adding a few more agents? In the past, when external AI wanted to connect to ERP, it either simulated a person clicking through the interface or built custom interfaces for each scenario, yet a large number of business rules are actually hidden in the sequence of UI operations, and interfaces simply cannot reach them. After decoupling, the rules themselves become something that can be invoked, and agents no longer have to rely on “looking at the screen” to guess how the enterprise does things.
Ascend with Epicor shortens the time to get qualified customers' core business processes up and running as quickly as possible; about 87% of new customers choose cloud deployment
Don't skip the other two sets of numbers either: 82% of existing local customers have already moved to the cloud, and there are about 1,800 partners. They show one thing—no matter how beautifully the architecture is described, delivery capability still depends on the implementation network. AI hasn't made this part lighter; it has merely shifted the difficulty from 'configuring forms' to 'sorting out rules'.
The more thoroughly the rules are exposed, the less ambiguous permissions can be. Open connections like MCP, while handing over read capabilities, also turn “who can read which table and which field” into configurations that must be implemented item by item. Don’t use an all-permissions service account to save effort; that is equivalent to giving every external agent a master key.
3. What is the difference between growing in the core and attaching externally?
Microsoft's moves this week provide a good contrast. Rental management in Dynamics 365 Supply Chain Management has entered public preview, covering the entire asset lifecycle within the ERP core, from quotes, contracts, fleet scheduling, and maintenance to invoicing by contract cycle, posting to the general ledger, and fixed asset depreciation. The Copilot Cowork plug-in can identify equipment from customer emails, check availability, draft replies, and initiate rental quotes, then hand them over to a person for review. In the words of their AI ERP lead Georg Glantschnig: coordinators stay in control, while agents handle the assembly.
He has another line that deserves to be remembered even more: the usefulness of an agent depends on the processes and data it can reach. Device availability is in one application, rates in another, and the asset ledger in a third—the agent cannot even put together a single quote.
| Path | Representative practices | Direct impact on agents |
|---|---|---|
| Process-native at the core | Microsoft builds leasing into Dynamics 365; Odoo uses Studio / modules / MCP to keep the rules in the same repository | A single call can read the full context, and actions fall within existing transactions and permissions |
| Supplemented by partner plugins | SAP's FIT-Rent, BearingPoint Lease & Rent; Oracle relies on subscriptions, services, and asset management to assemble it | Multiple vendors, multiple contracts, multiple integrations and upgrade cadences—context easily breaks at the interfaces |
| M&A completes the footprint | Priority Software 11-05 Acquires Fireberry, Integrating CRM / Marketing / Customer Service into Cloud ERP | The goal is a single source of truth for customer and business data, but master data consolidation is still engineering work |
Priority’s acquisition deserves a few more words. In its November 5 announcement, it repeatedly emphasized “single source of truth for customer and business data”—put plainly, this is an admission: a customer is called A in the CRM and B in the ERP, and no matter how powerful the model is, it can only produce contradictory answers. This shares the same motivation as Microsoft building leasing into its core—first put data and processes in the right place, then talk about intelligence.
Speaking of Odoo, by the way. Its position in this lineup is rather special: being open source, same-database, modular, and Studio means business rules already live on the database side; plus native MCP, so external tools can connect without building another set of data copies. This is not to say it can run agents for you out of the box, but rather that the amount of rework needed to "make it reachable by agents" is much smaller. When making a selection, this point is more worth asking about than a few extra lines of AI in the feature list.
IV. Where to draw the boundary: three questions to answer before implementation
1. Which processes live in the system? List the processes to hand over to agents, and confirm one by one whether their rules, data, and transaction boundaries are in the same system. Any step that relies on plugins, Excel, or word of mouth to fill in is where the agent will break. Fix the process first, not the model.
2. Which actions go to agents, and which are written as code? High-frequency, stable, clearly ruled actions should be written as scripts or modules and run under existing permissions; long-tail, exception-heavy, judgment-requiring ones go to agents. The value of Brennan's afternoon wasn't in generation speed, but in getting this layering right.
3. Where does data outside the boundary go? The more convenient open connectivity is, the more you need to write "who holds the keys, under what identity data is read, where context is sent, where logs are kept" into auditable configuration. Rules and permissions are two sides of the same thing; separating them will cause trouble sooner or later.
Another often-missed boundary: versions. Odoo 19's agent uses Topics, 20 uses Skills, and the configuration model has changed; after upgrading, AI workflows need to be re-accepted like financial processes, not considered successfully migrated just because the interface opens. Similarly, any architecture that exposes rules to external tools must regression-test the callers on every version upgrade.
For CIOs and implementation peers, my landing advice tends to start small: pick a high-frequency process with relatively clear rules that genuinely annoys frontline staff, first decide whether it should be written as deterministic code or handed to an agent; set up permissions, logs, and rollback, run it for a full month, then decide whether to expand to a second one. Compared with rolling out hundreds of agents at once, this pace makes it easier to show evidence at quarterly reviews.
This week vendors talked a lot about models, but what really determines project outcomes are the things that don't make it onto launch events: which layer processes live in, whether rules can be invoked, whether permissions can stop things, and whether it's still there after an upgrade.
An agent won't be smarter than the processes it can reach. First fix the roads in the system, then let it in to run.
Sources: ERP News / diginomica interview with Brennan Industries CIO Ryan King (2026-11-02), BusinessWire / Morningstar (Epicor IDC MarketScape #US54115426, 2026-11-05), Agent & Copilot report on Dynamics 365 rental management and Georg Glantschnig's statements (early 2026-11), PR Newswire (Priority Software acquires Fireberry, 2026-11-05), Workday / PR Newswire 2026 Gartner Magic Quadrant for Cloud ERP for Service-Centric Enterprises (2026-11-05), Wavect analysis of Odoo 19→20 AI workflow acceptance (2026-11-05).
This article was compiled and written by Guangzhou Zhongdi Information Technology for reference by enterprise digital leaders and implementation teams, and does not constitute procurement advice. Images are AI-generated.
