Every couple of weeks, a LinkedIn follower who works in the NetSuite space will forward me a "thought piece" (I guess that's what they're supposed to be) that they stumbled upon involving NetSuite and AI, asking if I've seen it. Usually I haven't, so I appreciate the heads up.
The articles - usually posted by NetSuite AI vendors - are, to some extent, a criticism of the type of work that I'm doing and the approach that I'm taking. And then there are the AI fear mongers, who I often wonder whether they've ever used AI, or whether they're just scared that it's going to replace them. (It is, by the way, and it's coming for me, too. But that's an article for another day.)
First, It Was the Prompts
Initially, the claim was that prompting alone isn't of much real value. That if all you're doing is prompting, then you aren't getting the full benefit of AI. I sell a NetSuite prompt library, so I'll admit that one felt like it was aimed at me.
But as someone who has talked with dozens and dozens of companies that run on NetSuite - and, increasingly, companies that don't - I can tell you two things.
First, that they're getting an amazing amount of value from prompts, especially (but not exclusively) when they're using them for financial analysis.
And second - and I wrote about this recently - that for many companies that are just getting started with AI, prompting is all that they're comfortable doing. Prompting is the on-ramp to agentic AI.
I find the prompt hate ironic, too. AI agents have - or at least should have, if they're really "AI agents" in the first place - one or more prompts embedded in them. Right?
Now It's Where the Agent Lives
Now the criticism seems to have shifted to where the AI agent sits in the big scheme of things. The claim is that, because your employees don't spend their entire day in a single application, your AI agents shouldn't either. An agent that lives inside your ERP system is limited to whatever the ERP can see. The better design, the argument goes, is a separate agent that stands outside of your systems, connects to each of them in turn, and runs the process from there.
The first half of that argument is mostly correct. The rest of it is based on an assumption that is just plain wrong.
The assumption is that an agent built inside the ERP can't see anything outside of it. That's not true of NetSuite itself, and I don't believe that it's true of an agent that runs inside of it either.
What "Inside" Really Looks Like
Sonar is an AI agent that I developed to run inside NetSuite.
It runs natively, so it works with NetSuite the way NetSuite works with itself. It sees the full record model, the custom fields and saved searches, the workflows and approval routing, the posting logic, and the roles and permissions that decide who is allowed to do what. There's no flattened copy of your data sitting in a third-party database somewhere, and there's no sync job that has to finish before the agent knows what happened this morning.
And it isn't confined there. When a process needs something that lives outside of NetSuite, Sonar can reach out and get it through that system's web API over ordinary HTTP calls. A vendor's invoice sitting as a PDF in an inbox, this morning's exchange rates, a carrier's tracking status, a customer's credit check. If the standard API isn't enough for what the process needs, then Sonar can write the Suitelets and RESTlets required to support a more advanced integration. It extends the platform rather than waiting on someone else to do it.
So the idea that an embedded agent is stuck looking at one system doesn't hold up. The employee analogy is a good one, but it points in the other direction. A controller doesn't leave NetSuite to go work somewhere else all day. She works out of NetSuite and reaches for the bank portal or the spreadsheet or the email thread when she needs to, and that's exactly what an embedded agent does.
Where the Work Should Live
I think that the useful distinction here is about what kind of work is being done.
Acting on the books belongs in the system of record. Entering a vendor bill, posting a journal entry, updating a customer record - I believe that these should happen where the ledger, the business rules, the approval workflows and the audit trail already live.
An embedded agent inherits all of that. It runs under a role. It hits the same validation that a human user would hit, and if a transaction can't be posted, then the agent finds out the same way everyone else does. But an external agent has to rebuild that context on its side, or write through an API and hope that the rules it doesn't know about don't matter.
Heavy analysis over large volumes of outside data is a different job, and I'm not going to claim that Sonar should do it. Scoring three years of customer payment behavior or running a margin analysis across every item you've ever sold belongs in a data platform that was designed for that. Nobody should be doing that type of analysis inside an ERP. But the output of that analysis has to come back into NetSuite somehow, and I think that the right way for it to come back is through a controlled door with a defined contract, running under a role that NetSuite enforces. That door is usually a RESTlet, and Sonar can build it.
What I have a harder time seeing the case for is a third thing that sits between those two: a separate product or platform that copies transaction data out of NetSuite, reasons about it somewhere else, and then writes back in through an API with less context than a native agent would have had in the first place.
The Question I Have
An outside agent isn't free. It's another vendor. It's another set of credentials with access to your general ledger. It's another system that your customer and transaction data flows through, and another place to look when something doesn't reconcile.
"NetSuite is still the source of truth" is a comforting sentence, and I understand why people say it. But the source of truth only tells you where the truth is, and it says nothing about where the copies went.
If you're considering an external agent for your NetSuite instance, then ask the vendor about that before you go any further. Is our NetSuite data being extracted and stored somewhere else? And if so, why?
And none of this is theory. Sonar is the interactive version: it runs inside NetSuite against live data, and every query is verified and every action is approved by the person sitting in front of it. Helm is the unattended version, built for the work that should run every night without anyone watching, and it runs inside NetSuite, too. Two very different kinds of AI agent, and neither one of them needed to leave the platform to do its job.
A few weeks ago I wrote down a few things I believe about AI in NetSuite. If I were adding to that list today, then this would be on it: the agent belongs where the ledger is.
In the meantime, I'll keep an eye on my inbox for the next "thought piece."