Most 'agents' are scripts in costumes

There is a genre of explainer right now teaching accountants what an agent is, and the genre has settled on its definition. A recent one in CPA Practice Advisor describes agentic AI as “a fully autonomous system capable of making its own decisions,” built to “drastically reduce human interventions.” That is the industry’s working sentence: the agent perceives, reasons, and decides, and the human recedes toward the edge of the org chart.

I implement AI in back offices for a living, so I should be the last person throwing rocks at the category, and I’m not, exactly. The technology under the pitch is real, and we use it. My argument is with the costume: the word “agent” draped over systems that are, on inspection, workflows. Mostly deterministic, occasionally brilliant, and autonomous in roughly the way a dishwasher is autonomous.

Our firm shipped a system with AI in it that gets used every day, and I wrote up its design in public. That gives me something most of the genre doesn’t have: a census. When a real system’s whole design is on the table, you can count the model calls, see what each one is allowed to do, and notice where the intelligence actually lives. The count is two, and the intelligence mostly lives in SQL.

Strip the costume off a shipped back-office “agent” and you usually find a script: fetch the rows, transform them, compare them to the ledger, queue whatever disagrees. Somewhere in that loop there may be a model call. The deck calls this perception and reasoning. The repository calls it a cron job and a diff.

The costume is profitable because the demo is where the sale happens, and autonomy demos beautifully. Discretion demos terribly: it is a list of things the system declined to do on its own.

The word “script” is doing insult work in that sentence, and it shouldn’t. The back office runs on repetition: the same export, the same matching, the same close, every month. A deterministic workflow that does the same correct thing on run four thousand as on run four is the most valuable kind of software a finance operation can own. We write a lot of it. Nobody budgets a keynote for it.

So the useful question in a demo was never “is there a model in it.” The useful question is discretion. What can this system do to the books without a person? Who settles a disagreement between it and the ledger? What happens on the day it is wrong, because that day is on the calendar whether anyone books it or not.

The question

“

Call it an agent or call it a script. The only thing that matters is what it can do to your books without you.

”

Here is the count on a system whose whole design is public. The QBO A/R App syncs a company’s receivables out of QuickBooks into a database the firm controls, gives the team a fast surface to work from, and writes back only what belongs in the books. A buyer watching it would meet several features that read as AI.

Start with the payment matching, the feature a demo would badge first. Every payment-to-invoice link is QuickBooks’ own foreign key, read from the API and recorded. No fuzzy matching, no model anywhere near the import path.

The duplicate detection runs on exact rules: the same invoice number for the same client, the same client and total inside a seven-day window, a payment reference shared across invoices, payments applied past an invoice’s total. Its cleverest behavior is a recurring-series suppressor that computes the median gap between a series’ invoice dates and tolerates 25 percent of drift, so a monthly retainer stops flagging itself as its own duplicate. The most intelligent-feeling thing in the system is arithmetic.

The aging comes out of a SQL view. The balances, the buckets, and the printed totals all read from the same place, so the paper agrees with the screen.

The model appears exactly twice. A collections readout takes figures the deterministic code already computed, validated and capped at 25 line items and 40 project rollups per request, and narrates them into a short priority list; it runs behind a Generate button, its output is never saved, and it cannot move a number, because the report renders from the same state whether the narration exists or not. And quick invoicing parses one typed sentence into a draft form; the model is not allowed to pick the customer record, it is instructed never to guess invoice numbers, and a person reviews the form before anything is created. The dialog’s own toast says it plainly: “Filled from prompt - review and submit”.

There is not even a review queue for AI output, because nothing needs one. Both outputs are transient, form state in one case and rendered text in the other, and no table in the schema marks a row as model-generated, because no model-generated row exists.

The census

“

Two call sites, both producing words for a person to read. Zero paths to the ledger.

”

That is the whole census. If this firm wore the costume, we would call it a multi-agent financial intelligence platform. It is a database, a pile of deterministic TypeScript and SQL, and two narrow places where language is genuinely the job.

Boards have started asking the right governance question: what happens when the agent gets one wrong. In this design the answer is built in. Before pushing any local edit, the app re-reads the record from QuickBooks and compares. If QuickBooks moved but the values still agree, the row quietly falls back in step. If the values differ, nothing is written, the row freezes as a conflict, an alert opens, and a person picks whose version wins. Even a write that QuickBooks rejects over a stale token freezes rather than retrying blind. The system never resolves its own disagreement with the books.

The write boundary is the same shape. A new invoice requires a person pressing a button that names the invoice and the amount. Record edits go across on a save. Payments never write back at all. Even the sync out of QuickBooks runs when a person presses the button for it.

And when the boundary was tested, we were the ones who tested it. During the first live pushes, the one square inch of surface where model text could reach QuickBooks (an invoice’s notes field) leaked prompt residue into it, once. I keep telling that story because of what it proves: the leak happened on the only surface that existed. The costume version of this system would have given the model forty surfaces.

None of this demos well. A frozen row is nobody’s keynote moment. It is also the entire difference between a system you can run a close on and a system you apologize for at the next board meeting.

If you are being pitched an agent for your back office this quarter, you don’t need to win a definitional argument. Ask for the census.

First: where are the model calls? A vendor who built the system can answer in a sentence per call site. A vendor who answers with the word “agentic” has told you the architecture is a slide.

Second: what can each output touch? The trustworthy answers are “a human’s screen” and “a draft a person reviews.” The answer that should end the meeting is any version of “it posts automatically, and you can review the log.”

Third: when your system and my ledger disagree, who wins? There is one correct answer, and it is a person, with the disagreement frozen in front of them until they choose.

We build and run systems on exactly these rules as an engagement, which is why I care where the costume ends and the work begins. This is general information about how one kind of system is built and bought, not advice for your situation. But if a demo can’t tell you where the model calls are, you have learned what the product is. The product is the costume.