Clausey
AI strategy is a verification question. If a machine does the work, someone still has to check it — and what that checking costs is what caps the value you get. So you can only hand over work you can cheaply check, and unless you redesign the checking itself, the savings never show up. That is the whole argument, and everything below is the working.
Two years ago, a competent answer from a machine was expensive and unreliable. Now it costs a fraction of a cent and usually works. The gap between the best models and the free ones is measured in months.
Which means access to AI isn't an advantage. Your competitor has the same models you do, at roughly the same price, and so does everyone who starts a company next week. So the strategic question can't be how do we get AI. The question is what you can actually do with it — and that turns out to be governed by something most companies aren't looking at.
What actually caps the value?
If a machine does the work, someone still has to check it. What that checking costs is what caps the value.
Every hour a model saves gets partly handed back at the review step. Sometimes a little. Sometimes all of it. Occasionally more than all of it — a specific failure we'll get to.
The obvious objection is that capability is the real constraint — models still can't do plenty of things. True. But capability is the thing everyone is already watching, and it shrinks with every release. Checking cost doesn't shrink on its own, and nobody's watching it. That combination is usually where the interesting problems live.
You can see it in what's already been handed over. Coding went first — not because software is easy, but because you find out immediately when it's wrong. Tests fail. The compiler complains. Rollbacks are cheap. Customer support went early for the same reason: you know within a day whether the ticket got resolved.
Now look at what hasn't moved. Nobody lets a model set next year's budget, sign off on a clinical decision, or approve a credit facility — not because those are harder in some absolute sense, but because you won't know if it was right for months, and by then the money's gone.
If raw difficulty were the gate, the order would look completely different. It isn't difficulty. It's how fast and how cheaply you find out you were wrong.
So the first move isn't picking a use case. It's sorting the work.
Three piles, one sort key
The only sort key is how hard the output is to check.
Pile one: mistakes are obvious and easy to undo. First drafts, meeting notes, summaries, translations, fifty variations of ad copy so a human can pick three. If it's wrong you see it immediately and fixing it costs nothing. Automate hard and stop supervising it — the governance most companies wrap around this work costs more than the errors it prevents.
Pile two: someone reviews it but doesn't create it. Code. Financial analysis. Research memos. First-pass document review. The test is whether reviewing is meaningfully faster than doing it yourself. When it is, this is where the money is — most of it, because this is where most expensive human hours actually go.
Pile three: you'd have to redo the work to know if it's right. Strategic recommendations. Real legal exposure. Decisions you can't reverse. Leave these for now — but instrument them, because that is how they eventually move.
And here's what makes pile three worth understanding: it isn't the hard stuff. It's the stuff you can't check. A five-year forecast is hard — but the reason you can't hand it over is that you won't know whether it was any good until 2031. A model can produce a forecast that reads beautifully and is completely wrong, and nothing in your process will catch it. No test. No compiler. No angry customer. The output is confident, plausible, and unfalsifiable until it's too late to matter.
That's the boundary. Not what the model can attempt — it'll attempt anything. What you can confirm.
Two rules keep this from being a lazy exercise in bucketing.
Sort tasks, not departments
"Automate finance" means nothing. Take one job: explaining why last month's numbers moved. Working out what moved — price versus volume versus mix — is arithmetic against the ledger, checkable in seconds. Pile one. Working out why it moved — a delayed order, a competitor's promotion, downtime nobody logged — lives in someone's head, with nothing to check it against. Pile three.
Same hour, same person's work, two piles. Ask a model to do both in one pass and you've built something you can't verify. Most processes are like this; the sorting only works at the task level.
A standard that exists only in someone's head puts you in pile three
If the answer to "how do we know this is correct" is "Susan reads it and she'd know," you can't check the output, no matter how simple the task looks. This is why so many programs stall on something that seemed easy: the task was easy, the standard was undocumented.
One more thing: the line moves. Every improvement in evals, logging, and audit tooling drags work leftward. There's a whole industry forming around this. It looks like a safety industry. It's actually selling the ability to hand over more work.
Sort your work this way and you have a map of where the value could be. That's all it is, though — a map. Most companies stop here, which is why so many end up with something that demonstrably works and a P&L that doesn't move.
The pilot worked. The close still takes a week.
A finance team of six spends the last week of every month explaining why the numbers moved. Two hundred line items. Three days of analysts drafting commentary, two days of managers reviewing it.
They point a model at the ledger. It works — the drafts are good, and they arrive in an hour instead of three days. The close still takes a week. Here's why.
The review step was built for human mistakes. People get things wrong in predictable ways — transposed figures, the wrong month, a stale hardcoded number. Managers who've reviewed this work for years check the four places errors show up and skim everything else. That's why two days is enough for two hundred line items.
Models get things wrong differently. Rarely — but confidently, with no pattern to learn. The wrong answer arrives in the same assured tone as the right one, often more fluent, because there's no hesitation in it. The mistake could be anywhere. So the manager can't skim. They read every line.
Net saving: roughly nothing. And everyone involved is now slightly more tired and slightly less trusting of the tool.
AI doesn't remove the bottleneck. It moves it — usually into the review step.
You see it everywhere once you're looking. Support replies generated in seconds, then a supervisor reads all of them. Contract summaries produced instantly, then checked against the contract, which takes longer than reading the contract did. More pull requests than anyone can meaningfully review. In each case the work got faster at exactly one step, and the step that was actually constraining the process never changed.
So three things have to change
Roles. People stop producing and start specifying and judging — and writing a good brief and evaluating an output are both skills, and neither is the skill anyone was hired for. In the finance example: analysts stop drafting and instead push the business-unit owner a pre-computed breakdown — regional margin fell 340 basis points, 80% of it volume, concentrated in two accounts, confirm or correct — and the owner spends four minutes instead of thirty.
The review step. It was designed to catch a kind of mistake that isn't happening anymore. If you don't rebuild it, it will absorb the entire time saving, quietly. Managers stop reading for prose quality and review an exception list — anything above a materiality threshold, anything the model flagged low-confidence, anything where the owner's explanation contradicts the arithmetic. Everything else ships without a human reading it. That last clause is the hard part, and it's the whole point.
The freed-up time. Three analyst-days don't come back as savings. They come back as three slightly-less-busy days that nobody notices and nobody can put in a budget. Either you name what those days are now for — driver-based forecasting, scenario work, the analysis nobody ever had bandwidth for — or you shrink the team, or the value evaporates. And if close is a five-day process on the calendar, it stays five days no matter how fast the drafts arrive. Somebody has to move the deadline.
Capture is an organizational problem wearing a technical costume.
All three are changes to somebody's job. The technology part was settled before the project started; the model worked in the pilot — that's why you're here. It gets skipped because the technology part is legible: you can staff it, scope it, demo it. Reassigning what a manager does with their Thursday is none of those things.
Who's on the hook?
Don't start from a roster of roles. Start from four questions and let the roles fall out. Who defines what "right" looks like, and builds the means of checking it? Who builds the system? Who gets people to actually change how they work? And who baselined the process before deployment and can prove the delta afterwards — with budget authority and their name on the outcome?
Now watch how these get staffed.
The build gets the headcount, because it's visible and easy to justify. The first and last questions get half a person each, borrowed from another team, doing it alongside their real job. Those are the two that decide whether it works.
A procurement question wearing a strategy costume
"What's our AI strategy?" is really asking how to acquire something everyone can already acquire, at roughly the same price, on roughly the same timeline. Everyone will answer it about the same way — a reliable sign you're looking at a procurement question wearing a strategy costume.
Two questions are better.
What work do we understand well enough to check? That sets the boundary of what's available to you. It's a question about your own processes, your own data, and your own documented standards — none of which your competitor has, and none of which they can buy.
Are we willing to change how that work gets done? That decides whether any of it ever reaches the P&L.
Where this could be wrong: if the tooling for checking AI output stops improving, this stalls — a long stretch of very capable systems doing only the easily-checkable work, pile three frozen where it is. That's a real possibility, not a rhetorical one. It's also the argument for treating your checking capacity as infrastructure you build deliberately rather than overhead you tolerate.
What you can check is what you can hand over. And unlike the models, that part is yours.
Where Clausey fits
This argument is why Clausey is built the way it is. Document work is full of pile-two tasks — someone reviews the output but doesn't create it — and the thing that decides whether they pay off is whether the checking is cheap. So the checking is the product: every answer cites the exact page it came from, and the rules run as a deterministic policy engine rather than something you have to trust. You are meant to be able to confirm the output in seconds, not re-derive it.
The same idea runs through the rest of what we publish: verification as the binding constraint in The Software Economy Is Being Repriced, the grounding gate and eval suite in Building Enterprise-Grade Agentic Knowledge Bases, and governance as the durable moat in The Model Is No Longer the Moat.
Which is the practical version of the whole essay: don't ask what the model can attempt. Ask what you can confirm — and then go build more of that.