A robot working at a laptop that shows the Helm Command and Control screen inside NetSuite

A progress report on the unattended AI agent framework I've been building for NetSuite - what it is, what the first ten agents do, how it got here, and where it's going.

At 2:00 every morning, an AI agent logs into a NetSuite account, pulls the open receivables, reads every overdue customer's payment history, and drafts collection emails and payment applications for a human to approve. An hour later a second agent reviews the vendor bills that landed yesterday. Then a third checks three-way match. Then a fourth plans the payment run. By breakfast, ten agents have each done a night's work, and the people who own those processes open a review queue instead of a blank screen.

None of those agents sent an email, posted a journal, or paid a vendor. That's the point. Helm is built on a simple premise: AI should do the work, and people should make the decisions.

Here's where things stand.

What Helm is

Helm is an unattended AI agent framework that runs natively inside NetSuite, using SuiteScript 2.1, custom records, scheduled scripts, and a Command & Control Suitelet. There's no middleware, no external orchestrator, and no data leaves the account except the prompts sent to the model. Each agent is a set of standing orders (a system prompt), a manifest of the tools it's allowed to call, and a policy that hard-caps what it can touch (records per run, turns per run, dollars per run, dollars per day).

Every tool an agent can call is classified by tier:

  • Tier 0 - read. Run a query, load a customer's context, check item supply, run an anomaly battery.
  • Tier 1 - flag. Raise a finding for a human to review. Nothing changes in the ledger.
  • Tier 2 - draft. Prepare a real action, such as a dunning email, a payment application - that sits in a queue until a person approves it. Approval is what executes it, as that person, under their role.

There is no Tier 3 (yet). An agent cannot post, send, pay, or delete on its own initiative. The policy engine enforces this at the dispatch layer, not in the prompt - a runaway or manipulated agent hits a wall, not a suggestion. Every run is a record: full transcript, token counts, cost, every record touched, and the reason it stopped.

Ten Agents and Counting

Six agents are currently in production, running nightly on a staggered schedule. Four more have completed their shakedown runs and are being activated for the first time this weekend.

Helm Command and Control screen in NetSuite listing ten active agents with their schedules, policies, models, run counts, costs, and open flags

Helm's Command & Control App, showing the agents that have been created.

Finance and Accounting Agents

1. AR Collections Drafting Agent. Works the aging report. For every overdue customer it reads the full context - open invoices, payment history, disputes, prior contact - and drafts a tone-appropriate collection email. Where an unapplied payment obviously belongs to an invoice, it drafts the payment application. It knows which customers already have drafts or tasks pending and doesn't pile on. Typical night: 4 turns, about 14 cents.

2. AP Bill Review Agent. Reviews newly entered vendor bills for the things a good AP clerk catches, such as missing POs, duplicate invoice numbers, terms that don't match the vendor record, amounts that don't fit the vendor's history. Flags what's wrong and files follow-up tasks for the AP team.

3. Three-Way Match Agent. Matches bills to purchase orders to receipts, line by line. Surfaces price variances, quantity mismatches, bills against unreceived POs, and receipts nobody has billed.

4. Payment Run Planner. Looks at what's due, what's discountable, what's disputed and what's already been flagged, and lays out a recommended payment run with the reasoning - which bills to pay now, which to hold, which discounts are worth taking. A person still runs the payments.

5. Ledger Sentinel. The forensic process. Runs a battery of anomaly checks across the general ledger every night: Benford's Law analysis on bill and journal populations, duplicate-payment detection (same vendor, same amount, same reference, days apart), journals posted outside normal hours, round-dollar patterns, and vendor master changes. It knows the difference between statistical noise and a signal, and it's told to say so.

6. Period Close Readiness Sentinel. Watches the accounting calendar. Which periods are still open that shouldn't be? What's unposted or pending approval in periods that are about to close? Are there transactions dated in one period but posted to another? It ranks the oldest actionable items first, so the controller sees what's blocking the close before the close.

Helm detail view of the AP Bill Review Agent, with the Prompt tab open showing its read-only system prompt

Detail view of the AP Bill Review Agent, showing its system prompt.

Operations and Supply Chain Agents

7. Inbound Supply Watch. Reviews open purchase orders against their expected dates. Late POs, partially received POs going stale, and POs whose lateness is about to become a stock-out somewhere downstream. Files tasks for purchasing where a follow-up is warranted.

8. Inventory Days-of-Supply Watch. Computes days of supply per item per location from committed demand and on-hand, and flags what's about to run out - distinguishing items that are short everywhere from items that are simply in the wrong warehouse and could be transferred.

9. Unbilled Shipments Watch. Finds sales orders that have shipped but haven't been invoiced. Revenue that's sitting in the warehouse door instead of the receivables ledger. Ranked by age and dollar value.

10. Work Order & Assembly Watch. The cause-side partner of the inventory agent. Looks at every open work order and reports which are late and which cannot be built because a component is short - and then says where the component could come from: another location, an open PO, or a sub-assembly that needs its own work order. On its first full run it traced a cascade of seven blocked work orders back to a single sub-assembly with zero stock and no build order.

How Helm Has evolved

I started working on Helm a few weeks ago as a specification and one agent. The path from there to ten agents has taught me quite a bit about running AI unattended inside an ERP.

The first milestone was pretty boring. An agent that ran on a schedule with no human present, finished cleanly, and cost fourteen cents. Everything since then has been about making that reliable at scale.

Policies had to become real. Early on, guardrails lived in the prompt. They now live in a policy engine that checks every tool call before it executes - its per-tool caps, per-run record limits, budget ceilings, kill switches checked at pickup and mid-run. When an agent violates policy the run halts and the halt reason is recorded. That has already caught two real cases of an agent trying to file more flags than it was allowed.

Agents had to learn budget discipline. The cost of an agent run is dominated by turns, because every turn re-sends the full context. The difference between a well-behaved agent and a wasteful one is whether it batches its tool calls or dribbles them out two at a time. The best agents now run in four turns: query, think, act, summarize. We've been refining the standing orders of each agent to enforce that shape, and a versioned prompt history means every change is recorded and can be compared against the runs it produced.

Dedupe had to be built in. An agent that flags the same overdue invoice every night is worse than useless. Every run receives the list of what's already flagged, drafted, or tasked from previous runs, and the server refuses duplicates as a backstop. On a quiet night, most of an agent's findings come back as “already flagged” - which is exactly right.

And the newest piece: agents can now be built conversationally. Helm is now integrated with Sonar AI, my in-NetSuite assistant. I can describe a business problem, work through the queries and thresholds interactively against real data, and then promote the result to a Helm agent in one step. Agents are created in an inactive state, under a shadow policy that permits reads and flags only, with a shakedown run to prove it behaves before anyone activates it.

The four newest agents were all built this way, each in under an hour, and each was refined through two or three prompt versions based on what its shakedown transcript showed. Activation remains a human click in the Command UI. Sonar can build an agent, but it cannot switch one on.

What's Next

Building the framework was the hard part, and with Sonar and the integration between it and Helm, agents are now cheap and easy to build.

My list of potential new agents is pretty long, but here are few that I'm considering creating next:

  • Credit Exposure Watch - customers approaching or exceeding their credit limit, with open orders that would breach it.
  • Sales Order Health - orders stuck in pending approval, pending fulfillment past their ship date, or partially shipped with no remaining supply.
  • Revenue Recognition Sentinel - arrangements whose recognition schedule has drifted from delivery, and deferred balances that should have moved.
  • Customer Churn Signals - customers whose order cadence has broken pattern, before the quarter ends and it's obvious.
  • Vendor Master Hygiene - bank detail changes, duplicate vendors, dormant vendors that suddenly bill again.
  • Fixed Asset Reconciliation - asset register vs. GL, additions without capitalization, disposals without retirement.
  • Access & Permissions Watch - new administrator grants, dormant users with live access, segregation-of-duties conflicts.

And on the framework side, I'll be adding support for event-driven triggers (that run when something happens, not just at 2:00 a.m.), a morning briefing that consolidates every agent's findings into one ranked view for the owner, and an approvals experience polished enough that a controller looks forward to opening it.

Wrapping Up

Picture a controller at 7:00 a.m. on the third business day of the month. The close is under way, the aging report is long, and the questions that matter - what's stuck, what's wrong, what needs a decision today - take a morning to answer by hand.

My hope with Helm is that it can have answers to those questions already prepared and waiting. Not as a chart or a chat reply, but as a ranked queue of findings and drafts, each one citing the exact records behind it, each one produced inside the system of record under its own security model, and each one left for a person to accept or decline. That's a different kind of help than answering questions. It's the first hour of the day done before the day starts, for pocket change per night.

Just as important is that none of it is a black box. The framework is native SuiteScript. The agents are standing orders written in plain English. The policies are records you can open. If you can administer a NetSuite account, you can read every line of what these agents did last night and why, and change what they're allowed to do tomorrow.

I'll be sharing more as the fleet of agents continues to grow. If you run finance or operations on NetSuite and any of the agents above made you think “I'd want that,” I'd like to hear which one, and what agents you'd want running next.