The Wiki Is CapEx: Stop Funding AI in Hours Saved

The efficiency pitch for AI is a lie wrapped around a landmine: the saved hours never come back as payroll, and the moment you force them to, you've made your own workforce the enemy. Here's the argument that survives — the compounding knowledge asset isn't an expense, it's capital, and it appreciates every time someone uses it.

By Scott Farrell, LeverageAI

There's a slide almost every AI business case eventually shows, and you can feel the room relax when it lands. It says: we'll spend a million on this, and it'll save us three million a year in labour. Two hundred people, eleven minutes a day, times a burdened hourly rate, compounded across the year — look, it pays for itself in a quarter. Everyone nods. Efficiency is the one business case nobody has ever been fired for making.

It's also, in my experience, the worst way to fund the best thing you could build. Not because the arithmetic is sloppy — because the whole denomination is wrong. The moment you price an AI investment in hours saved, you've signed up to a return that is either imaginary or radioactive, and you've filed your most valuable asset under the cheapest line on the budget. Let me take the labour-hours case apart first, because it fails in three distinct ways, and then show you the currency that actually works.

Failure one: the hours are confetti

Start with the three million in saved labour, because it was never going to appear anywhere. Saved time doesn't arrive in a lump you can bank. It arrives as confetti — eleven minutes here, twenty minutes there, scattered across forty people and a hundred small tasks. And confetti doesn't consolidate. Nobody hands their reclaimed eleven minutes back to the payroll. It gets absorbed — into a slightly longer lunch, an extra pass over the inbox, one more meeting that expands to fill the gap the way meetings always do.

So the P&L never sees it. There is no line, at the end of the year, where three million dollars of recovered time shows up as three million dollars of anything. You made a real fleet of people marginally less harried, which is fine and humane, and completely invisible to finance. The savings were fictional the day you put them on the slide — not because you lied, but because diffuse time is not money until something forces it to consolidate. Which brings us to the second failure, and it's much worse.

Failure two: the only business case whose beneficiaries are its enemies

Suppose you're disciplined. You refuse to let the savings evaporate as slack. You say: we will consolidate those reclaimed hours. Good — and the instant you do, the saved time has a name. It's headcount. Consolidated labour hours are jobs, and now the return on your AI investment is funded by the people whose jobs it removes.

Sit with the structure of that for a second, because it is genuinely perverse. You have built the only kind of business case whose beneficiaries are its enemies. The very people whose hours pay for the ROI — the ones being consolidated — are the same people you now need to adopt the tool, feed it their knowledge, correct it when it's wrong, and champion it to their colleagues. You have walked into the office and asked the workforce to dig its own grave enthusiastically, on deadline, and to keep the shovel well-maintained.

You already know how that goes. Every adoption survey ever run tells the same story about tools the staff quietly suspect are there to replace them: the training doesn't stick, the data stays dirty, the edge cases never get reported, and the pilot posts a disappointing number that gets blamed on the model. It wasn't the model. It was that you asked people to be the fuel for their own redundancy and acted surprised when they declined. And there's a version of this that isn't even about sabotage — it's about reputation. You do not want to be the company known for deploying an AI and cutting half its workforce. That's not a side effect of the labour-hours frame; it's the destination the frame is pointed at.

Failure three: the baseline is a story you tell yourself

The third failure is quieter and it undoes the measurement itself. To prove hours saved, you need a before and an after. Where does the "before" come from? Almost always, someone's estimate of how long the task used to take — self-reported, remembered, and produced by the same team whose budget depends on the number looking good.

So the baseline is negotiable, and everyone negotiating it has a reason to inflate it. The task that "used to take four hours" takes four hours precisely because a four-hour baseline makes the AI look like a hero. You are measuring your success against a ruler that your own incentives are bending. It's not fraud; it's theatre, and everyone in the theatre knows their part. Stack the three up and the verdict is clean: the labour-hours ROI case is either fictional or self-defeating — and its evidence is gamed. Pick your poison.

Price AI in hours saved and you promise a return that's either imaginary, or paid for by the very people you need to adopt the thing. There is no third door out of that frame — you have to change the currency.

Change the currency: denominate in capability

Here's the move. Stop counting what the AI subtracts — hours, heads, cost — and start counting what it adds in kind. Denominate the return in capability: things the organisation can now do that it simply could not do before.

That's a different ledger, and it's a real one. Decisions that got better because the context to make them well was finally in the room. Institutional IP that had evaporated into people's heads and old drives, recovered and put back into circulation. And the one I care about most — the question nobody knew to ask, answered. That's the signature of a compounding asset: not that it does the known task faster, but that it makes a previously impossible task ordinary. You don't measure that in minutes. You measure it in new things the company is now capable of.

And notice what this does to the politics, because it's the exact mirror of failure two. A capability case is stable for the same reason a labour-hours case is explosive. When the tool makes your people demonstrably more able — a better analyst, a faster onboarder, a sharper decision-maker — nobody sabotages it. You don't quietly starve the thing that makes you the most valuable person in the meeting. The exoskeleton frame and the redundancy frame produce opposite adoption curves, and you get to choose which one you build. One makes the workforce your fuel; the other makes them your allies. Same technology, opposite outcome, decided entirely by the denominator you chose.

Opex dies with the process. CapEx carries over.

Now the part a CFO can actually hear, because it stops being a values argument and becomes an accounting one. There are two categories of AI spend, and they belong on two different lines.

A workflow accelerator — the thing that makes an existing process run faster — is opex. Its value is welded to the lifespan of the process it accelerates, and here's the trap: AI is the very thing shortening process lifespans. You are strapping a rocket to a workflow whose remaining life the rocket itself is busy reducing. When you redesign that process — and in this era you will, repeatedly — the accelerator dies with the old workflow. It was expensed, it was consumed, it's gone. That's not a knock on accelerators; it's just what they are. This is roughly what the Terminal Value Doctrine means when it says of workflow acceleration: tolerate, don't celebrate. Harvest the speed-up if it's sitting there. Just don't put the board's attention and the build budget behind a horse you're about to stop riding.

The wiki — the compiled context, the retrieval layer, the compounding knowledge asset — is the other thing entirely. It's CapEx. It's substrate, not process. When the workflow gets redesigned, the accelerator dies and the knowledge asset carries over and feeds the new one. That's terminal value in a sentence: one asset's worth survives the churn, the other's is the churn. (There's a deeper version of this flip at the token layer — the idea I've called context arbitrage, where paying once to compile a worldview turns intelligence from a recurring read-cost into amortised capital. That's the same opex-to-CapEx move, one floor down. This piece is about the funding and the politics, not the token economics.)

The asset that appreciates when you use it

Call something CapEx and a finance person immediately files it next to a depreciating asset — a machine that's worth a little less every year until it's scrap. The wiki breaks that intuition, and this is the single most important property to get across, so let me be precise about the mechanism rather than hand-wave "it's compounding."

The wiki appreciates with use. Every query you run against it teaches you where it's thin. Every package you ingest doesn't just add a page — it raises the retrieval hit-rate of everything already in it, because the new material connects to the old and the graph gets denser. Every correction someone makes adds an edge that will route a future question no one has asked yet. Usage doesn't wear this asset down; usage is what builds it. Read from it and you learn its gaps; write to it and you thicken it; correct it and you sharpen it. It is the rare capital asset where the depreciation schedule runs backwards — it is worth more after a year of hard use than the day you commissioned it. There's a whole read-path economics here — the archive you already paid to create, re-priced from dead storage into circulating capital, yield on capital already deployed — but the short version is the one that matters at budget time: this is the only line item you own that gets more valuable the more the company leans on it.

One afternoon, one library

I don't want to leave "reuse across unknown futures" as an assertion, because it happened in front of me and the demo is better than the claim. In a single afternoon, one compounding asset — the wiki — grounded a CV rewrite, settled a twenty-year-old provenance question about who first said what, surfaced a colleague's old, half-forgotten prophecy about a bug I was chasing, and retrieved two of my own frameworks on demand when I needed them mid-argument. And it got measurably denser while doing all of it.

Count the distinct workflows one asset served in one afternoon — none of which existed when it was built. That's not efficiency. Not one of those tasks got a labour-hours line; several of them were things I could not have done at all the day before. No horse got faster. The rider got a library. That's the capability case, not asserted in a deck but witnessed in an afternoon — and it's the shape every genuinely compounding asset has: it keeps answering questions you didn't own it to answer.

The one-pager a CFO can actually score

None of this survives contact with a budget meeting unless you can hand it over on a single page. So here's the capability-denominated ledger, sketched. Fill your own rows — the point is the columns, and that every unit is a real thing that happened, not a hypothetical minute.

Move the line item

So the whole argument comes down to one budgeting decision, and it's the decision the labour-hours frame quietly makes for you without asking. Price AI in hours saved and it lands on the IT tools line — a cost, an expense, a subscription, something you justify by what it shaves and cancel when the number disappoints. That's the right home for accelerators. It is the wrong home for a compounding asset.

Price it in capability, and name it as what it is — a balance-sheet asset that appreciates with use — and it belongs somewhere else entirely: on the capital plan, next to the other multi-year investments the company makes in its own future worth. Not a cost to be minimised. Capital to be allocated. That single relocation, from the tools line to the capital plan, changes who approves it, how it's measured, and whether it survives the first quarter it fails to produce a tidy efficiency number.

The compounding asset you need CapEx for

The reason the labour-hours pitch feels so natural is that it's the pitch built for the last era — when software was bought, workflows were stable, and efficiency was the whole game. In the era of cheap cognition, the game moved. The scarce, defensible, compounding thing isn't a faster process; it's the substrate that outlives every process you'll build on top of it. Fund that in hours saved and you'll either lie about the return or make an enemy of the workforce you need. Fund it in capability, call it what it is on the books, and you've made an argument a CFO can put their name to.

The wiki isn't the tool that makes this quarter cheaper. It's the compounding asset you need CapEx for — and the day you argue it that way is the day it stops being a line item someone can cut, and starts being capital the company is deliberately choosing to build.

Scott Farrell writes on AI strategy, knowledge architecture, and the economics of building compounding assets at LeverageAI. If your AI business case is denominated in hours saved, you don't have a weak number — you have the wrong currency.