An accounts payable clerk who posts a bad vendor bill has made one mistake. An AI agent that posts a bad vendor bill has made four thousand of them before lunch, all coded the same way, all carrying the same confident memo.
I keep coming back to that asymmetry. For most of the past year I've been building Sonar AI, an agent that lives inside NetSuite, and the more capable it gets, the more of my time goes into the boundaries around it rather than the features inside it. Somewhere in that work the question shifted from "what can an agent do in an ERP" to "what would a business look like if agents did most of it," and that's the question I want to work through here. I'm going to use NetSuite as the example because it's the system I know, but I believe that nearly all of this applies to SAP, Dynamics 365, Acumatica, or any other Enterprise Resource Planning (ERP) system where the transactions and the chart of accounts live in the same place.
Keep in mind that some of this is speculation. I'll try to be clear about which parts I've watched work, which parts I'm extrapolating, and which parts I'm currently building.
The ERP Stops Being the Memory
Today, an ERP is the place where people record what happened. Someone reads an email, makes a decision, and keys a record. The system remembers, and occasionally it blocks a bad entry with a validation rule. The intelligence lives in the people, and the ERP holds the state.
In the version I'm describing, the ledger, the item master, the open orders, and the vendor file become the agent's picture of the world. It reads them to understand what's going on, and it writes to them when it acts. The record is still the record. What changes is who does the reading and the writing, and how fast.
That shift leaves people with three jobs: writing the policy the agents follow, deciding the cases the policy doesn't cover, and signing their name to the result. Everything else is candidate work for an agent. I don't say that lightly - a lot of people I respect do that "everything else" for a living, and I'll come back to what happens to them. But I think that it's more honest to name the shape of the thing than to pretend the agents will stop at drafting emails.
A Tuesday, Sometime Later
It helps to make this specific, so here is a composite of an ordinary day at a mid-sized distributor running this way. None of it is a prediction about a particular company. It's the shape I'd expect once the pieces I already see working get connected end to end.
A customer emails a purchase order as a PDF at 7:40 in the morning. The order-to-cash agent parses it, matches the customer's part numbers against the cross-reference on the item records, checks credit exposure and available-to-promise across the warehouses, and creates a sales order. It picks the fulfillment location by margin after freight, and it does all of that before the sales team has finished their coffee. Approval, in this world, is a policy evaluation over credit exposure and margin, plus what the last few orders looked like, and it runs in milliseconds rather than sitting in someone's inbox. The one line where the margin lands below the floor gets routed to a person, with the agent's reasoning attached.
On the procurement side, the inventory agent has been watching demand by location and proposing purchase orders. Those proposals go to the vendor's agent, which negotiates lead times and quantities inside an envelope both companies agreed to in the contract. When the vendor bill arrives, a separate agent does the three-way match against the PO and the receipt, codes the general ledger from vendor history and item defaults, and files the mismatches for review. Payment is executed by yet another agent, and that one can only pay bills the matching agent has approved. I'll come back to why "yet another agent" matters so much.
And then there's the close.
I believe that the biggest change a business would notice is that the month-end close stops being an event. A close agent reconciles the bank feed every morning, deterministic matches first and judgment calls after. It posts accruals from open purchase orders and receipts. It runs a flux analysis every day against a rolling forecast and writes a plain-English explanation of every variance above a threshold the controller set. On the first business day of the month, the controller reads a set of financials that arrive with their explanations already attached, asks questions about the four or five things that still look odd, and signs.
Meanwhile, a controls agent runs in the background with read-only access and no ability to change anything. It looks for duplicate payments, vendor bank-account changes that land suspiciously close to a payment run, sequence gaps in document numbers, and the kind of digit distributions that Benford's Law says don't occur in honest data. It files findings, and something else fixes them. That separation is the whole point, and it's the same separation a good internal audit function has always insisted on.
Agents Get Employee Records
The part of this that I've become most convinced about is also the least glamorous: every agent needs its own role, with permissions narrower than those of the people supervising it. Segregation of duties applies to software exactly as it applies to people, and the permission system is the only place where that separation really counts.
I learned this the awkward way. The agent I've been building runs under my role, and my role is Administrator. Every query, every update, every delete goes through with my permissions. For a tool that I supervise one turn at a time, that's workable, and the tool has its own enforced read-only and no-deletes modes layered on top. But when I started sketching a customer-facing agent, the first thing I did was create a separate role for it with a very short permission list, and the design got simpler right away. The role couldn't touch a vendor bill or delete anything, so I stopped worrying about those cases entirely.
The role didn't solve the harder question, which was "what if the model gets tricked into looking up another customer's invoices." A NetSuite role scopes record types, and a role that can view invoices can view all of them. That one got solved a layer down, in the server code that executes the agent's requests: it takes the customer's identity from the login, binds it into every query and record load, and ignores whatever customer the model asked for. The model never gets a vote. Between the two layers, one deciding what the agent can do at all and the other deciding on whose behalf, the prompt stopped carrying any security weight, and I think that's the right place for a prompt to be.
Extend that across the whole business and the org chart starts to include agents. Each one has an owner, a scope, a governance budget, and a performance review in the form of exception rate and reversal rate. When someone asks "who approved this," the answer resolves either to a person or to a written policy with a person's name on it. I think that a lot of companies will resist giving agents "employee records" because it feels strange. It's going to feel a lot less strange than explaining to an auditor that all of the agents ran as the CFO.
Policy Becomes the Product
If the agents do the work, then what the business really owns is the set of rules they follow. I've come to think of those rules in three tiers, and all three exist in embryo in the tooling I use every day.
The first tier is verified facts about the account. Which subsidiaries exist, which fields are custom, which bank account belongs to which entity, which "obvious" join throws an error.
The second tier is convention: how this company codes freight, when a variance is worth a note, what a well-formed vendor record looks like, which purchases need a second signature.
The third is process: the ordered steps for a bank reconciliation or a customer onboarding check, with explicit stopping points where a person has to say go.
The difference between a demo and an autonomous business is that the agents write back to those tiers. Every exception a person resolves becomes a new fact, a tighter tolerance, a new gate, or an item on somebody's list to fix the underlying data. The instance gets more autonomous by accumulating verified knowledge, and I've watched that happen at small scale. A bigger model helps at the margins. The memory is what does the work.
Here's a small example of why the "verified" part matters. The account I develop against is a demo, and its ledger includes a set of synthetic "beginning balance" journals posted on the first of every month that make up the majority of the recorded revenue. The first time I asked an agent to analyze revenue trends in that account, it produced a confident, well-structured, completely fictional analysis. It believed the data, because I hadn't told it not to. Now there's a line in its notes about those journals, and every revenue query it writes either excludes them or says that it didn't. Multiply that by every quirk in a real company's data and you start to see what the finance team's job turns into.
Their core skill becomes writing good tolerances. What counts as material for this account. What a normal variance looks like for this cost center in this season. When a vendor master change deserves a second look. Which customers get shipped before the credit check clears. That work is judgment, and it's judgment that has to be written down precisely enough for a machine to apply it. I believe that it's going to look a lot more like accounting than like programming, and I think that's good news for accountants.
It's also my answer to the question I set aside earlier. The AP clerk and the billing specialist don't disappear in this picture, but their days change completely. They handle the exceptions the agents route to them, and every exception they handle is a chance to write the rule that keeps the next one from being an exception at all. That's a better job than keying bills, and I say that as someone who - way, way back in my career - keyed a lot of bills.
It's also a smaller number of jobs, and I don't think that pretending otherwise helps anyone.
The Boring Safety Work
Back to the four thousand bad bills.
Speed changes the risk profile of everything, and the response I see working is a set of mechanical controls rather than a larger review team.
The pattern I've settled on for any change an agent makes runs like this: the agent computes what it wants to do and shows the difference between before and after. A policy check decides whether the change executes on its own, executes and notifies someone, waits for approval, or is simply forbidden.
Then it executes, and a signed entry lands in an audit trail that the agent itself cannot edit. For anything destructive, the approval takes the form of a single-use token that the system mints for one specific record and that the model never sees. The model can ask for the delete, and it can even claim that the user approved it, but the claim does nothing. Only the click does.
Two more pieces belong here.
The first is circuit breakers: rate limits, posting ceilings by account, a hard stop on any account that hasn't seen activity in a year, and anomaly detection on the agents' own behavior, so that the four-thousandth bad bill never gets posted because the two-hundredth tripped something.
The second is treating inbound documents as hostile. A vendor bill PDF is untrusted input to a system that has write access to your ledger, and a well-crafted line in an invoice memo is the new phishing email. The defense is the same one that works for roles: enforcement at the layer where the action happens, and permissions the model can't talk its way past. Prompt instructions are guidance. A control is something the model can't argue with.
None of this is exciting to build. I've spent more hours on the dry-run and confirmation flows in my own agent than on anything a user would call a feature, and I think that's roughly the right ratio.
What Stays With People
I don't believe that everything moves to agents, and I want to be specific about what doesn't, because "humans stay in the loop" is the kind of sentence that means nothing without details.
Materiality stays. Impairment decisions, going-concern judgments, revenue recognition on a contract nobody has seen before, reserve estimates - these depend on a view of the business that isn't in the ledger.
External commitments stay: signing contracts, borrowing, hiring, pricing outside the envelope. And attestation stays, because attestation means a person with liability puts their name on the numbers. An agent can assemble the evidence pack, and it can probably do it better than a tired senior on the last night of the close. It can't be the one on the hook.
There's also a less obvious category, which is deciding what the agents should want. Margin after freight is a fine rule for picking a warehouse until the day a strategic customer's order ships from the wrong coast. Someone has to notice that the rule is wrong, and I don't think that noticing is something the rule can do about itself - at least not yet.
How Far Along This Is
I sometimes find it useful to think in levels.
At the first level, an agent reads and reports. It writes queries, runs the standard reports, exports data, and cannot change anything. Most companies experimenting with AI in their ERP today are here, and that's a reasonable place to be. Walk before you run.
At the second level, the agent proposes. It shows the before-and-after of every change, and a person clicks every time. Still safe, still comfortable.
At the third, the agent executes within written tolerances and asks above them, under its own role, with the audit trail I described.
At the fourth, agents run unattended, bounded processes on a schedule, with circuit breakers and a second agent reviewing material postings.
At the fifth, the agents author the policy themselves - new fields, new workflows, new tolerances, new gates - and people approve deployments and policy changes but little else.
At this point my work sits between the second and third levels. The tooling is mostly there for the third. The written tolerances mostly aren't, and I think that's the honest state of the industry, too.
The gap between where we are and a business that runs this way is mostly a writing problem (yes, really), and it's writing that has to be done by the people who understand the business rather than the people who understand the models.
I might be wrong about the timeline. I might be wrong about the shape. But I've watched the ERP start to turn from the place where the business remembers what it did into the place where the business does it, and I believe that the people who write the rules it follows are going to matter more than the people who write the code.