One question I get asked often about Sonar AI is some version of "can this just run every night?"
I understand why. Sonar is an interactive copilot that runs inside NetSuite, against live data, with every query verified and every action approved by the person sitting in front of it. The prompt library that grew up around it now has 366 prompts across 15 categories - 13-week cash flow models, lot genealogy traces, SuiteScript technical-debt inventories, unapplied cash sweeps. Once you've watched one of those run against your own account, it's natural to want it to run on its own, on a schedule, without you.
For a long time my answer was "not yet." And part of me wasn't sure it should ever be "yes."
Helm is what changed my mind. This is my vision for it, how it's being built, what I plan to ship, and the questions I think that every NetSuite customer should be asking of any AI vendor - including me.
What I Mean by "Unattended"
Helm is an unattended agent execution system for NetSuite. Where Sonar is interactive (you ask, you watch every tool call, you approve anything risky), Helm runs scheduled and event-triggered agents with no human in the loop at execution time.
That sentence should make a controller nervous. It made me nervous. So the design of Helm is almost entirely about one problem: how do you let an agent work unattended in a system of record without ever having to say "trust us"?
My answer is infrastructure.
In Sonar, the human does three jobs. They decide when the agent runs, they watch what it does, and they catch what goes wrong. Helm replaces each of those with something in the account: a trigger layer for the scheduling, a policy engine for the watching, and a run ledger with circuit breakers for the catching. The prompt is still important, but the prompt is no longer what keeps you safe.
What Worries Me About the Usual Approach
I've spent a lot of time looking at how AI products for ERP users are built, and in my experience most of them follow the same shape. The vendor connects to your account with an integration credential, replicates a large volume of your transaction data into their own platform, runs the AI there, and pushes results back. The vendor decides how much autonomy the agent gets. And when you want to know what the agent really did, you're reading the vendor's logs.
I don't think that's dishonest. I think it's the natural shape a product takes when it's built as a platform first and a NetSuite tool second, and I genuinely respect the people building products that way. It's hard work.
But it leaves a finance or security team living with things I wouldn't want to live with. There's a token somewhere outside the account that can read the general ledger (GL), held on infrastructure you don't control. There's a second copy of your data, with your customers' names and your vendors' bank details and your payroll figures in it, governed by someone else's retention policy. The model sees all of those names, because nothing in the pipeline takes them out. And the audit trail for "why did the agent skip these 12 invoices?" is a support ticket.
I built Helm so that none of those things exist.
How Helm Is Being Built
The single most important decision is that everything runs inside NetSuite. The agent loop is SuiteScript, hosted in a Map/Reduce script that checkpoints after every model turn so it can survive governance limits. The queue, the policy engine, the run ledger, and the scheduler are custom records and scheduled scripts in your account. The only outbound traffic is the call to the language model, and that goes through N/https using an API key stored in NetSuite's own API Secrets. No vendor holds a credential to your account. There's nothing for a vendor to hold.
That's a tax, by the way. Building a multi-step large language model (LLM) loop inside SuiteScript governance limits is harder than building it on a server somewhere, and every future feature has to be built inside those limits too. I've accepted that permanently. If a feature can't be built inside the account, then the feature changes. The loop doesn't move.
The second decision is that the agent is an employee. Each Helm agent runs under a dedicated employee record with a purpose-built role, constructed by subtraction from an empty role: View on exactly the record types it reads, Create (never Edit, never Delete) on exactly the record types it drafts. NetSuite's permission system is the enforcement boundary, so a prompt-injected instruction can't exceed the role no matter how clever it is. Attribution is native - "who created this bill?" is answered by system notes. Offboarding is native too. Deactivate the role and the agent is gone, even if every other control fails.
The third decision is the one I expect to get the most pushback on, and I'm fine with that. Draft-and-approve is permanent. Anything with GL impact or external visibility is created in a pending state and routed through the native NetSuite approval workflows your controller already uses. There's no custom approval UI. And this isn't a training wheel that comes off in version two. I believe that it's the only durable defense against both model error and prompt injection. Helm assumes injection attempts will reach the model, and it's built so that a fully successful attack produces, at worst, a bad draft sitting in an approval queue and an alert to the person who owns that agent.
Underneath draft-and-approve, every tool an agent can call is classified into one of four tiers: read, auto-execute but reviewable, draft only, or never. I want to be specific about "never," because it's where I think that most agent products get this wrong. Deletes, outbound emails, payment execution, posting-period changes, and role edits don't have a tool. They're absent from the agent's manifest. There's nothing to jailbreak because there's nothing there.
Then there's the part I'm most proud of, which is how autonomy gets widened. Every draft's fate is tracked - approved unedited, approved with edits (and which fields changed), or rejected. When an action type crosses a threshold on your own approval history, Helm offers a promotion in the morning digest. Something like: "You've approved 214 of this agent's payment applications with zero edits. Enable auto-apply for applications under $500?" A named admin accepts or ignores it. The promotion is scoped by a value cap you choose, it's reversible instantly, and it's revoked automatically if the approval rate slips. Helm never promotes on its own. There are no vendor-side defaults for how much your agent is allowed to do.
Two more things, briefly. Sonar's Privacy Mode withholds customer, vendor, employee, and contact identities from the model at the dispatch layer, and Helm carries that forward, with de-tokenization happening inside the run, in your account, before any record is written. And every run is fully replayable. The complete transcript (model turns, tool calls, results) is sealed with a content hash and stored on the run record, so when someone asks why the agent did something, the answer is in your account and readable in minutes.
I want to be precise about one claim here. Helm does not mean "no data ever leaves NetSuite." The prompt to the model is data. What Helm means is that no vendor platform holds your data or a credential to your account, identities are removed before the prompt is built, and the only thing that leaves goes directly to a model provider you selected, under terms you set. That's a claim I can defend in a security review. The broader one isn't, and I'd rather not make it.
Sonar Is Where Helm Agents Get Built
This is the part that turns two products into one workflow, and it took me a while to see it.
A Helm agent is a Sonar prompt with the human removed from the loop and the guardrails moved into infrastructure. So the way you build one is the way you already work today. You run the prompt in Sonar and watch every query and every tool call. You correct it and run it again until it does what you want against your real data. Then you promote it to Helm: the tool surface gets filtered by tier, a role manifest gets generated from the records the prompt touched, and a schedule or trigger gets attached. The next morning, you read the digest and approve, edit, or reject what it drafted. And you widen the leash only when your own approval history says you can.
Prototype interactively, run unattended, earn autonomy. Nobody has to trust a demo, because the prototype ran against their own account with them watching.
What I Plan to Ship
The first agent template that I've been prototyping with is deliberately narrow. It's an Accounts Receivable (AR) collections drafting agent that runs nightly, reviews overdue receivables, drafts payment applications where unapplied cash clearly matches open invoices, drafts dunning emails by tone tier (with no send tool in existence), creates prioritized follow-up tasks for the AR team, flags anomalies, and posts nothing. The agent itself is almost beside the point. The deliverable is the infrastructure underneath it, which every later template shares.
Alongside it, I'm planning a broad catalog of read-and-flag agents derived directly from the Sonar prompt library. These only observe and report, so they carry almost no risk, and I think that they're where most of the day-to-day value lives.
On the cash side: an unapplied cash and credits sweep, a days-in-AR trend watch, a quiet-quitting customer detector, a credit-limit breach sentinel.
For the close: a backdated transaction detector, an off-hours posting audit, a financial close integrity check, approval-threshold bunching, deletion forensics.
For data integrity: orphaned transaction chains, a stale open document groomer, required-field compliance, negative inventory root cause, phantom and duplicate entity detection.
For supply chain: stockout risk scoring, vendor lead-time reliability, the supply promise anchor audit, backorder aging.
And for the platform itself: login and authentication anomalies, a token and integration credential audit, publicly exposed files, configuration drift diffs, and the zombie automation audit.
If you've used the Sonar AI Prompt Library, then you'll likely recognize every one of those. That's intentional.
After that, and gated on evidence from real customers rather than a roadmap slide, come the drafting templates:
- month-end accrual identification with proposed journal entries
- order documents to draft sales orders
- vendor-bill queue preparation with purchase order (PO) and receipt context
- intercompany reconciliation drafts
- reconciliation sweeps working toward a continuous close.
Each will ship with its own role manifest, tool manifest, golden-run test suite, and injection corpus. No drafting template will ship until the previous one has proven itself in someone's approval queue.
I might be wrong about how quickly that happens, and I'm choosing to be slow rather than sorry.
Helm Will Be Open Source
The most important claim about Helm is architectural: the loop runs in your account, and the only thing that leaves is a de-identified prompt. I believe that a claim like that should be verifiable by reading the code, and I'd be uncomfortable asking anyone to accept it on the strength of a marketing page or a System and Organization Controls (SOC) 2 report.
So the runner, the policy engine, the run ledger, the autonomy ledger, and the read-and-flag catalog will be open source. Your developer can trace every N/https call. Your auditor can diff the role manifest before activation. If you want to build your own agent templates, then the format is a versioned bundle you can author and test yourself.
My hope for Helm is that NetSuite consultants and solution providers build businesses around it.
Unattended automation comes with real work attached. Someone has to configure the approval workflows a customer doesn't have yet, build and review the role manifests, tune the first agent against that customer's data, author new templates for their industry, train the AR team on how to read the digest skeptically, and answer the phone when a run halts at 2am.
I think that work belongs with the people who already know the customer's account, and I'd much rather see a dozen consultancies offering Helm training, configuration, support, and agent creation than try to do all of that myself.
The SuiteQL Query Tool has been free for years, and the best thing that came out of it was watching other people build on it. I want the same thing for Helm.
Six Questions to Ask Any NetSuite AI Vendor
You shouldn't take my word for any of this, and you shouldn't take any vendor's. I suggest asking everyone the same things, me included.
- Where does the agent loop execute - inside my NetSuite account, or on your infrastructure?
- What data is stored outside my account, for how long, and under whose retention policy?
- What credential do you hold to my account, and what can it read?
- Does the model ever see my customers', vendors', or employees' names?
- Who decides which actions the agent may take on its own, and can I see the approval data behind that decision?
- And can I read the code?
Helm's answers are: inside, nothing, none, no, you (from your own history), and yes.
Where This Goes Next
Today, Helm is already in an internal beta stage. Not surprisingly, I've been developing it using Sonar AI.
To give you some idea as to how amazing Sonar is at developing complex NetSuite solutions, in its initial session, and at a token cost of around $15.00, Sonar delivered:
- A complete data model - 5 custom lists, 7 custom record types, 98 custom fields - covering agent definitions, a policy engine ("Standing Orders"), a run ledger that acts as a flight recorder, a draft-approval queue, an earned-autonomy ledger, and a digest queue.
- A least-privilege identity - a dedicated employee record and a purpose-built role with exactly 20 permissions: View on AR data, Create on tasks and drafts, and nothing else. The agent cannot edit or delete a transaction, send an email, or approve its own work. The role, not the prompt, is the enforcement boundary.
- Five SuiteScript files (~78 KB) - a core library with the policy engine, budgets, LLM client, and tool registry; a runner that executes the agent loop with checkpoint/resume every turn; a scheduler that also sweeps approval outcomes into the autonomy ledger; a digest script designed so every draft is verifiable in two clicks; and a User Event that executes approved drafts under the reviewer's identity, not the agent's.
- A deployment runbook with a risk briefing and kill-switch rehearsal.
So I expect the remaining development work to progress quickly. That said, a lot of testing will be involved.
Regardless, I'm publishing Helm's architecture now, before the code, because I think that the questions above should change how people evaluate AI for NetSuite regardless of when Helm ships.
The private beta will be to a handful of design partners: existing Sonar customers with an engaged AR manager and a controller who really reviews what lands in the approval queue.
That last part matters more than it sounds. Earned autonomy only means something if the approval data is real, and a "rubber stamp" produces data that looks great but means nothing. If you're running Sonar today and that describes your team, then let's talk.
And if you have comments, questions, or suggestions about Helm, please get in touch.