Read more

Maybe it treats the entry like a third-party transaction and overstates revenue. Maybe it flags the elimination as an anomaly and sends someone chasing a problem that doesn’t exist. Either way, the output looks fine. The chart is clean. The explanation is confident. The PDF is ready for the CFO.

And the accounting is wrong.

This isn’t a failure of intelligence. It’s a failure of context.

The model has read nearly everything ever published about accounting. Every textbook, every standard, every audit blog. It understands intercompany eliminations better than most first-year staff accountants … in the abstract. What it doesn’t know is anything about your eliminations. Which entities trade with each other, which accounts should offset, what timing differences are normal, which mismatch is harmless, and which one means somebody screwed up.

The agent knows the textbook version perfectly. It’s missing yours.

And your version (in most companies I’ve worked with) has never been written down. It lives in the consolidation system, in a policy doc on SharePoint nobody’s opened since 2021, and/or mostly in your controller’s head.

And we’re about to dig in a bit on why a few words have started showing up in your feed more frequently than the words “quietly” and “shape” in your LinkedIn comment section.

Three terms are all over AI infrastructure conversations this year:

• MCP

• semantic layer, and

• ontology

On the surface, they sound like things you should maybe let the IT department worry about. But … once you understand them, they describe three different problems, and if you’re going to let an AI agent anywhere near your close, you should probably know which is which.

One gives the AI access to your systems, one tells it what your data means, and the last one teaches it how the pieces of your business fit together.

You need all three.

Share

The Wiring

MCP, or Model Context Protocol, is a standard way for AI models to talk to outside systems.

Think of it as plumbing. Instead of building a custom integration every time you want a model to talk to an ERP, a data warehouse, or a planning tool, MCP gives developers one common way to connect them.

That’s kind of a big deal. It’s also much narrower than you might expect.

MCP can help an agent pull journal entries from NetSuite or query Snowflake. It doesn’t tell the agent what any of it means. The connection itself contains zero accounting knowledge. It’s moving data back and forth. That’s all it does.

And it’s easy to overestimate what that connection means. Watching an agent query a live general ledger feels intelligent. Something is happening in real time, against your actual systems, and the answers come back in full sentences. But you’re watching plumbing. The intelligence question, whether this thing understands what an elimination is doing in account 4890, hasn’t come up yet.

Access isn’t understanding. A lot of disappointing AI pilots over the next two years will trace back to some version of confusing the two.

The Dictionary

The next layer is the semantic layer, and it does what the name says: it tells the system what your data means in business terms.

Finance and BI teams have been doing this for years. Raw database fields get mapped to definitions like revenue, ARR, gross margin, so that everyone asking for the same number gets the same number. If you lived through the era of five dashboards showing four versions of revenue, you already know why this layer exists.

AI raises the stakes considerably.

A language model shows up with generic definitions learned from the whole internet. It knows what “operating expense” means in the abstract. It has no idea what your company means by it. It doesn’t know your chart of accounts. It doesn’t know that account 4890 exists for exactly one consolidation adjustment, or that one business unit books below the line what another books above it.

Without that mapping, the model infers. Inference works well in a lot of domains. It’s a terrible way to close the books.

A semantic layer turns an opaque account code into something the agent can use: intercompany elimination, non-economic activity, exclude from operating expense, must net to zero at consolidation. Now it has a definition instead of a guess.

The old version of this problem produced four revenue numbers on five dashboards, and eventually somebody noticed. The new version is worse, because a generative model doesn’t just return the wrong number. It writes a confident, well-organized explanation around the wrong number. The error arrives pre-rationalized.

The Worldview

Even a perfect dictionary isn’t enough, and eliminations are exactly where you find that out.

Say the agent correctly identifies a $500,000 balance as an intercompany receivable. The classification is right. Now it needs to know that the matching $500,000 payable sits in a different legal entity, that the two balances are opposite sides of one economic event, and that both should vanish when the group consolidates.

That’s a relationship, and relationships are what an ontology describes: the things that exist in your business, how they connect, and what rules govern the connections.

The word comes from philosophy, where it means the study of what exists. The finance version is concrete: which legal entities exist, who consolidates whom, which entities trade with each other, which accounts should offset, what currencies and jurisdictions apply, and which conditions are a valid exception rather than an error.

The semantic layer tells the agent, “this is an intercompany payable.” The ontology tells it, “this payable belongs to Entity A, should have a twin receivable at Entity B, and both disappear at consolidation.”

Without that structure, an agent can classify every individual transaction correctly and still misread the financial statements. Right about every tree, wrong about the forest.

The Real Bottleneck

Most companies have never written any of this down.

The entity hierarchy lives in the consolidation tool. Policies live in SharePoint. Account definitions sit in somebody’s Excel file. The exceptions live in old close checklists, email threads, and heads.

Mostly heads. Your controller knows one entity always books a certain accrual a day late. A senior accountant knows which intercompany mismatch is noise and which one is a mistake. The consolidation manager knows the three exceptions to the policy that aren’t in the policy.

Humans fill those gaps automatically. It’s most of what experience is. Machines don’t, and won’t, until somebody writes the gaps down.

So making finance agent-ready turns out to be a knowledge engineering project. You’re taking judgment that experienced people apply invisibly and turning it into something precise enough for a system with no judgment of its own to follow. Unglamorous, detailed, nobody’s idea of an exciting AI initiative. Also where most of the value is.

The scarce resource here isn’t the latest model, and it isn’t prompt engineering. It’s domain expertise, specifically the ability to articulate it. The people who know exactly how your books work, undocumented weirdness included, may end up at the center of your AI program. Some AI companies have figured this out already. Basis, whose agents do multi-day tax work autonomously, hires philosophy majors to write the documents its agents run on. Defining categories precisely, without contradiction, is the actual job.

What This Means for Your Stack

MCP is the wiring. It gets the agent to your systems.

The semantic layer is the dictionary. It tells the agent what your data means.

The ontology is the worldview. It tells the agent how the pieces fit together.

Put all three in place and you have something that can start operating inside a real finance environment. Skip the last two and you’ve hired a very fast employee with access to every system and no onboarding.

Which is probably not who you want closing the books.

In the Pro Edition

The buildout: a semantic-layer template for intercompany eliminations, a framework for testing whether an agent actually followed your process instead of just producing plausible output, a five-step roadmap for making one finance workflow agent-ready, and prompts you can adapt to your own environment.

Connecting an agent to your financial systems is now the easy part. Teaching it enough about your business to be trusted there is the work.

Unlock the full model and templates:

Subscribe now

Read more

We dumped in financial statements and had it draft commentary, let it summarize technical accounting memos for us, and handed it excel workouts to find out what went wrong in cell H47 … which, as every finance professional knows, is where an otherwise pleasant afternoon goes to die.

An agent works differently. Instead of handing the model a single task and waiting for an answer, you hand it an objective and let it work through a series of steps to get there.

My favorite example of a finance function that AI is surprisingly good at is the monthly variance analysis. I’ve used this as a great starter example of using AI inf finance going all the way to the ChatGPT 3.5 days. We can ask AI to review actuals against budget, identify material variances, pulls, transaction detail, compare against prior periods, hunt for operating drivers, and now even email business partners for more detail, draft commentary, check the numbers, and send it up.

In the past that was a whole series of individual prompts. We had to use Chain of Thought (CoT) and other methods to essentially babysit the chatbot through the whole process. Now though, we can knock out a huge swath of every one of those tasks in a single prompt. (Though I’d probably stop short of letting it fire off the AI slop cannon in those two emails. Draft, sure … but let me take a look before you ping Hank in treasury.)

That distinction is growing increasingly stark. KPMG reported in May that 93% of US companies expect to be deploying or scaling AI in their finance functions within 18 months, with half of them planning to orchestrate multi-agent systems across workflows.

Which means it’s worth understanding what these things are before every SaaS company on earth adds the word “agent” to its homepage (or has this already happened?).

What an AI agent is

As a somewhat pedantic defender of what an agent actually is, I’ve finally had to concede that there’s no single agreed definition.

Here’s mine:

An AI agent is a system that pursues an objective, decides what to do next, uses tools, evaluates results, and keeps iterating until it hits a stopping condition or needs a human.

The core loop runs like this:

This is distinctly different than the behavior everyone recognizes from chat tools, which default to request and response.

An agent adds a loop on top of that. It acts, looks at what came back, then decides what to do next without human intervention.

Here’s what I mean:

Prompt 1: Chatbot
“Explain why operating expenses were over budget.”
The model answers.


Prompt 2: Agent
“Investigate operating expense variances and prepare management commentary.”
An agent retrieves data, identifies anomalies, pulls supporting detail, compares periods, runs calculations, and refines its analysis step by step.

The mechanism here is persistence with feedback. The model doesn’t get smarter between steps three and four. It gets another look at what happened and another chance to correct course. This is the “loop.” The loop introduces autonomy, which is useful under constraint … and more than a little dangerous without it.

Finance has spent a century building controls, and the reasons for doing that haven’t changed.

Why agents got better

Agents aren’t new. What changed is the stack around them.

They hold together over longer chains of work

Modern models are better at breaking a task into steps, catching their own mistakes, and staying coherent across a long sequence. METR tracks how the length of task a frontier model can carry has moved over time, and that timeline continues to incrementally increase … to the point where users frequently have to throttle back the agent to prevent it from overstepping the ask.

And this is important in our profession because finance work is rarely one step. It’s a chain of dependent decisions, each of which assumes the previous one didn’t go sideways.

Share

Agents can use tools

Without tools the models can respond and for the last couple of years they can even reason. But tools give them the ability to act.

Which means they can do things like query systems, run calculations, retrieve documents, execute workflows, and interact with enterprise software. Agents open a whole new realm of possibility. A model that understands the P&L at this point pretty much seems like a parlor trick. But a model that can operate inside the systems producing the P&L becomes a workflow participant … with everything that implies about access and review.

The surrounding infrastructure matured

This part is the least visible, but arguably the most important. Modern agent systems include orchestration layers, memory, tool routing, permissions, logging, and recovery mechanisms.

So the model isn’t operating alone anymore. It’s sitting inside a controlled environment designed to make it useful in production. And that layer is what moves an agent from a tool that runs on a path you guide to one that runs autonomously in the background until it produces a result.

The harness is now more important than the model

An agent harness is the infrastructure around an AI agent that manages its tools, context, memory, permissions, execution flow, and interactions with external systems.

A useful analogy is hiring a new analyst. You aren’t hiring intelligence in a jar.

You define:

• what they’re responsible for

• which systems they can access

• which decisions they make on their own

• what has to be escalated

• how their work gets reviewed

• how their output is recorded

An agent needs the same structure, and in agent architecture that structure has a name. It’s called the harness.

A typical harness includes:

• Objective definition. What the agent is trying to achieve.

• Context injection. Which data it can see.

• Tool access. Which tools it can reach, at which permission level.

• Memory and state. What it has already done.

• Permissions. What it’s allowed to do.

• Stopping rules. When it should stop.

• Validation logic. How outputs get checked.

• Human approval gates. Where oversight is mandatory.

• Audit logging. What it did and why.

Read that list again, and you’ll notice you already own most of it. Segregation of duties, access controls, materiality thresholds, review evidence, and retention. The harness spec and the control matrix are exactly the same.

The model supplies the reasoning, but everything about control lives in the harness. And this is where finance teams should spend their design time.

Let the systems compute and the model interpret

The design rule that keeps agents out of trouble is to keep arithmetic in the systems built for arithmetic and point the model at the part that requires judgment.

In variance analysis, that splits cleanly:

• SQL or the ERP calculates actuals, budget, and variance

• rules define materiality thresholds

• the agent identifies which variances matter

• the agent investigates causes

• the agent drafts commentary

• a validation layer checks every numeric claim against source

No one wants a language model to improvise revenue figures. What we do want is for it to explain why revenue moved. Computing a variance is arithmetic. Explaining one is analysis, and the two require different tools.

What a finance agent looks like in practice

A production-grade variance agent runs something like this:

1. Results close and publish.

2. The agent retrieves actuals and budget.

3. A calculation engine computes variances.

4. The agent identifies material deviations.

5. It pulls supporting ledger detail and context.

6. It investigates probable drivers.

7. It drafts commentary for each key variance.

8. A validation layer checks the numbers.

9. A human reviewer approves or edits.

10. The final report goes out.

At no point is the agent “free-running.” It’s operating inside a structured process with gates. And that structure is what makes it usable in finance.

Production is where the interesting problems live

At this point, we’ve all seen AI do some amazing work in finance. From analyzing a trial balance to building out DCF models and waterfall charts from scratch. (Just don’t ask AI to build a pivot table in Excel!)

The real question now though is if it can perform all these tasks repeatedly, reliably, with an audit trail, under existing controls, and inside enterprise systems

Early production deployments cluster in reconciliation and close reporting, which makes sense. Those workflows have the clearest rules, the most repetitive exception handling, and the least tolerance for creative interpretation, so they’re the easiest place to prove a harness works before pointing one at something ambiguous.

Efficiency is obviously the main benefit and driver here. And where finance needs to focus now is around how more and more of our workflows becoming partially executable by software that makes intermediate decisions along the way. This actually changes the whole workflow design process.

Five questions to ask before you scope one

1. What’s the objective of the process?

2. What data is required to complete it?

3. What tools or systems must be accessed?

4. What should be deterministic and what should be AI-driven?

5. Where does human approval stay mandatory?

These map to how agent systems are built. They also map to how finance controls are governed. That overlap is the reason your controllers are actually better positioned to design these systems than anyone else in the building.

The shift

The first wave of AI in finance was assistance. The second is execution.

That doesn’t mean finance teams are bring replaced. It means the work is being reallocated: systems compute, agents investigate, validation layers check, and humans decide. But only when the system is designed for it.

Once software can take actions, “did it answer correctly” stops being the interesting question, and “can we explain everything it did” takes its place. Finance will always care less about intelligence than about evidence. That’s probably the correct instinct.

Autonomous or not, somebody eventually asks for the receipts.

The Pro edition this week looks under the hood of an agent harness.

Subscribers get every layer between the model and the approved commentary, how decisions move through them, and what permissions, validation, escalation, and logging have to look like before finance signs off.

It comes with the Governed Finance Agent Reference Architecture, two pages: the full schematic, and a nine-section review checklist you can work through in a design review rather than reconstruct from memory afterward.

Unlock the full architecture and review checklist:

Subscribe now

Deliberate doesn’t have to mean a marathon strategy session. For each task, you just need two numbers and a clear written rule for using them.

That’s the whole method. Most finance teams never make it this far because th…

Read more

In a blog post this week, OpenAI’s CFO laid out two “bold ambitions” for her finance team: a zero-day close, and forecasts that update themselves continuously instead of waiting around for the next quarterly ritual. AI pulls spending plans, GL actuals, purchase orders, and accruals into one reconciled view, then drafts the explanation when something looks off. A human still owns the sign-off. “We are still building toward both ambitions,” she wrote … This is clearly CFO-speak for we haven’t shipped this yet, but just watch!

I kind of believe her.

Anyone who’s spent real time in finance or fintech over the last twenty years has heard some version of this story before: the bots are arriving any day now to finally do the busy work so humans can finally focus on the real value-add of the function. I’ve heard it enough times that I stopped being skeptical of the promise … only the timeline for when that day would arrive.

Share

There’s an old line, usually pinned on Bill Gates (though he almost certainly never said it) about choosing a lazy person for a hard job because a lazy person will find the easy way to do it. I’ve quoted it for years as a stand-in for my whole career; not because I was lazy, but because I never had much patience for doing the same task the same way every day, week, or month when there was obviously a better way sitting a few keystrokes out of reach.

And that’s how I landed in my first data lake. Back in my days working in telecom, years before “zero-day close” was a phrase anyone used. I was running procurement and budget management at the time, which meant every stale number was my problem before it was anyone else’s. Field techs were installing equipment across a territory too large for weekly reports to keep up with, and I was ordering inventory off data that was already a week stale by the time it hit my desk. Too little equipment meant installation delays, and too much meant it sat in a warehouse getting damaged or walking off.

The fix wasn’t glamorous. I worked with finance, accounting, operations, and engineering to build a system that piped inventory data into a shared data lake in something “close enough” to real time. Technicians updated counts from the field, and I could order the moment inventory hit a threshold instead of waiting on a report that used to pass through four departments first. It wasn’t AI. It didn’t need to be. It was just a practical dataflow that stopped making people wait for information that already existed somewhere.

(There’s a lesson here around this widespread belief that just “sprinkling some AI” on any process or task will somehow magically fix it. I can’t tell you how many clients I work with that get more gains from automation and process improvement than they would from throwing AI at a broken process.)

If you’re staring at your own close wondering where to start, that’s usually the tell. Look for the number that already exists somewhere in your systems, but takes four people and two days to reach the person who needs it. That’s almost never the sexy AI use case. It’s the shortest path between data existing and data being useful … and it’s usually sitting in plain sight.

I spent years chasing the same shape of problem in different clothes.

By 2021, mine was a chatbot.

I spent an embarrassing number of evenings in the AWS console building this thing with Amazon Lex, the same technology under the hood of Alexa (if you can believe that a device that mishears “play jazz” as “play Jaws” was once considered the cutting edge of natural language understanding). Lex paired speech recognition with a bit of natural-language guesswork. You taught it a handful of ways someone might ask a question, and it matched what it heard against that list. No learning on the fly, no generalizing beyond what you’d built; just a very good version of something fundamentally limited: a search engine with a friendly voice. In 2021, that still felt like magic.

I was convinced I’d seen the future.

In a way, I had. I just hadn’t realized how far away it still was. My bot couldn’t reason about a number; it could only report one. I wrote about it in my first book, Deep Finance,mostly to prove you didn’t need a computer science degree to start playing with this stuff! What I didn’t fully appreciate at the time was that Lex, like almost everything finance had automated before it, was deterministic. Same input, same output, forever. That’s the DNA running through every ERP workflow and RPA script finance has ever deployed. My chatbot was a museum piece before I’d even finished building it.

That DNA goes back further than any of us like to admit. One of my first employees, early in my finance management career was a purchasing manager who tracked every invoice and PO in an actual paper ledger. Seriously. A paper ledger … pen, ruled columns, the whole thing. I know I’m old, but this was the early 2000s, and even then it looked like an artifact from another era.

Paper ledger » data lake » Lex bot to agent harnesses (which I can’t stop building in 2026): it’s one continuous line, and Friar is just standing twenty years further down the track.

Generative AI is the technology that finally broke that line’s deterministic ceiling. It doesn’t just match your words against a list. It can read a variance, weigh context, and draft an explanation nobody typed in advance. That’s new, and it’s also exactly why the harness matters now in a way it never did for a rules-based engine. A rules engine can’t hallucinate. And a model that can draft board-ready variance commentary can also draft a confidently wrong explanation for why gross margin moved 240 basis points … and it’ll sound just as sure of itself either way.

That’s the part of Friar’s essay worth thinking more about ...

She’s not describing full autonomy. She’s describing a close where AI collects and drafts, and a person still decides. Low-stakes work clears on its own, and anything that matters lands on an actual human’s desk. I wrote about this exact structure in AI Mastery for Finance Professionals a couple of years ago. We were talking about zero-day close back then for sure, but the path to get there was more convoluted (lots of deterministic automations that were great in theory, but overly brittle.) And it’s worth saying that all of this is really more of an oversight concept. The close is just where the friction shows up first.

It also helps explain why this feels urgent right now and not five years ago. The 2026 FP&A Trends Survey found that finance teams are spending 47% of their time on data collection and validation. This is the highest share in five years, and worse than it was before any of this AI investment started. All that automation and somehow the end result is that the collecting got harder, not easier — mostly because more systems means more places for the same number to disagree with itself. Zero-day close is (among other things) a bet that AI can finally win that argument faster than a human can.

And here’s the number that should keep everyone from getting too starry-eyed about how close we actually are: Vals AI runs an independent benchmark called Finance Agent v2, testing models on the kind of realistic analyst work a close actually requires. As of August 1, the best-performing model on that leaderboard scored 58.6%. Which is essentially an independent evaluator giving frontier models a C-, and telling them to “come see me after class.”

So … no, your close isn’t going to zero days next month or probably not even in the next year. (Let’s check this next August to see if we aren’t surprised.) But the direction hasn’t really been in question since that paper ledger. The more interesting question is where you draw the line between what AI collects, what it drafts, what clears automatically, and what still requires a human to make a call. Most finance teams haven’t drawn that line deliberately. The question we all have to answer is “Where is that line?”

That’s worth getting right. It’s also the part nobody outside your building can do for you.

Friar's team is redesigning the close for one company. This week's Pro edition gives you the version that works for yours.

Subscribe now

My latest book, The AI Ready CFO, is coming next month from Wiley Finance. Pre-order your copy now.

Friday’s free article ended with an assignment: pick one workflow, set one baseline and run a single cycle. Then answer the three questions. I received a few questions on how to select a workflow and how exactly to measure it. My knee jerk reaction was, “Buy the book!”

Read more

In the beginning, a lot of my demos felt like “parlor tricks,” where I showed people how this magic new tech could do seemingly anything we asked it. I did countless presentations for people who had spent their careers reconciling reality back to the general ledger. Feed the model a messy trial balance, ask a question, and watch it draft in 90 seconds the variance commentary an analyst would have spent half a day building.

My wife, Kerith, actually came to one of these conferences with me. She was sitting in the crowd next to a controller who was simultaneously taking notes and following along with my prompts as we worked an exercise live in the auditorium. She said about halfway through the presentation, he just closed his laptop and said aloud, “Well, there goes my job.”

Many of my sessions had those existential moments where we all saw the potential, and with the pace of advancement I think we all had those forecasts where we would reach Artificial Super Intelligence in a matter of months, and we’d all be working for the bots by the end of the year. ASI suddenly felt less like science fiction and more like a quarterly risk factor!

I routinely preached then (and still do) that AI changes tasks, judgment endures, roles evolve, and the people who learn the tools come out ahead. That whole “AI won’t replace you, someone using AI will replace you” mantra. I still believe that today. But the thing is, EVERYONE is using AI today.

I rode the wave of inflated expectations along with everyone else … and anyone claiming they weren’t riding that hype train during that period either has an unusual memory or kept better notes than I did.

I know we’re still soaring like a rocket in the AI space, but expectations have perhaps settled a bit. (I might be wrong here … I probably sit in a slightly different atmosphere than people who don’t live in this world 24/7.) But we’ve all kind of learned at this point where the models shine, and where sometimes they fall completely flat on their faces. The technology, of course, continues to evolve at a breakneck pace (Hello, agents!). They are much better at performing long-range tasks end-to-end, and the frontier labs keep shipping connections and capabilities that go well beyond raw model intelligence.

All of this is still worth learning.

But I’ve been out on the bleeding edge of this since before anyone said “generative,” and I can feel the ground shifting. Knowing how to use the tools is becoming table stakes. The differentiation has moved further down the line.

Share

The adoption question is settled

“AI usage” is barely even an interesting number anymore. Gallup’s second-quarter survey of 22,573 US employees found that 52% now use AI in their role, with 30% using it a few times a week or more, and 15% using it daily. Organizational adoption jumped six points in one quarter, to 47%, which is the biggest quarterly jump Gallup has recorded. And look at what those users report doing with AI in hte most recent surveys: writing and editing tops the list at 51%, with search and research close behind at 49%. Useful work. Also the same work everyone else’s team is doing with the same tools.

McKinsey’s latest State of AI survey puts 88% of organizations using AI in at least one business function — up from 78% a year earlier. And the Federal Reserve, an institution not exactly known for chasing the latest shiny object, published a statement estimating that 78% of the US labor force works at a firm that has adopted AI. The Fed tracks AI adoption the way it tracks employment now. Adoption is no longer a trend to debate. It’s a variable.

A capability distributed this evenly isn’t an advantage. Half the workforce uses AI.

So What’s the Problem?

Usage has outpaced operating discipline.

I frequently talk about the two ways companies adopt AI. The most ubiquitous is the bottom-up rollout, where a company gives their employees access to an AI tool (or tools) and lets their teams run wild. (Usually with an acceptable usage policy, training, and appropriate guardrails … but not always.) The second is the top-down rollout. This is where companies build and deploy tools at the enterprise level and guide their employees on how to use them.

That same McKinsey survey I referenced above found that only 7% of respondents report AI fully scaled across their organizations. The story is similar for AI agents: 23% are scaling an agentic system somewhere … most of them in one or two functions, but no more than 10% are scaling agents in any given business function.

Microsoft’s 2026 Work Trend Index surveyed 20,000 AI users and found that 16% qualify as what it calls Frontier Professionals: people who routinely redesign how the job gets done and build repeatable, documented practices that scale past the individual. Who are these people, you ask? The group skews toward finance, with 11% sitting in finance and accounting roles. Interestingly the people closest to the controls are the furthest along. Honestly, that shouldn’t surprise anyone who has ever met a controller.

So the picture as we roll through Q3 of 2026:

• 52% of workers use AI,

• and 7% of companies have scaled it.

The gap between those two numbers is where competitive advantage will live for the next five years. The question worth a CFO’s time is what the seven percent know that everyone else doesn’t.

This Isn’t New

If this sounds eerily familiar it’s because we’ve seen this movie (and its 19 sequels) before. We spent 30 years talking about “digital transformation.” Budgets, steering committees, ribbon cuttings, keynotes with the word “journey” in the title. But did we ever actually transform?

I’ve said before that I never liked the word “transformation” in this context because it made the whole “journey” sound like a one-and-done operations. For those riding this wave, it’s felt more like an evolution. And AI is just the latest part of that.

So what happened along the way?

Companies modernized systems without modernizing decisions. They implemented ERPs, but kept running their business on emailed spreadsheets. They built dashboards and set up self-serve data marts, but then devolved into semantic arguments about KPI definitions in board meetings. They bought “single sources of truth,” and spent half of every month debating whose definition was correct. And how much planning was done on a planning platform vs. Excel? So the systems changed, but the decision behavior lagged.

Now AI is set to re-run that pattern on a compressed timescale. Put modern tools into a legacy decision culture, and you end up with a token-maxxed, more expensive version of the same habits.

Microsoft’s research backs the diagnosis. Organizational factors like culture and manager support account for roughly twice the AI impact of individual mindset and usage. The workers are ready. The operating models aren’t.

This is the problem I spent the last year working on in The AI-Ready CFO.

Then What do we Do?

The difference isn’t the tools themselves. (At this point, the benchmarks are so close across the frontier labs that the models themselves are almost commoditized. Yeah … I know … this isn’t the standard for when a product reaches that point, but right now the biggest differentiators are more around features than model intelligence.)

The differentiator is a company’s internal machinery.

The organizations capturing value from AI today run a system that turns experiments into evidence and evidence into scale. And they run AI the way finance already runs everything else: with a cadence, controls, decision gates, and an owner.

In the book, I call these base unit of that system the “Minimum Governance Pilot,” or MGP. The MGP is a self-contained 90-day cycle with an accountable owner, a baseline of metrics, approved data boundaries, a human in the loop, and a decision at the end.

Subscribe now

Every MGP has to answer three questions:

• Does this use case create measurable value?

• Can it operate safely within our controls?

• Is it repeatable across other workflows?

Three yeses establish a pattern, and those patterns become scale. As an added benefit, this structure also hands the CFO a common language with IT, compliance, and the board: We are running three MGPs this quarter, two are scaling and one retired. That sentence replaces an hour of slideware.

And oh, by the way, a no is also a result. A pilot that fails cleanly costs a single cycle. Whereas, a pilot that drifts for a year with no decision costs the program. Because drift is what teaches an organization that AI initiatives never conclude anything.

About the governance layer: minimum governance means no unnecessary control. It is the least structure required to produce credible evidence, and nothing past that. Prompts get versioned, outputs get logged, human reviews get captured, and the whole trail lands in an evidence pack an auditor can inspect rather than reconstruct from chat histories and meeting notes.

Built this way, governance speeds up deployment, rather than slowing it down. Because nobody upstream has to guess whether the thing is safe. (That “guessing” is what takes six months and kills a project in a long, slow, brutal manner.)

The cadence has outside validation too. MIT’s data found top-performing mid-market companies moving from pilot to full implementation in 90 days. The winning cohort already runs on quarters, so finance should feel at home here.

The MGP sits inside a larger architecture the book walks through in detail. The First-90 rhythm sets scope and metrics before anyone touches a model. “Copy-with-variation” means each completed pilot leaves behind prompts, eval templates, and evidence packs that the next pilot reuses. So the second deployment costs a fraction of the first.

Wave planning sequences the program from quick wins into core processes and then into decision support. And the evidence pack answers an auditor’s questions in one file instead of one frantic afternoon. Run this way, the organization stops funding anecdotes. It compares pilots on a common record and reconciles promised value to realized value before another dollar goes out.

The next three years

The last three years rewarded individuals who learned the tools. The next three will reward organizations that redesign the operating model around them. Both are real work. Only one is still scarce.

That operating model is the subject of The AI-Ready CFO, out September 29, 2026 from Wiley.

Pre-Order The AI-Ready CFO

And here’s a place to start before the book arrives: pick one workflow, set one baseline, run one 90-day cycle, and answer the three questions honestly. If the idea can’t meet that bar, it’s not ready for finance. If your whole AI program can’t meet it … well … Now you know what the seven percent know.

That world is shifting under our feet. Last week, BlackLine introduced Verity Prepare. High Radius markets agents that match …

Read more

The first exception is an invoice posted twice. No problem. Barely an iconvenience.

Share

The second is a payment recorded on the final day of the month, but cleared by the bank two days later. Also easy.

The third involves an F/X adjustment and an email from Treasury that begins, “As discussed,” which is corporate shorthand for “somebody understands this, but that person is no longer participating in the conversation.”

The fourth exception is $38.42.

By 9:06 p.m., the $38.42 has acquired its own Slack thread, two screenshots, and an emotional significance wildly out of proportion to its monetary value. The supporting workbook is called Cash_Recon_FINAL_v7_USE_THIS_ONE.xlsx, a filename suggesting that six earlier versions have been rejected by people who remain unwilling to delete them.

Inside are twelve tabs, three hidden worksheets, links to two supporting PDFs, and a yellow cell nobody is prepared to touch. The agent assigns the item an 87% probability of being a “timing difference.” The senior accountant agrees that it’s probably timing. The controller asks what “probably” means in this context. The analyst who prepared the original file is now offline.

Kevin has left the building.

The $38.42 now tests the whole system. The agent has to preserve the evidence, expose its uncertainty, route the exception, and record the final decision. That is the standard for AI doing real finance work.

An agent enters the close

On July 27, BlackLine announced the general availability of Verity Prepare, a multi-agent AI system built to prepare account reconciliations. According to the company, the agents analyze supporting documents, match transactions, identify reconciling items, explain variances, and compile the finished package for human sign-off. Each recommendation includes reasoning, a confidence score, and an audit trail.

This moves the agent from the edge of the close into the work itself.

Reconciliation preparation consumes an impressive amount of human hours. Someone retrieves the ledger balance. Someone else finds the bank statement, subsidiary ledger, payment report, invoice support, and whatever other document this particular account has decided to require. Then another person matches transactions, investigates breaks, drafts explanations, and assembles the evidence. And, finally, a reviewer opens the workbook, adds comments, and …

requests another version.

The revised workbook receives a new name. This is where finance departments display their creativity:

Cash_Recon_FINAL.xlsx
Cash_Recon_FINAL2.xlsx
Cash_Recon_FINAL2_MHcomments.xlsx
Cash_Recon_FINAL2_MHcomments_USE.xlsx

And in 2026 … this is still how institutional knowledge is preserved in many modern companies. (Come at me, if I’m wrong!)

Blackline says that Verity Prepare is designed to handle much of that prep. They say its agents can ingest structured and unstructured evidence, perform analysis normally completed in Excel, isolate anomalies, draft reconciling items, and assemble the account for review. The company reports that early adopters reduced manual preparation time by as much as 92%. Sure, that’s a vendor-reported result from an early-adopter program … and finance teams will need to test the system against their own accounts, policies, source data, and close calendars, but this is hopefully an early view of the future of AI agents doing actual work in finance.

(The 92% figure measures preparation time. Finance still has to determine whether the resulting work can be reviewed, challenged, and replayed.)

The Blackline agent is producing work that may enter the financial record. Presentation quality won’t carry that burden. A polished explanation can still be wrong.

A green status indicator can conceal a bad match, and a confidence score can look scientific while leaving the controller with the same question raised by the $38.42 exception:

What does 87% mean for this account?

Subscribe now

The workbook has to show its work

A language model can write a plausible explanation for almost any difference between two balances. Give it enough context and it will mention cutoff, timing, foreign exchange, accruals, settlement dates, or several other terms commonly found near the end of a close.

But the account only ties out when the evidence supports the conclusion.

The reviewer needs to see what entered the workflow, which transactions the system matched, what it excluded, which criteria it applied, and why it classified an item as an exception. They need a defined approval path. And the auditor needs to reconstruct the decision months later … long after everyone involved has forgotten the details and now Kevin has changed departments.

But the sequence should remain visible:

The system retrieves the ledger balance and supporting documents. It applies the matching criteria, clears routine items, and flags unresolved ones. Each exception remains linked to its source. The workflow routes the item to a qualified reviewer, who approves, edits, or rejects the proposed treatment. The system logs that action and preserves the supporting evidence.

Remove the source link and the reviewer has to hunt for support. (Not good.) Omit the exception log and the audit team has to reconstruct what happened. Leave the approver unnamed and responsibility becomes a group activity, which is a dependable way to ensure that nobody owns it.

Finance has traditionally assembled much of this evidence after the work is finished. The transaction gets processed, the workbook gets approved, the support gets saved (somewhere), and later someone prepares the audit package and discovers that a link points to a former employee’s desktop.

Think about how this is different if an auditable system does the work:

An agentic workflow can collect the evidence while the work runs. It records the source, the procedure, the result, the exception, the review, and the approval. The completed reconciliation arrives with its history attached.

Without that record, automation moves the archaeology downstream. Several months later, when an auditor asks a calm and reasonable question: “What happened here?” The finance team begins digging through archived email, shared drives, Slack history, and a folder called Old Desktop. Someone eventually finds the answer. Nobody can explain why it was stored next to a photograph from the office holiday party.

The remaining queue gets harder

The accountant spends less time collecting documents, copying balances, matching routine transactions, and drafting the first explanation for an obvious timing difference. What remains in the queue is the work the system can’t clear with enough confidence.

Those items require judgment.

• Is the exception real?

• Does the explanation fit the evidence?

• Should the item clear automatically next month?

• Does it indicate a cutoff problem, a mapping error, a duplicate posting, or a control that has failed quietly for three periods?

An 87% confidence score sounds precise until somebody has to approve it. The controller still has to decide whether 87% is acceptable for this account, this amount, this entity, and this reporting period. The score informs the review. It doesn’t complete it.

The amount alone doesn’t settle the question. A $38.42 difference in one low-risk account may deserve little attention. The same difference repeated across 40,000 transactions could reveal a process defect with could reveal a process defect likely to outlast the tenure of everyone involved.

A manager who previously inspected every line can concentrate on exceptions, unusual patterns, confidence thresholds, and overrides. That focus can improve the review because attention moves toward the work carrying the most risk. It can also produce ceremonial clicking.

So … The package arrives complete, all the boxes are green, the explanations use full sentences, and the reviewers doesn’t see any obvious problems, but now the close calendar has become openly hostile … and the approval button is right there.

A human in the loop becomes a control only when that person can evaluate the output, challenge the evidence, and document the decision. The reviewer needs to know what the agent tested, which data it used, where its confidence dropped, and what remained outside its scope. The workflow should preserve evidence that the review occurred.

The scope here is that the agent narrows the field, and (as you’ve heard me say before) the accountant owns the conclusion.

The replay test

Before approving an agent for reconciliation work, I would ask one question:

Can the controller replay a completed reconciliation from source document through final approval without rebuilding the process manually?

Replay requires more than opening the final workbook. The controller should be able to see which documents the system used, which transactions it matched, which criteria it applied, which items it flagged, what explanation it proposed, who reviewed each exception, what the reviewer changed, and who approved the final result.

The sequence should survive the departure of the analyst, the passage of time, and the arrival of an auditor who has never heard of Kevin.

BlackLine says Verity Prepare records its reasoning, confidence scores, actions, decisions, and supporting evidence while leaving final approval with the finance professional. The product will now encounter the conditions that make close automation difficult: inconsistent account structures, late-arriving source data, policies full of exceptions, and reviewers with thirty reconciliations waiting before dinner.

Finance agents are moving beyond drafting and summarizing. Their work now touches the close, the control evidence, and the financial record. A useful agent has to execute the procedure, expose uncertainty, route the exception, preserve the support, and leave a record that another person can replay.

Where did we start this thing?

Oh yeah …

Now it’s 9:32 p.m., and Kevin’s back.

The $38.42 is a bank fee. He documented it in Cash_Recon_FINAL_v8_ACTUAL.xlsx, although the support is attached to the wrong tab and the yellow cell remains unexplained.

The controller approves the account at 9:41. The system records the evidence, the reviewer, the decision, and the timestamp.

Kevin is free to leave the building again.

Building systems where AI agents handle the prep and humans handle the judgment isn't just about saving time - it's the future of financial controls. This is exactly the kind of operating model I develop in The AI-Ready CFO, available September 29 from Wiley.

Pre-Order Now

I keep coming back to something I said on that Agicap call almost as an aside: think about a new agent the way you’d think about onboarding a human analyst. You don’t hand them a laptop and walk away. You give them a task queue, a policy …

Read more

Two regulators on opposite sides of the world drew the same boundary. That kind of convergence suggests the boundary is structural, and it’s the exact question I recently worked through live on a webinar with Agicap’s Brandon Barnes: not whether AI can run treasury, but how much of it has earned the right to run without a human watching.

The Monetary Authority of Singapore’s new SAFR framework sorts agent activity into three buckets: payments and treasury, wealth advisory, and client engagement. Each gets its own mandate, real-time validation, and audit log. Notice that MAS didn’t ask whether the model is smart enough. It asked what happens when the agent is wrong … and how fast someone can catch it. That’s the same test I’ve been running with clients for a year (minus the government letterhead).

Share

On the call, Brandon asked me the question every CFO eventually asks: How do you decide what AI runs on its own vs. what it should collect and hand to you? One easy framework is to think of it as a simple binary boundary: collect vs. decide.

I have a client that runs more than a dozen QuickBooks Desktop entities (I know, right?), and consolidation used to eat a day every month. Now an agent pulls it, ties out the intercompany eliminations, and hands over a finished workbook.

That’s “collect.”

Nobody’s moving money. If the number’s off, I’ll catch it in the time it takes to open the file.

Payment execution doesn’t get that same leash. An agent can match the invoice to the PO, flag the vendor that doesn’t reconcile against the master file, and stage the wire, but it stops there. Our workflow requires a human to releases it. I think of it the way I’d think about a smart, eager intern in their third year of college: I’ll let them touch almost everything, but I’m not handing them the checkbook.

Three things to incorporate into your next planning meeting:

• Score two variables, not one. What happens when the model is wrong, and how fast can a person verify the output? (Note that model quality isn’t a key factor here.)

• Consolidation and variance analysis are autonomy’s easiest win. They’re read-heavy, reversible, and reconcilable against known numbers.

• Regulators are converging on the same architecture finance teams already use informally. MAS’s three-bucket sort tracks closely to collect, stage, and gate.

Bonus: What The AI-Ready CFO Says About Letting Agents Near the Cash

On the surface, treasury might look like the easiest sell in the whole finance function. The data’s structured, the workflows repeat, and half the vendors in this space already built the tooling. My book, The AI-Ready CFO (Wiley, September 29, 2026), spends a full chapter arguing the opposite.

The book scores any AI-enabled workflow on three dimensions instead of two:

• Magnitude: how bad is it if this fails.

• Frequency: how many chances does the system get to be wrong.

• Recoverability: can you catch and reverse the damage before it lands.

Plot magnitude against frequency, layer recoverability on top, and most finance workflows sort themselves pretty cleanly.

Cash forecasting and liquidity planning are high magnitude and low frequency. The errors are rare, but when one shows up, it’s impactful … and depending on the magnitude, potentially existential. The guidance for that quadrant is specific: model the downside scenarios instead of assuming them away, carry a risk-adjusted contingency reserve in the project cost, and get board sign-off and legal review before anything launches. AI has its place, but only as decision support. The go/no-go call stays with a person who can be held accountable for it.

Segregation of duties is the first control to break when an agent starts touching more than one step. A system that processes a transaction, codes it, and routes it for payment can’t also approve and release that same payment; and automation doesn’t get an exception to that rule because it’s efficient. It makes the violation harder to spot. One agent spanning four steps looks like a clean workflow, until an auditor asks who reviewed what. The fix isn’t clever. Keep processing, approval, and release in separate hands, set conservative thresholds on any auto-approval logic, and test those rules on a schedule to confirm they still work the way they were built.

None of this keeps treasury manual forever. Instead, it tiers oversight by risk. Routine sweeps and low-value intercompany transfers clear on their own and get sampled after-the-fact, anything mid-risk gets dual review, and anything material reaches a person — every time. The CFO’s job is setting those thresholds and making sure the evidence survives the audit.

Which is the theme I keep coming back to across the whole book: AI Recommends, but humans approve.

The AI-Ready CFO publishes September 29 from Wiley.

Pre-Order Now

The pro edition walks through the full scorecard I use with clients, the actual near-miss that changed how I think about who builds these agents, and why the token bill is the wrong thing to be arguing about right now. The full session, Agentic AI in Finance: Where to Automate and Where to Stay in the Loop, ran live with Agicap earlier this month. It’s built for CFOs, controllers, and FP&A leads who already have AI in their stack and are working through how much of it to trust. If you were on the call, you already have some of this. If you weren’t, the recording is here: https://event.agicap.com/webinar/agentic-ai/.

Unlock the full model and templates:

Subscribe now

You give it to an agent that gets the task right 95% of the time. That sounds excellent, right? It’s probably better than anything you’re running with AI right now.

But a 95% success rate still produces ~12 exceptions per year. Someone has to handle every one of them.

Now ask a different question: What are the odds the agent runs clean for the entire year?

That’s 0.95 raised to the 250th power. The result is effectively zero.

That’s not a failure. It’s how real deployments work. The problem is that most finance teams have never run this calculation on their own workflows. The number they need isn’t published anywhere. They have to produce it themselves.

So let’s produce it.

Why the Published Number Is the Wrong One

Most benchmarks report pass¹: Run the task once. Did it work?

That’s the number shown on leaderboards, in product demos, and on vendor roadmaps.

Your close needs a different number: pass^k. Run the same task repeatedly. Did it work every time?

Tau-bench introduced this measure in 2024, and the gap it exposed was severe. GPT-4o scored roughly 61% on retail tasks using pass¹. By pass⁸, the score fell to about 25%.

Same model. Same tasks. But when the model had to perform reliably eight times in a row, nearly two-thirds of the apparent capability disappeared.

There’s no comparable pass^k result for the frontier models finance teams are using in 2026. The tau-bench leaderboard stopped with the late-2024 model set. Sierra, which created the benchmark, expected other labs to compete on it, but that never really happened. The labs moved on to successor benchmarks and began publishing their own averages.

The measurement exists, and the method is public. The number for the model running inside your workflow isn’t.

That part is now your job.

Reliability Depends on the Nature of the Work

A reliability study published this spring ran 23,392 episodes across 10 models and 396 tasks.

Average success fell from 76.3% on short tasks to 52.1% on the longest tasks. More important, performance didn’t decline in a straight line. It deteriorated faster as the tasks became longer and more dependent.

The most useful finding sits below the headline.

Read more

So one number matters more than the rest: how many actions an agent gets right in a row.

Two-thirds of the AI agents running in production today take fewer than 10 steps before a human takes over. Nearly half stop before five.

Four steps: read the invoice, query the ledger against it, compare the two, flag the gap. That's roughly what a junior analyst gets through before they'd stop and ask you something.

So an agent on a five-step leash hasn’t automated your reconciliation. It’s done the first five steps, then handed the thing back. Everything after that is still payroll.

Finance is pricing headcount as though the leash weren’t there.

What got better

Credit where it’s owed. Agents that used to fumble a 10-minute job now grind through multi-hour ones, and the length of job they can finish has been doubling roughly every 131 days since 2023. That compounds. It’s why this question landed on your desk in 2026 instead of 2029.

That number comes from METR, a nonprofit that gets frontier models before the labs release them and publishes what it finds. It’s the closest thing the field has to an outside referee, which tells you something about the field.

Read the fine print, though. The headline is the length of task a model finishes at 50% success. Half the time. METR’s 80% horizon is several times shorter, and METR now flags anything above 16 hours as unreliable, on the grounds that the models have outrun the test suite. Meaning, the ruler is shorter than the thing it’s trying to measure.

Share

What’s running

Those step counts come from Measuring Agents in Production, a survey of systems already deployed and running.

Short leash … with a person at the end. That’s the shipping product, right now.

The best-documented finance case in circulation proves it. The FSB’s June consultation report describes a large international bank that built an agentic fraud system in-house in three months. It watches more than 80 million signals a day and proposes new detection rules.

A person on the fraud team approves each rule before it goes live. That system drove three-quarters of the bank’s card-fraud rule updates and helped cut fraud losses more than 20% in the first half of this year.

Three months, 80 million signals a day, and it shipped that fast because a human approved the rule, not despite it.

Klarna ran another experiment. Its OpenAI-built assistant handled 2.3 million conversations in a month and cut resolution time from 11 minutes to under two, doing the work of 700 service reps.

Then Klarna reversed. The CEO told Bloomberg that cost had been too dominant a factor, quality had suffered, and the company was hiring humans again.

Two experiments, one finding.

None of which is new … Netflix paid out $1 million in 2009 to the team that beat its recommendation engine by 10%, then never shipped the winning entry because the accuracy gain didn’t justify the engineering to run a hundred stacked models in production. It kept a simpler, earlier version instead. The leaderboard and the production system were asking different questions. That was 17 years ago.

Four ways in, and one of them didn’t ask

All four put an agent on roughly the same five-step leash. What changes is who holds it, and who explains it afterward.

Suite agents. SAP’s Joule, Oracle’s AP and revenue recognition agents, Workday’s financial test suite for continuous transaction auditing. These arrive with an upgrade you didn’t schedule. They live in the ERP, inherit your permissions, and meter you on consumption. When one reaches step six, the exception drops into a queue somebody else designed.

• Upside: it’s already there and your data doesn’t move.

• Downside: you inherit their audit trail and their opinion about how your close works.

Point solutions. One workflow, done deep. Basis raised $100 million at a $1.15 billion valuation in February and told Reuters it serves about seven of the top 25 US accounting firms. Ramp shipped an Accounting Agent, and Fazeshift is going after AR. Each is a separate integration, a separate login, and a separate answer when someone asks who approved the entry.

• Upside: depth in one workflow.

• Downside: the gaps between them are yours, and each is its own liability conversation.

Hybrid orchestration. Buy the model, build the logic yourself. The FSB’s bank shipped in three months this way, and three months is fast because the model was the easy part. Knowing which fraud rules mattered and who approves them took the bank years. It already had that.

• Upside: the control surface is yours, which matters when a regulator asks you to replay a decision.

• Downside: you own the data engineering, and you own it every year after, not once.

The one nobody inventoried. Somebody on your team already built something in a chat window that works. It may not even be software. It might be a person pasting a ledger extract into a browser tab twice a month and pasting the answer back. It never went through procurement, so it isn’t on the software list, and its blast radius has never been measured.

• Upside: free, fast, already working.

• Downside: nobody knows it exists until it’s in the board pack.

Guess which one is in this quarter’s reporting package.

Why the leash is five steps

Most benchmarks report pass¹. Run the task once, see if it worked.

Pass^k asks the harder question: run it k times, did it work every time? Tau-bench introduced the metric in 2024, and it’s the one that matches how a control runs. A reconciliation you perform 250 times a year needs to be right 250 times.

On tau-bench, GPT-4o scored about 61% on the first try. By the eighth run it was down to 25%.

(Yes, GPT-4o. That was way back in 2024, and it’s the most recent published pass^k there is. The tau-bench board froze at the late-2024 model set, and its top entry is still Claude 3.5 Sonnet. Sierra, which built the benchmark, expected a leaderboard race, with each new model touting a better consistency score. The labs went to the successor benchmark instead, where they report their own averages.)

A reliability study this spring ran 23,392 episodes across 10 models and watched success fall from 76.3% on short tasks to 52.1% on long ones, steepening as it went. Same paper, and this is the line that matters: capability rank and reliability rank diverge.

The model on top of the leaderboard is frequently not the one that fails least. And the leaderboard is how everybody builds a shortlist.

The pass^k curve for a 2026 frontier model isn’t published anywhere, and not because anyone’s hiding it. Running one long task eight times across 10 models is slow and expensive, and nobody in the field is graded on it.

So it doesn’t get done. The number that decides whether your close survives contact with an agent doesn’t exist, because producing it would be tedious.

Finance inherits the gap.

Nobody chose the five-step leash. A few thousand teams found it separately, each one doing the arithmetic the hard way.

The jobs math doesn’t tie

Challenger counts 101,743 US job cuts attributed to AI through June, nearly double all of 2025.

Total announced cuts over the same period: 443,604, down 40% from last year.

So layoffs are falling, while AI attribution nearly doubles. Employers aren’t cutting more. They’re relabeling why … because “we deployed agents” reads better on an earnings call than “we hired too many people in 2022.”

Which is why Citi’s Q2 repays a close read. CFO Gonzalo Luchetti told analysts that efficiencies had let the bank reduce headcount to 219,000, with more than $800 million of severance year to date. Then, separately, that Citi keeps investing in AI and expects productivity saves “over time.”

The severance is booked. The AI savings are a forecast.

Takeaways

• First-run scores. They tell you what an agent can do. Your close cares what it does in March.

• Measure your own. Run your workflow k times and count what comes back clean. Nobody is going to hand you that number.

• The gate is the accelerant. Every deployment that works is short-leash and human-gated. The FSB’s bank shipped in three months because of the gate.

• The real math. Your exception rate sets the headcount. Your automation rate sets the slide.

What’s in Sunday’s Pro edition

This half made the argument. Sunday hands over the tools.

• The Agent Reliability Scorecard, in Excel. Log k runs of any workflow and it returns your observed pass^k, your cost per clean completion, and your true exception rate. Blue cells are yours to fill.

• The posture selector. Score a workflow on control surface, data readiness, replay requirement, and blast radius. It returns Buy, Build, Hybrid, or Hold, and it tells you why.

• The replay file. What you have to be able to demonstrate when a regulator asks why an agent made a decision, why SR 26-2 put agentic AI outside its own scope in April and left you holding it anyway, and what Colorado’s deployer-liability standard has meant since June 30.

• The cancellation math. Gartner’s projection for how many agentic projects die before 2027, MIT’s count of pilots that never touched P&L, and how to use both as inputs to your own deploy-or-hold call rather than as headlines.

• A seven-prompt pack, structured ROLE / ACTION / CONTEXT / FORMAT, so you can run the scorecard without me.

Unlock the full model & templates:

Subscribe now

Point an agent at your bank feed and it'll have a thirteen-week cash forecast built in about the time it used to take to open the spreadsheet. Give it one more permission and it can send the wire, too. That second step requires guard rails … and a fair amount of careful consideration.

I keep landing on the same question with finance teams: how much of the work do you actually let an agent run on its own? Cash positioning and a payment release sit at opposite ends of that answer, and most teams haven't drawn the line between them.

This Thursday (July 16, 2026) I'm sitting down with Brandon Barnes of Agicap to map exactly that: one workflow at a time across treasury, plus where MCP is changing the risk picture underneath it all. Brandon will run a live demo, and we're leaving plenty of room for your questions.

This session is built for finance teams who already have AI in the stack and are working out where to give it room, and where to keep a hand on the wheel.

Free to join.

Register Now

July 16, 11:00 AM ET / 5:00 PM CEST.

See you there,
Glenn

Define output before you measure it

“Output per token” is easy to say and hard to compute, and anyone selling you a clean, single number is … well … selling you something. Output shows up in different forms for different teams, it lags the spend that produced it, and attribution is messy. None of that is a reason to give up. It’s the same problem finance already solved for every other input it manages, where imperfect proxies beat no measurement at all, and the discipline is knowing exactly how each proxy lies to you.

Rank the proxies by how easily they’re gamed. The harder a measure is to fake, the more it’s worth … and usually the harder it is to collect.

• Code artifacts. Merged pull requests, deployed changes, tests passing. Concrete and available today. The trap is that volume games it. One study found code churn, lines written then quickly deleted, rose more than 800% under heavy AI use, so a PR count can climb while durable work does not.

• Knowledge artifacts. Drafts shipped, analyses delivered, models run, decks built. This is where finance, marketing, and operations actually show up, and it’s the layer most token dashboards ignore entirely. Same volume trap with fewer people watching for it.

• Downstream outcomes. Cycle-time drops, ticket deflection, revenue per rep, faster close. Much harder to fake and much harder to attribute cleanly, which is the tradeoff that makes it valuable. This is the layer a board believes.

• Judgment overlay. Was the work worth doing at all. No metric captures this, so a human has to. The productive, inefficient, or wasteful tag in the workbook is that judgment made routine, applied per session and rolled up.

Two data points explain the importance of that layering. Jellyfish found the heaviest token users were about twice as productive while spending 10x the tokens, so volume and value have already come apart in the data. And Gartner reports fewer than a third of decision-makers can identify specific financial outcomes from their AI investments. The gap isn’t a spending problem. It’s a measurement vacuum, and the proxy hierarchy is how you start filling it.

This section feeds the classifier tab. The tag is the judgment overlay; the roll-up is the productivity-of-spend read your provider dashboard will never hand you.

Tokens as COGS, worked

The reframe only pays off once it hits the P&L; and that starts with a split most teams haven’t made: Customer-facing inference is cost of goods. Internal productivity is operating expense. The same model lands in both depending on the job it’s doing. A support agent answering your customers is COGS. An engineer running Claude Code against your own repo is Opex … or capitalized development if it meets the bar. Sort every token line into one bucket or the other before you do anything else, because the two behave nothing alike on the way to the board.

But the split is important because tokens in COGS scale with usage, and if usage scales with revenue, your gross margin compresses as you grow unless cost-per-transaction falls faster than volume rises. That’s the number the board reads first, and a token line buried in a SaaS category will distort it without anyone noticing until the quarter closes. Tokens in Opex behave more like headcount, lumpy and forecastable, and they belong in the productivity conversation rather than the margin one.

For anything you sell with tokens riding inside it, the unit economics are the whole game. Cost per request has to clear comfortably below the contribution you earn per request, and that’s where routing stops being a hygiene tip and becomes margin defense. Sending a support classification to a frontier model isn’t a preference, it’s a gross-margin leak. Published cases show routing and caching together cutting 60 to 90% with no measurable quality loss, and the fattest single target is context, which runs about 62% of the agent bill when every step reloads the whole conversation. You aren’t trimming cost, you’re protecting margin.

This section feeds the routing decision table. Cost-per-task by tier is the input that tells you which requests are safe to keep on the expensive model.

Two runbooks, read as instruments

Uber is the runaway train here. The company gave roughly 5,000 engineers Claude Code and burned its entire 2026 AI budget in four months. And its own COO conceded the spend didn’t clearly track to features shipped. What did they measure? Adoption and volume. What they missed was whether the volume actually produced anything. The scoreboard was pointed at the meter the entire time, which is the failure the free edition described.

The turnaround is the mirror image. One team took an $87K April invoice down to $24K in May with routing, caching, and context pruning — and sprint velocity held flat. The difference was they classified the spend, found the waste, and cut it without touching output. The distance between those two invoices is the recoverable line, and it came entirely out of sessions that were never producing in the first place. Map your own situation onto one of these before you build the forecast, because the fix is different depending on which one you are.

Forecast it

Most token budgets are built through the path of least resistance: last month times a growth rate. And they break within a quarter because token demand doesn’t grow in a straight line. Build it driver-based instead.

Tokens = headcount by role x adoption rate x intensity per active user

This is phased along an adoption curve rather than a flat percentage. New hires ramp over a few months. Power users plateau. Agentic workloads step-change the day you deploy a new agent, and no smooth growth rate will ever catch that jump.

The commercial side follows from the same data. With real consumption history you can size a committed-spend tier instead of guessing, which carries weight now that pricing itself has moved. Anthropic split programmatic usage onto a separate metered credit pool in mid-June, and GitHub Copilot shifted to usage-based billing at the start of the month, so any budget set last fall is already stale. Finance leaders are responding by reforecasting quarterly and negotiating directly with the labs rather than defending an annual number nobody believes anymore.

This section feeds the savings estimator. The driver inputs are what turn a projected reduction into a defensible line in next quarter’s plan.

Budget the bots with the body

We need to reframe the way we think about AI spend. The fully-loaded cost of a hire used to be two lines: base comp + tax and benefits. It’s three lines now. Comp, benefits, and a token budget that travels with the person.

Model it per role. An engineer carries the largest token line by a wide margin, with Claude Code running $150 to $250 per developer each month for typical use and power users reaching $500 to $2,000. A financial analyst or a marketer carries a smaller line, though anyone living in these tools is not cheap either. The point for planning is that the moment you approve a rec, you have approved the bots that come with it, and your H2 headcount model should say so explicitly. Skip that and every hire sneaks in an unbudgeted variable cost.

The endpoint of this trend is already visible. Nvidia’s VP of applied deep learning told Fortune that for his team compute now costs more than the employees running it. Most finance teams are nowhere near that ratio today. The ones that model the token line per head now will not be surprised by it later.

Keep the scoreboard alive

An audit you run once decays by the next close. The cadence is what lasts. Instrument spend by team, model, and key daily. Give FP&A and a platform partner joint ownership of a weekly review. When a key spikes, notify and investigate rather than auto-capping, because the spike is often your most productive person mid-project. Monthly, take the productive-inefficient-wasteful mix to leadership as a standing KPI, so the scoreboard stays about output instead of drifting back to the total.

The durable control is enablement, not restriction. The 20x spread between two developers on the same tool closes with training, and organizations with mature AI-literacy programs report positive AI ROI at nearly double the rate of those without. A cap saves money once. A team that knows how to scope and route saves it every month, and produces more while doing it.

The prompt pack

Six prompts, structured Role / Action / Context / Format. Paste them straight into your workflow.

1. Session classifier. Role: FinOps analyst. Action: classify each AI session as productive, inefficient, or wasteful. Context: a usage log with task descriptions, token counts, and the model used per session. Format: a table with the tag, a one-line reason, and the recommended fix.

2. Model-downshift evaluator. Role: cost engineer. Action: decide whether a task can move to a cheaper model without losing quality. Context: the task description, the current model, and a sample of current output. Format: a verdict of downshift or hold, the target model, and one risk note.

3. Context-hygiene rewriter. Role: prompt engineer. Action: trim a bloated prompt and its context to essentials. Context: the full prompt, the system context, and the actual goal. Format: the rewritten prompt and an estimate of tokens removed.

4. COGS-versus-Opex sorter. Role: controller. Action: sort a list of AI workloads into cost of goods or operating expense. Context: a list of workloads with a short description of what each one does and who it serves. Format: each workload tagged COGS or Opex with a one-line rationale.

5. Weekly finance briefing. Role: FP&A partner. Action: turn raw token usage into a CFO-readable weekly brief. Context: this week’s usage by team and model, plus the prior week for the delta. Format: five bullets covering what changed, the driver, the COGS-versus-Opex split, a watch item, and an action.

6. Commit-tier sizer. Role: procurement analyst. Action: recommend a committed-spend tier from consumption history. Context: trailing three to six months of usage, the growth rate, and the provider tiers on offer. Format: a recommended commitment, the rationale, and the break-even against on-demand.

Run it this quarter

Download the Token-Efficiency Audit Workbook and the prompt pack below. Classify one team’s sessions against last month’s export, sort the workloads into COGS and Opex, and you’ll walk into your next forecast review with a recoverable number, a margin read, and a driver-based budget instead of a guess.

Download

Glenn Hopper spent two decades as a CFO before turning to the question this newsletter keeps circling: what AI actually costs a business, and what it's worth. He writes Deep Finance Dispatch and, through RoboCFO, helps finance teams instrument, forecast, and govern their AI spend instead of guessing at it.

Silicon Valley heard that as a challenge. And a management philosophy. Teams at Meta and Amazon built consumption leaderboards and ranked engineers by spend. Engineers gamed them.

Then the invoices landed … and the mood changed.

Conversations went from “Are we using enough AI?” to “What exactly did we just buy?”

Hold onto that second question …

The problem isn’t that AI is expensive

Finance knows expensive.

The problem is that AI is expensive in a new and frustrating way.

For 30 years, enterprise software has been mostly seat-based. You bought access by the number of users and got a knowable, explainable bill every month. A user could log in once a week or live inside the product like a raccoon in the HVAC system, and the bill stayed more or less the same.

Tokens broke that model.

Share

Assuming most of you already know what a token is, but to level-set for the unfamiliar: a token is the billing unit for AI usage ~ roughly a few characters of text going into or coming out of a model. It’s the meter running under the conversation.

Think of it like a taxi meter, except this taxi talks, uses a truckload of emdashes, can’t stop saying the word “quietly,” occasionally invents a street that doesn’t exist, and can low-key call up three more taxis to ride alongside you to help you reach your destination.

All while everyone you know asks you to justify what you spent on the ride that, oh by the way, keeps getting more expensive every month. “How are taxis better than horses, again?”

AI moved software cost from access to activity. The seat barely matters now. The work does. Which is how an army of coding agents running around the clock creates a five-figure monthly bill nobody forecasted, approved, or can really explain.

And the part that makes this especially fun for finance: the unit price can fall while the total bill explodes.

We kept score wrong

The knee jerk reaction is to Cut AI spend and cap usage. Find the overspend and squeeze.

That reflex is the same mistake that got us here, painted from a different angle. Token maxxing celebrated that running meter. Cost-panic mourns it. Both are staring at the same number, but neither is asking what came out the other end.

We gamified consumption because consumption was the first thing about AI we could measure. Tokens are visible, countable, rankable. So we ranked them, handed out trophies for burning the most, and mistook a rising number for progress. It’s the oldest error in enterprise tech, confusing activity with output, and we fell for it hard this time only because the activity finally had a dollar sign attached.

There are some things users can do to minimize token usage. A lot of people point out how we use the most powerful, biggest model by default. (If you’re gonna be a bear, be a grizzly … right?)

I think we’d all agree that using Fable to review a contract is like hiring an investment bank to reconcile petty cash. The result will be fine, but the economics are stupid.

Two developers on the same tool can land 20x apart on cost, driven mostly by which model they default to and whether they reuse context. Same tool, same seat, one bill twenty times the other.

And volume tracks value poorly: Jellyfish found the heaviest token users were about twice as productive while spending 10x the tokens to get there. More spend bought a little more output and a lot more waste.

Routing helps. So does caching, scoping, and writing a better prompt. But tightening the inputs is still an input game. It lowers the number without telling you whether the number was ever buying anything.

Trust your AI. But how much?

AI can forecast your cash position, flag anomalies, route approvals, and shorten the close. The adopt-or-not debate is over. The open question is how far to let it run before a human signs off.

Join me live on Thursday, July 16 at 11:00 AM Eastern when I’ll be sitting down with Agicap’s Joseph Gaide to map where that automation boundary actually falls, what stays autonomous, what needs judgment, and what agentic AI and MCP connectivity change for treasury and cash teams.

Built for CFOs, controllers, and FP&A leaders who already have AI in the stack and are working out how much to trust it.

→ Register here

Where your bill lands

For CFOs, it’s worth knowing where you sit before you cap anything.

Across one large sample reported a couple of weeks ago, the median AI customer spends about $136 per employee a year on tokens, the 90th percentile runs near $7,300, and the 99th percentile clears $90K. The spend lives in a thin tail of power users, mostly engineers, so a frightening company total usually traces back to a handful of individuals rather than a broad problem. (I’d love to see this cut for financial analysts. Not engineer-high, but for anyone in FP&A living in these tools right now, it can’t be low. Speaking from personal experience.)

Three other ways to check yourself.

• On revenue, companies expect to put about 1.7% of revenue toward AI this year, double last year’s 0.8%.

• On trajectory, the FinOps Foundation reports firms that were 3x over their full-year token budget by spring, with per-developer use up close to 19x in nine months.

• On the biggest line, coding, Claude Code runs $150 to $250 per developer each month for typical use, and power users reach $500 to $2,000.

Put your own number next to those and you’ll know quickly whether you have a spend problem or a visibility problem.

The meter was never the point

So here’s the turn (and it’s the least comfortable thing an AI optimist can say right now): Stop defending the spend, and start demanding the output.

For 30 years, software spend told you nothing about value. You paid the same for Salesforce whether a rep lived in it or never opened it. Utilization was invisible, so ROI on software was a story you told, never a number you had. Tokens broke that, and everyone is reading the break as bad news.

It isn’t.

A per-person, per-task bill is the closest finance has ever come to a direct readout of who is getting work out of these tools, and who is just running the meter. The invoice everyone’s panicking about is the measurement instrument we have been asking for. It just showed up dressed as a bill.

Which is also why nobody can prove AI ROI yet. We’ve been measuring the wrong thing the whole time: Seats deployed, logins, adoption rates, and now tokens burned. Those are all measurements of input.

Output is harder to count, so we counted the easy thing and called it a strategy. Meta’s own CTO was blunt when he pulled their leaderboard: token usage alone is not a measure of impact of any kind.

He’s right, and he’s on our side of this.

And so this is finance’s moment. Turning messy inputs into cost-per-unit is the entire reason the function exists. Cost accounting did it for labor-hours and raw steel a century ago. This is that same job, pointed at cognition. Finance is the one function built to construct the scoreboard that measures what got made per dollar, and the token bill is the richest raw dataset it has ever been handed. Capping the meter is beside the point. Change what it scores.

One honest caveat so we don’t oversell it: Perfect ROI-per-token is a trap, and chasing it will drive you up a wall. You don’t compute exact ROI on a payroll dollar either. You decide the work is worth doing, you staff it, and you watch the output over time. Same discipline here. Judgment and output accountability, not a decimal-point answer.

The reflex to cap is everywhere anyway. Tesla just held employees to $200 a week, joining Uber and a lengthening list. (Tesla users reportedly have unlimited access to Grok, but aren’t too keen on using it from what I hear.)

A cap rations your most productive people’s hours and leaves the scoreboard pointed the wrong way. The companies that win the next two years won’t be the ones who spent the least. They’ll be the ones that figured out what the spend produced while everyone else was congratulating themselves for hitting the brakes.

We gamified the meter, but the meter was never the point.

Takeaways

• Change the scoreboard. Track output per token, not tokens. Retire the leaderboard that rewards volume.

• Instrument first. Spend by team, model, and key, refreshed daily. You can’t forecast what you never metered.

• Tighten inputs, then keep going. Route away from the frontier model where it’s overkill, cache, and teach people to scope. Then ask what the leftover spend is producing.

• Judge it like payroll. Decide the work is worth doing, staff it, and watch output. Skip the hunt for a perfect per-token ROI.

One prompt to start

Paste last month’s usage into this and you have a first cut before your next forecast review.

Role: FinOps analyst.

Action: classify each AI session as productive, inefficient, or wasteful.

Context: [paste a usage log with task descriptions, token counts, and the model used per session].

Format: a table with the tag, a one-line reason, and the recommended fix.

The full six-prompt pack and the workbook that scores it live in the Pro edition, which runs the audit end to end: a spend classifier, a routing decision table with cost-per-task by tier, a savings estimator that projects the cut against your current run rate, and the prompt pack to drive it.

Unlock the full model & templates:

Subscribe now

You already run AI-built apps in production that you can’t list, can’t assign an owner to, and can’t switch off. The EU AI Act’s high-risk obligations start biting August 2 (CSA – Jun 2026), and this cycle’s first audit walkthrough will ask for every AI-built tool that touches financial reporting. No inventory, and the auditor writes the finding for you.

Read more

[Sending early this week ahead of the Independence Day holiday in the US.]

A couple of months ago I was training a RoboCFO client’s finance team on the advanced end of what Claude can do, and we got to the segment on vibe coding, where everyone learns to build and deploy their own apps. We’d just walked through the NetSuite MCP server, the role-based access and the guardrails Oracle already built into it. These are the kinds of rails that let you hand the tool to a controller and sleep fine. Then I said the part that’s been rattling around my head ever since …

Anybody can point an AI at a company’s financials. It takes about two minutes and literally zero training. But if you can’t reliably tell EBITDA from net income, or say why operating income sits between them, you won’t catch the model when it’s confidently wrong … and at some point it will be wrong in ways that look clean to the untrained eye. You need the domain expertise to know what you’re even looking at.

Same goes for the app you just vibe-coded. If you’re not an engineer or a security person, you don’t have the domain expertise to know which guardrails you’re missing, and you can’t put up a rail you’ve never heard of. A security pro looks at that same app and asks whether the database login it’s using can read one table or the whole thing, whether there’s a password sitting in plain text in the code, if the app is sitting open to the internet with no sign-in, or if anyone will ever know it ran. You didn’t ask any of those because you didn’t know they exsited. I was telling a room of smart, tech-forward people that the thing I’d just taught them to do was one they weren’t equipped to do safely and I watched it land.

Here’s the part I didn’t say: Both my insurance policies had come up for renewal that same week. Cyber liability, for when a client’s data ends up somewhere it shouldn’t, and errors-and-omissions, for when the client decides your advice put it there.

I was pricing my own downside and handing everyone else theirs in the same week.

That juxtaposition stung a bit.

So I softened the training. I’d been slipping caveats in all week without quite noticing: use fake data for now, don’t wire anything into the real systems, loop in IT before this goes near production, and please don’t point it at the live ledger. I was teaching a declawed version, because the full version felt like dropping them into a Ferrari, pointing them at the test track, and sending them off with no seatbelt. And the only guardrail actually in the room was me, standing at the front hoping everyone remembered the caveats after the coffee wore off.

You can’t insure your way out of a fire you can see coming. Sooner or later somebody has to go move the matches.

(I realize I’m mixing metaphors again, but you get it.)

The reviewer is gone

Back in May I ran the body count. Israeli researchers scanned roughly 380,000 apps built with AI coding tools and found about 5,000 leaking corporate data, internal financial records and sales files and strategy decks sitting on the open web for anyone who typed the URL. Finance was in the blast radius. The short version, if you missed it: the apps shipped public by default, and nobody flipped the setting.

What’s stuck with me since isn’t that scan. It’s what the scan is a symptom of.

The person who used to catch the security problem before it shipped has been designed out of the process. These tools are very good at producing software that runs … and pretty bad at producing software that’s safe. And those are not the same skill. Veracode tested over a hundred models and found that 45% of AI-generated code carries the kind of hole that belongs on the OWASP Top 10, and the pass rate has held flat near 55% even as the models got dramatically better at coding. Bigger model, same hole. At Fortune 50 scale it gets worse: AI-assisted developers ship three to four times faster while their monthly security findings jump roughly tenfold. Ship rate up, defect rate up more. Same curve, two readings.

Share

The failure modes are getting inventive, too. There’s a fresh one called slopsquatting: the model hallucinates a software package that doesn’t exist, an attacker registers that exact fake name and loads it with malware, and the next person who runs the AI’s code installs it without a second look. Socket’s research lead warned in late June that AI agents are pulling in dependencies faster than any scanner can watch, and that the first half of 2026 already produced more than four times the package-compromise volume of all of last year. Even Microsoft got its own open-source projects breached twice in a matter of weeks, with password-stealing malware slipped into tools developers run right alongside their AI assistants. If Microsoft’s supply chain can get hit, the dashboard your treasury analyst built over the weekend is not the hard target here.

Why it’s your problem specifically

A vibe-coded app in marketing leaks a campaign calendar. A vibe-coded app in finance reaches the operating account, the AP subledger, the AR subledger, and payroll. Same tool, different blast radius … and yours is the one with the balance sheet wired to it.

The prototype works, the trouble is everything wrapped around it: no access review, no log of who touched the data, no version control, no idea whether it’s reading from a sandbox or the live ledger. For a public company, that’s a compliance problem with a short fuse. SOX already demands access controls, audit trails, documented data handling, and a named owner for anything touching financial reporting, and an unauthenticated app rendering ERP data in a browser window misses all of it the second an auditor finds it. The EU AI Act’s high-risk provisions land August 2, and citizen-built tools can trip them while sitting below the line where anyone’s looking. IBM puts the shadow-AI premium at about $670,000 on top of an already ugly breach.

The Cloud Security Alliance said the quiet part out loud in June: a risk committee can’t sign off on controls inside applications it can’t even list. Which squares with something from that same Escape.tech scan I flagged in May: Not one of the 5,600 apps they checked had basic access scoping in place. You can’t govern what you can’t see … and right now you can’t see most of it.

So I built the harness

The only guardrail in that room was me, and I don’t scale. Caveats stop working the second the session ends. So I stopped trying to bolt on rails one at a time and built the thing they run inside instead.

It’s called Trustward. A harness for the apps your team builds.

The idea is boring in the best way. Your team keeps the AI coding tool they already like. Trustward sits between that tool and your real systems and hands each app only the slice of data it’s cleared for, masked and logged, through credentials that reach nothing else. While they build, the tool works against synthetic data, so the dangerous paste into some outside model has nothing live to leak. Every app they ship lands on a map you can read in plain English: who owns it, what data it touches, whether it’s cleared, and when it last ran. And if one of them needs to stop, you stop it. One switch.

You never read a line of the code. You get the part that was your job all along, which is knowing what’s running and being able to turn it off.

Five years out

Play it forward and the training room I was standing in stops being a training room because nobody needs to be taught anymore. The very notion seems as archaic as teaching a roomfull of analysts how to Google something or attach a file to an email. Every person on your team runs a personal automation platform the way they run email today. The month-end close assembles itself overnight while a fleet of small agents ties out the subledgers and drafts the commentary for a human to bless over coffee. The analyst doesn’t build one dashboard over lunch. She runs a dozen agents that build and rebuild forty of them, retiring the ones that stop earning their keep. The org chart stops looking like a pyramid with a wide base of juniors doing grunt work and starts looking like a diamond, thin at the bottom, thick in the middle where people direct the machines. PwC is already watching that shape form.

Plenty of it won’t arrive on schedule. Gartner expects more than 40% of agentic AI projects to be scrapped by 2027, and the ones that die will mostly be the ungoverned ones, the pilots that couldn’t prove what they did or couldn’t be trusted near real data. That’s the part worth sitting with. The teams that win the next five years are the ones that built inside something, with a wall around the work and a record of what it touched, so the speed came with a paper trail instead of a prayer.

Everyone on your team is going to build like this soon, all day, whether you’re ready for it or not. The only real choice you get is whether they’re building with rails that hold, or building with nothing under them at all.

Next time I run that training, I’m not going to soften anything. I won’t have to.

The Pro edition this week turns all of this into the operational build: the app-inventory and risk-register workbook that turns “we think a few people built stuff” into a list you can act on, the control pattern for a governed build environment mapped to the ITGC framework you already run, and a prompt pack for running the discovery, tiering the risk, and drafting the attestation you can put your name on.

Unlock the full model & templates:

Subscribe now

The free edition left you with a problem and no tool. …

Read more