November | 2026 | A Tinkerers Notebook

The email has “quick question” in the subject line and lands at 3:40 on a Thursday. Someone on the leadership team wants revenue for three customers by product line over the last 18 months, next to what each of them was quoted. They will read the answer once. Possibly on their phone, in the back of a car. Then nobody will ask that question again for as long as the company exists.

Every finance team knows what happens next. An analyst loses the afternoon. A workbook gets built, with a pivot table and a tab called Sheet3 that nobody can explain, and it gets saved as Q3_Analysis_FINAL_v4_USE_THIS.xlsx in a SharePoint folder. There it sits, unopened, until the next ERP migration, when someone on the project team asks whether it needs to be converted.

I think the AI argument in finance is being had in the wrong place. Most of the noise is about whether a model can replace the monthly reporting pack, and I’m not convinced it should. The quick question is where the math isn’t even close, and almost nobody is putting that on a slide.

The rental counter

Every big-box hardware store has a rental counter in the back corner. Floor sanders. A post-hole auger you will use exactly once, the weekend the fence goes in. Nobody buys a drum sander to refinish one hallway; you rent it for the day, bring it back with the dust bag half full, and never think about it again.

Nobody needs that explained to them. The tool you use every Saturday, you buy. The one you need for a single job, you rent, because owning it means finding a shelf for it and discovering three years later that the belt has rotted.

Reporting works the same way, and finance teams almost never treat it like that. A workbook is a purchase. You pay up front to build it and earn the money back by running it over and over. An AI report is a rental: a small fee each time, and when you’re done there’s nothing to put on a shelf. Most finance teams are buying a sander for every hallway.

What the afternoon costs

The median financial analyst in the US earns a little over $100,000 a year, which works out to roughly $49 an hour before anyone pays for benefits or a desk. Add overhead and the report-automation vendors like to round it up to $75. (I trust a vendor’s math about as far as I trust a vendor’s demo, but I’ll allow it.) Call the quick question four hours and you’ve spent $300 answering it. If it needs real analysis, one vendor estimate puts a proper research report at 6 to 12 hours, or $450 to $900.

And that’s only the part you can see. The rest is whatever didn’t get done that afternoon, which was probably the variance analysis somebody was actually waiting on.

What the rental costs

AI models charge by the token, and a token is roughly three-quarters of a word. A top-tier model currently lists at about $5 per million tokens going in and $25 per million coming out. Feed it 50,000 tokens of exported data (a couple of thousand rows of a CSV, depending on the columns) and let it write 5,000 tokens back, and the bill is 38 cents. The same vendor’s pricier flagship doubles that to 75 cents.

Even the expensive version, an agent that goes off pulling data from several places and rereading its own notes until it has burned through a few million tokens, comes in under $20 on the top-tier model.

Thirty-eight cents, against an afternoon.

Workbooks are built for reruns

This is the part both the replace-your-analysts crowd and the real-analysts-use-Excel crowd tend to skip. A workbook’s whole economic case is reuse. You pay for the build once and the refreshes are cheap, so over a year of monthly runs the build cost gets spread thin enough that nobody minds. Divide that build cost by one and there’s nothing to spread. The quick question gets used once, which makes it the worst possible candidate for a spreadsheet, and we build one anyway, mostly out of habit.

The seldom-used report is the sneakier version. It runs twice a year, maybe for the auditors, maybe for the board pack. Each time someone opens it, the data connection has broken, the formula in column K points at a cost center that was retired in the last reorg, and the person who built it left in the spring. The cheap refresh turns into half a day of archaeology. A model asked fresh each time has no column K to remember.

The second question

Analysis is rarely one question. The answer to the first produces the second, and the second is usually the one that matters. Revenue for those three customers is down, fine, but is it volume or price? And did it start before or after the last price list went out?

With a workbook, each of those is another pivot table and another hour, and most of them never get asked because the person asking can feel what they cost. I think that quiet self-censorship is the real price of the quick question. With a model, the follow-up costs a few more cents and about a minute, so people ask it.

That cuts both ways, for what it’s worth. Cheap questions get asked more often, and so do bad ones.

The fine print, because there is some

You still have to read what comes back. Not skim it. Read it, with the export open in another window, checking that the number in the second paragraph matches the number in the table, because language models are fluent and now and then wrong in a way that looks exactly like being right. Budget an hour for that on anything leaving the building. At $75 that’s a quarter of the afternoon, and the 38 cents rounds to nothing inside it. Anyone selling AI reporting on token price alone is leaving the reviewer off the slide.

Be careful what you feed it, too. Customer revenue by product line is exactly the kind of export that belongs in the tool your company has actually approved, not the one on your personal phone. If nobody has had that conversation with IT yet, a Thursday afternoon with a leadership email waiting is a bad time to start it.

Where the line sits

None of this means the monthly close package should be a prompt. Anything that runs every month for years earns a proper build, with formulas somebody can audit and the same answer every time it runs. Having a model write that workbook for you once is probably the best use of tokens in this whole article.

The hard cases sit in the middle: the quarterly report owned by whoever happened to be in the meeting when it was invented, where checking the model’s version might take longer than refreshing the old one would have. I haven’t found numbers for that one I’d put my name on.

Pull up the report inventory from any ERP implementation and ask how many of those reports were run more than twice in the first year after go-live. Somebody built and tested every one of them. I’d like to see that count next to the line in the project budget that paid for them.

My book, Gamifying the Enterprise: Game Mechanics for Continuous Proficiency, is on Amazon. All my books are on my Amazon author page.

The AD&D365 configuration guides are at adnd365.com/start.

Connect with me on LinkedIn.

Why point agents break

Real questions don’t stay inside one system. Take a supply chain manager asking why a customer’s order will ship late (an illustrative example, not a client story). The purchase order and its confirmed delivery date live in the ERP. The vendor’s explanation is sitting in a buyer’s inbox. The customer’s complaint might be a service case, or it might be a chat thread with the account manager. A purchase order agent sees one piece and answers with total confidence about that piece.

Then there’s routing. With ten point agents the user carries a mental map of which agent knows what. I’d bet the first confident wrong answer from one of them costs trust in all ten. A general agent puts the routing decision back on the system, which is the one doing the reasoning anyway.

Every point agent is also a small software product. Somebody owns its prompt and its connection. Somebody else gets to retest it after every vendor update that touches the tables it reads, and that work never shows up in the original business case.

Permissions are the part I’d lose sleep over. A point agent built on a shared connection or a service account runs as whoever wired it up, for everyone who uses it. One permission model to audit beats one per agent.

Write the skill instead

A skill is the piece that makes point agents hard to justify. In the agent tools that support them, a skill is usually just a folder with a Markdown file in it. The file opens with a name and a short description of when to use it, and the rest is plain instructions, with room for a reference document or a script alongside. There’s no app to register and no connection to configure.

Take a month-end cost summary for one legal entity. A point agent for that job needs its own connection to the ERP. A skill needs none, since the general agent already has one. What’s specific to the job is the procedure: which entity to pull and what the workbook should look like when it lands.

The agent reads the descriptions of the skills it has and loads one when the conversation calls for it, so nobody has to remember which tile to click. The description does the routing. Write it too broad and the skill fires when it shouldn’t; leave out the phrases people actually use and it never fires at all. I’d rather debug one sentence of description than a tenth agent.

A skill holds instructions, not credentials, and it runs in the session of whoever invokes it, so the connectors still check that person’s roles. Treat one from outside the company the way you’d treat a spreadsheet macro from outside the company.

Where a dedicated agent still earns its keep

I’m not arguing for zero dedicated agents. A general agent is built around a person describing an outcome and approving actions as it goes. Work that has to run unattended against every inbound vendor invoice, at whatever hour the invoice arrives, is a different shape of problem, and a narrow agent triggered by that event is the better fit.

Cost is the other honest objection. Many general agents bill by usage, so spend moves with how people use them. A narrow agent with a fixed workload is usually easier to put in a budget line.

And then there’s write access. A general agent with ERP connectors can usually change records as well as read them, under the invoking user’s permissions. Hand it to a power user whose roles already let them post journals and approve payments, and the agent can do anything those roles allow, subject to whatever approval step the tool puts in front of it. A point agent with a tight scope is a fence somebody built on purpose.

So my default is one general agent and a folder of skills, with point agents only where something has to run without a human in the loop. Before the ERP connector goes out to the whole finance team, though, somebody should pull the security role assignments for those users and read them line by line. Start with anyone who still has full administrator rights.

If you’ve built a single-purpose agent that a skill couldn’t have replaced, tell me what it does in the comments. I’d especially like to hear from anyone running one against an ERP.

—A Tinkerers Notebook

A diary of a mad (computer) scientist

Archive

Monthly Archives: November 2026

The Quick Question Tax