Every morning at 2:00 Pacific, four AI agents sign in to a NetSuite account and start reading the ledger. An hour later, four more. By the time I'm drinking my first cup of coffee, twenty-eight of them have run, filed what they found, and signed out again, and the whole shift has cost somewhere around eight dollars.
Last week I wrote about this fleet when it was ten agents. As of tonight it's twenty-eight, and every one of them is active. In this article, I discuss what those agents are, what each of them watches, and what they're allowed to do about it - which turned out to be the most interesting design question in the whole project.
What an Agent Is, in This Setup
The word "agent" gets used loosely, so I should say what I mean by it here. Each agent is a NetSuite record with four parts: a set of standing orders (the system prompt), a list of tools it's permitted to call, a policy that caps how much it can touch in a run, and an hour of the day. That's the whole definition. There's no code per agent. The code is a single scheduled SuiteScript runner that picks up whatever is queued, hands the standing orders to Claude, and executes the tool calls that come back - after checking each one against the policy.
Every agent files its work under one shared, login-disabled employee record, so anything an agent creates is signed by the fleet rather than by a person. The real boundary is the tool list: an agent can only call the handful of tools I gave it, and twenty-two of the twenty-eight were given nothing that writes.
Most of the tools are read-only queries against SuiteQL. The agents don't get a general-purpose "run any SQL" tool with no guardrails - they get one that caps result sizes, refuses to filter on fields that behave badly under their execution context, and returns rows in a fixed shape. If an agent needs to look up a customer, then it calls a tool that returns a curated context block rather than browsing the record.
The Original Ten Agents
The first wave was finance operations, because that's where I had the clearest sense of what "a good night" looks like. The AR Collections agent reads the aging, decides which overdue invoices are worth a nudge, and drafts the dunning emails and payment applications for a human to approve. The AP Bill Review agent reads new vendor bills for the things a careful clerk would catch. The Three-Way Match agent compares bills to purchase orders and receipts. The Payment Run Planner looks at what's due and what's in the bank and proposes a run.
Alongside those were an Inbound Supply Watch for late purchase orders, a Ledger Sentinel that runs a set of anomaly checks over posted journals, an Inventory Days-of-Supply Watch, an Unbilled Shipments Watch, a Work Order and Assembly Watch, and a Period Close Readiness Sentinel that reads the close checklist and the unposted transactions and says whether the period is really ready to lock.
Ten agents, all watching the parts of the business that produce or consume cash. That felt like plenty.
The Eighteen New Agents
The second wave of agents came from a different question. I stopped asking "what would an accountant check?" and started asking "what goes wrong in a NetSuite account that nobody notices for months?" That produced a longer list, and most of it had nothing to do with the P&L.
Some of the new agents watch master data. The Customer Master Hygiene and Vendor Master Hygiene agents look for duplicates, missing terms, blank subsidiaries, and the kind of drift that creeps in when several people create records over several years. The Pricing Integrity Monitor compares what was invoiced to what the price lists say should have been invoiced. The Credit Exposure Watch sums open balances against limits. The Customer Churn Sentinel looks for accounts whose order pattern has gone quiet.
Some watch cash that's stuck somewhere it shouldn't be. The Unapplied Cash and Credits Sentinel finds payments and credit memos sitting unapplied. The Undeposited Funds Aging Sentinel finds receipts that were recorded but never made it into a deposit. The Negative and Zero-Cost Inventory Sentinel finds item-location combinations where on-hand has gone below zero or cost has collapsed to nothing, which is almost always a receiving or costing mistake upstream.
The one I'm most excited about is the Cash Runway Sentinel. Every night it takes each subsidiary's bank balance, adds up the vendor bills that are due over the next twelve weeks, adds up the customer invoices that history says will really be paid (and when), and projects a weekly closing balance against a floor. The floor is a policy I set: two weeks of average outflow, computed from the trailing six months. Invoices owed by customers who have never paid before don't count toward the projection at all - they're listed separately as "at risk" - and any invoice that's already overdue is treated the same way. So the projection is deliberately conservative. If it says week two is fine, then week two is fine even if the flaky payers stay flaky. And if it says week two is below the floor, then I know on Monday, with the specific bill that causes it and the specific inflows that would have to arrive to cover it.
Then there are the agents that watch the account itself, as a system. The Deletion Sentinel reads the deleted-record log every night and reports what disappeared, who removed it, and from which context. The Public File Exposure Sentinel looks at the file cabinet for files marked "available without login" and asks whether any of them contain data that shouldn't be public. The Access and Permissions Sentinel watches for role changes, new administrators, and users who haven't logged in but still could. The Script Error and Deployment Health Sentinel reads the execution logs for scripts that have started throwing errors and deployments that have gone quiet. The Edit Storm and Rework Sentinel looks for records that were edited many times in a short window, which is either someone fixing a mess or someone making one.
A few more round it out: a Quote Follow-up Sentinel for estimates going cold, a Fixed Asset Reconciliation agent that ties the asset register to the GL, a Sales Order Health agent for orders stuck between approval and fulfillment, and a GL Dimension Tagging Sentinel that finds posted expense lines with no department and posted revenue lines with no class. That last one matters more than it sounds. An untagged expense lands in "No Department" and vanishes from every manager's budget report, and nobody complains, because nobody can see what they can't see.
What The Agents Are Allowed to Do
This is the part I'd want to read if someone else had built this, so I'll be very detailed about it. I pulled the tool lists for all twenty-eight agents tonight and counted.
Twenty-two of them have exactly one write tool, and it's flagForReview. It creates a finding record with a headline, a severity, an evidence list, a link to the record in question, and a fingerprint. That's all they can do. They can't create, edit, or delete anything in the account.
Six of them - the original finance agents - can also create a task and assign it to a person. One of them, AR Collections, can additionally draft a dunning email or a payment application into a review queue, where a human approves, edits, or rejects it. Nothing posts on its own. Nothing gets sent without a person clicking a button.
I think that this is the right design for the foreseeable future, and I'd say the same to anyone considering something similar. The temptation is to give an agent the ability to fix what it finds, because the fix is often obvious. But the moment an agent can write to the ledger, every prompt becomes a security review, and every model update becomes a risk. Keeping twenty-two of twenty-eight strictly read-only is what made it possible to add eleven new agents in one week without losing sleep over it. Read-only agents can be wrong. They can't be expensive.
What Comes Out the Other End
All of those findings flow into one review queue. A digest goes out each morning grouped by agent, and a separate Analyst agent - one that reads the other agents' runs rather than the business - writes a short brief at 8:00 that says what finished, what didn't, what the fleet costs, and which findings have been sitting unreviewed the longest. It's the one agent that reports on the agents.
The fingerprint is what makes the queue usable. Every finding carries a stable identity built from the agent, the record type, and the record id, and an agent that tries to flag something already open gets told "a reviewer already has this one" and moves on. I got the definition of "already open" wrong the first time - I had tied it to whether the digest had been sent rather than whether a person had reviewed the item - and the queue grew faster than anyone could read it until I fixed that. Small definition, large consequence. The lesson I took from it is that the meaning of "closed" deserves as much design attention as anything in the prompt.
What This Costs
Since the first run on September 14th, the fleet has completed 110 of 119 runs. The nine that didn't complete were early budget halts while I was tuning the per-run caps, which is exactly what the caps are for. Total spend across all of it is $37.54, which works out to about 31 cents a run and just under six model turns a run. Those runs have produced 554 findings covering 229 distinct problems, 37 drafts for review, and 23 tasks assigned to people.
For scale: a full night with all twenty-eight agents should come in at around eight or nine dollars. I have clients who routinely pay a controller for an hour of chasing a single unapplied payment, and that hour costs more than the whole fleet does in a night.
How an Agent Gets Added
I don't build agents in the Helm UI. I build them in a conversation with Sonar, the AI assistant that runs inside the same NetSuite account.
It starts with me describing the job in plain English: "watch for cash sales sitting in Undeposited Funds for more than a week and tell me which ones." Sonar already knows the account - the subsidiaries, the account numbers, the quirks in the demo ledger - so it drafts the agent's prompt against the real schema, picks the tools the agent will need from the fixed tool manifest, and shows me the whole thing before anything is saved.
When I say yes, Sonar creates the agent record. Every new agent arrives inactive and attached to the Shadow policy, which means that it can run, but only when I ask it to, and only under the tightest caps. The prompt passes through a lint gate on the way in. If the prompt filters on a transaction status the runner can't see, or forgets to tell the agent to finish its run, then the write is refused and Sonar has to fix it first.
Next comes a shakedown run. Sonar queues it, the runner picks it up on its next fifteen-minute tick, and a few minutes later Sonar pulls the transcript back and reads it with me: how many turns, what it cost, which flags it raised, and whether the evidence on each flag actually supports the claim. This is where most prompts fail the first time. One agent filed flags without evidence and then re-filed them. Another wrote "no activity" for weeks that its own table showed had tens of thousands of dollars moving through them. Sonar and I rewrote both prompts, saved them as new versions with a note on what changed, and ran the shakedowns again.
The one thing Sonar cannot do is turn an agent on. Activation, policy changes and deletion live in the Helm Command UI and need a human click. That's deliberate. The assistant that writes the agents doesn't get to release them.
Adding eleven agents this way took an evening. Writing them by hand would have taken me a week, and I would have made the same mistakes the shakedowns caught, without a shakedown to catch them.
Next Steps
Right now every agent runs every night, and for about a third of them that's more often than the underlying data changes. Vendor master hygiene doesn't need a daily pass. Period close readiness matters in the last few business days of the month and hardly at all otherwise. Fixed asset reconciliation is a monthly question. So the next piece of work is cadence - letting an agent be weekly, monthly, or relative to period end - which will cut the nightly run count roughly in half without giving up any coverage.
The other thing I'm watching is the queue. Twenty-eight agents produce a lot of findings, and a finding that nobody reads is worth nothing. The Analyst agent already tells me each morning which item has gone longest without a look. I suspect that the next real design problem is on the human side of the queue, and that the fleet will keep pointing at it until I do something about it.