The rains came, which in the jungle means budget season, and the Crow did something the Fox had not been expecting.

She offered him a deal.

“Pick your denominator,” she said. “Whatever unit of work you think this capability produces. You choose it, not me. I will fund against it and I will not argue with the one you pick.”

The Fox, who had spent two seasons being told that finance did not understand what he was building, waited for the catch.

“You own it for two years,” said the Crow. “You do not get to change it when it stops flattering you.”

That was the catch. It was also, though it took him most of a month to see it, the fairest offer anybody had made him since this began.

He had assumed choosing would take an afternoon. It took three weeks, and he abandoned four candidates before he found one he was willing to sign his name to for two years. Somewhere in the middle of the second week he came to a realization that I think most people in his position eventually arrive at, usually later than he did.

Complaining about not having a denominator is enormously easier than choosing one, and he had been doing the easy version for a year.

Why choosing is hard

The four tests from Lesson 2 still apply. Countable without new instrumentation, meaningful without explanation, attributable to someone, stable across quarters. Those get you a shortlist.

What they do not tell you is the thing that makes the decision genuinely difficult, which is that every honest denominator makes your capability look worse than the dishonest one sitting next to it. Choosing well is an act of deliberately taking a smaller number, on purpose, and defending it. That is why so few organizations do it, and it is not because they lack a framework.

The gap between generated and accepted

Here is the distinction that does most of the work in this post.

Cost per generated output is easy to measure and almost useless. Every system produces output. Producing output is the one thing you can absolutely rely on it to do, whether or not the output was any good, whether or not anyone read it, whether or not it went anywhere.

Cost per accepted output is hard to measure and true. Accepted meaning used. Sent. Merged. Approved. Acted upon. The thing where a person looked at what came out and decided it was good enough to carry forward.

Almost the entire value question lives in the gap between those two numbers, and organizations that measure the easy one systematically overstate their own performance, sometimes by a lot. I have seen acceptance rates that would have changed a funding decision if anyone had thought to look, sitting quietly inside a program reporting excellent volume metrics every month.

The unpleasant part is that acceptance is often the one thing nobody instrumented, because at pilot stage it did not matter. Everything was accepted at pilot stage. That was rather the point of a pilot, and it is why pilot metrics travel so badly into production.

Four archetypes

What this looks like in practice, with the acceptance definition attached, because the definition is the hard half.

• Service and support work. Cost per resolved case. Accepted means the case closed and did not reopen within some window you choose in advance and then do not adjust.
• Content and communication. Cost per accepted draft. Accepted means it went out, or went to the next stage, with or without editing. If you want to be rigorous, track the edit distance too, because a draft that gets rewritten entirely was not accepted, it was raw material.
• Operations and processing. Cost per processed document. Accepted means it cleared without human correction. This is the cleanest of the four and the one most organizations can measure today if they look.
• Engineering work. Cost per merged change. Accepted means it went into the main line. Suggestions that were dismissed are not free and should not be invisible.

Notice that in every case the acceptance definition contains a judgment call, and the judgment call belongs to the business rather than to engineering. This is why the Mandrill has to be in the room for this conversation, and why it goes badly when he is not.

The two traps

Two denominators are chosen constantly and are wrong in ways worth being explicit about.

Cost per user. This is the most common choice and the most reliably damaging one, because it rewards exactly the wrong behavior. Under cost per user, the way to improve your metric is to add more users. Adding users who barely touch the thing improves your number considerably. Meanwhile your heaviest users, the ones actually generating the value, make the metric look worse, which creates a quiet institutional pressure to discourage the people you most want to encourage. It is the metric that most reliably produces the wrong decision, and it is on more slides than any other.

Cost per token, or per request, or per call. This is a genuinely useful efficiency metric and it belongs to the Crocodile, in his own meetings, where it will do good work. It is not a business metric and it should not be near a steering committee, because it tells you how efficiently you are doing something without telling you whether the something was worth doing. A system can get steadily cheaper per request while producing steadily less value, and cost per request will report that as a success story every single month.

Does it survive a bad quarter

The test I would add to the four from Lesson 2 is this one, and it is the one that catches the metrics chosen for the wrong reasons.

Imagine the capability has a bad quarter. Volume down, quality complaints up, a territory unhappy. Does your denominator show that? Or does it stay flat, or improve, because of some property of how it is constructed?

If a metric only looks sensible when things are going well, it is not a measurement. It is a narrative device, and the moment it is needed it will not be there. The Fox discarded two of his four candidates on precisely this test, which is why the three weeks were well spent.

One more thing worth saying. More than one denominator per capability is fine, and often better, because different consumers care about different units. Zero denominators per capability is what almost everyone has, and that is the actual problem. Do not let the search for the perfect single metric become another reason to not choose.

Three ways this goes wrong

The vanity denominator. Chosen because it trends nicely, quietly redefined at the point it stops. This is usually not dishonesty. It is someone genuinely improving a definition at a moment that happens to be convenient, which is why dating the definition matters so much.

Acceptance blindness. Measuring generated volume as though produced equals delivered. The tell is a program with excellent throughput numbers where nobody can tell you what proportion of output actually got used.

The unattributable metric. Technically sound, methodologically defensible, owned by nobody, discussed monthly, acted on never. This is the most common end state for a metrics program and it looks like success for about three quarters.

The Field Kit

Concrete things to do this week.

If you sit in the Crow’s chair, make the Fox’s offer. Do not impose a denominator. Ask for one, accept whatever they propose, and hold them to it for two years. You will get a better metric than you would have chosen and considerably more commitment to it than you would have got by mandating one.

If you sit in the Crocodile’s chair, instrument acceptance, not just completion. This is the hardest signal in the stack and the most valuable, and if it is not designed in now it will require a retrofit later that nobody will fund.

If you sit in the Mandrill’s chair, define what accepted means for your use case before anybody builds anything. You will discover this takes longer to agree than you expect, and that the argument itself is worth having, because it surfaces that your own teams disagree about what good output looks like.

For everyone: write the denominator down and put a date on it. Undated definitions drift, and they take the trend line with them without anybody noticing until somebody builds a business case on eighteen months of two different measurements.

Jungle Lesson 6

Pick the denominator before you build the dashboard, and pick the one that counts what was accepted rather than what was produced. A capability that generates a thousand things nobody used is not efficient. It is fast at being wrong.

Next time: every territory in the jungle wants the Watering Hole to exist and not one of them wants it on their books. The Mandrill argues brilliantly and in bad faith, the Sloth arrives with a framework roughly six weeks after it would have been useful, and the question of who pays for the shared foundation turns out to be political rather than technical, which is why nobody solves it with a tool. Lesson 7 is about allocation, showback and chargeback.

If your organization has been discussing metrics for more than two quarters without choosing one, the problem is not that you lack a framework. You have several. The problem is that choosing means accepting a smaller number on purpose, and nobody wants to be the one who did that.

Somebody finally counted the pilots.

It had not occurred to anyone to do this, because each one had been approved separately, by a different animal, at a different time, for a defensible reason. The count came out at a hundred and eighty something. The precise number was disputed for a while, on the grounds that several of them might not technically still be running, which turned out to be a question nobody could answer.

The Hyena found this genuinely funny for about four minutes, which is a long time for a hyena.

The Fox went through the list looking for the ones that had produced something. He found eleven. Of those eleven, four had been quietly switched off after the demonstration, two had become the departmental builds on the Tortoise’s list from the previous season, and the remaining five were still running as pilots, funded quarter to quarter, eighteen months after proving whatever they had been set up to prove.

“So what happened to the other hundred and seventy?” asked the Crow.

“Mostly nothing,” said the Fox. “They ran, they showed something, everyone was pleased, and then the person who cared moved on to something else.”

The Crocodile opened one eye.

“You didn’t buy a capability,” he said. “You bought a hobby, a hundred and eighty times.”

The arithmetic nobody does

Here is the calculation that nobody performs, because each pilot is approved in isolation and isolation is where this problem hides.

Every pilot carries a fixed cost that has nothing to do with its scope. Getting access sorted. Wiring up to a data source. Standing up somewhere to run it. Building enough evaluation to know whether it worked. A security review. A privacy review. The meetings, which are not free, and which involve expensive animals. Somebody writing a summary at the end.

That fixed cost does not shrink because the pilot is small. A two week experiment and a two month one pay roughly the same setup tax. Which means the true cost of a pilot is somewhere between two and five times what appears on its approval, and almost all of it is invisible because it is spread across other people’s time.

Now multiply by a hundred and eighty.

The number that comes out of that is almost always larger than whatever line item the organization is currently anxious about. In the jungle’s case it was substantially larger than the inference bill that had started this whole conversation four posts ago, and it had never once been discussed as a single number, because it had never once existed as a single number.

Why nothing compounds

The arithmetic is bad. The structural problem underneath it is worse.

In a healthy system, the fortieth thing you build is cheaper than the fourth, because the fourth left something behind. Some infrastructure, some patterns, some hard-won knowledge about what breaks. That is what makes a platform a platform.

Pilots leave nothing behind. Each one builds its own retrieval, its own evaluation, its own prompt scaffolding, its own access pattern, its own little arrangement with whoever owns the data. When it ends, all of that goes with it. The team disbands, the environment gets reclaimed, and the summary document goes into a folder that will be reorganized next year.

So pilot forty costs the same as pilot four. There is no curve. There is a straight line with a bad slope, extending as far as anyone is willing to keep funding it, and the organization experiences this as a series of individually reasonable decisions.

This is the thing to understand about the pilot trap. It is not that the pilots are bad. Several of them were excellent. It is that a hundred and eighty of them, run this way, produce exactly as much accumulated capability as one of them does, which is none.

The graduation problem

The five survivors on the Fox’s list deserve their own attention, because they illustrate a failure that is somehow both obvious and universal.

A pilot is funded to prove something. When it proves it, the funding logic has been satisfied, and the thing that made the money flow no longer applies. There is usually no defined path from proof to production, no budget line waiting, and no team whose job it is to receive it.

So the successful pilot ends up in exactly the same position as the failures. Still running, still on temporary funding, still argued about every quarter, and slowly starved by an organization that has moved on to approving the next batch.

I have watched genuinely good capabilities die of this. Not rejected. Not found wanting. Simply never picked up, because success was not something anybody had designed for. The Mandrill put it well when he finally understood what he was looking at: “We’ve built a system that can start things and cannot finish them, and we call the starting part innovation.”

The portfolio inversion

What good looks like is roughly the inverse of what most organizations have.

A small number of capabilities. A large number of use cases running on them. Not many initiatives each carrying its own complete stack, but a handful of well-built things that many parts of the business consume.

Almost every enterprise I have seen has this exactly backwards. Dozens or hundreds of initiatives, each with its own everything, and no shared foundation underneath any of it. Then somebody proposes consolidation, and the resistance is immediate, because every one of those initiatives has an owner who experiences consolidation as losing control of their thing.

The economics are not subtle. In the capability model, the fixed cost is paid once and amortized across everything that uses it. The marginal cost of the next use case falls as the platform matures. The cost curve bends. In the pilot model, the fixed cost is paid every single time, and the curve does not bend, ever, because there is nothing for it to bend around.

What this sets up

I am deliberately not going to resolve this here, because the resolution takes a whole act and doing it badly in three paragraphs is how this subject usually gets ruined.

What a capability actually is, how it gets funded when your organization’s entire financial machinery is built around things that end, who owns it, and what has to be traded to make it politically survivable, all of that is Act IV. It is the part of the series I expect to be most argued with.

For now the useful thing is to have the number. Count your pilots, multiply by an honest fixed cost, and look at the total. That single figure changes more conversations than any framework I could give you, because it converts a hundred and eighty reasonable individual decisions into one unreasonable aggregate one, which is what it was all along.

Three ways this goes wrong

Innovation theater by volume. The number of pilots becomes the metric that gets reported upward. Once that happens the incentive is to start things, not to finish them and certainly not to kill them, and the count grows because the count is the point.

The graduation cliff. No funding path from proof to production, so success is fatal. The tell is that your longest running pilots are also your best ones, which should be alarming and is usually described as pragmatism.

Capability in name only. A platform team is created, everyone agrees consolidation is the right idea, and then each territory carries on building its own stack on top of the shared one. You now pay the duplicated fixed costs and a governance layer, which is worse than where you started, and it is very common.

The Field Kit

Concrete things to do this week.

If you sit in the Crow’s chair, get the count and multiply it by your honest fully loaded fixed cost per pilot. Include the meetings and the reviews. Bring the total to your next steering meeting as a single number with no commentary attached and let the room react to it.

If you sit in the Crocodile’s chair, list what every pilot has rebuilt from scratch. Retrieval, evaluation, access, deployment, monitoring. That list is not a complaint. It is the specification for your platform, written for you, by evidence.

If you sit in the Mandrill’s chair, stop starting things. Pick the three use cases in your territory that genuinely matter and kill the rest publicly, so that people believe the change is real. Quiet cancellation teaches nobody anything.

For everyone: ask what happens to a pilot that succeeds. If nobody can answer, you do not have a pipeline. You have a graveyard with excellent intentions and a quarterly approval process.

Jungle Lesson 5

Pilots are cheap individually and ruinous collectively, because each one pays the setup cost again and none of them make the next one easier. A hundred experiments is not a strategy with good coverage. It is the same experiment, funded a hundred times, by people who have not met.

That closes the first act. Five lessons in, the jungle now knows that its bill is shaped differently from anything it has managed before, that three groups have been arguing in three currencies, that the layer everyone budgeted for is not the layer that hurts, that the most interesting demand signal in the building was sitting on a compliance officer’s desk, and that a hundred and eighty reasonable decisions can add up to one unreasonable one.

What it still cannot do is answer the Crow’s original question. Are we getting enough for what we are paying? That requires learning to count, which is the second act, and it starts with the least glamorous and most consequential decision in the whole discipline: choosing what to divide by. Lesson 6 is about picking a denominator, and why choosing turns out to be considerably harder than complaining about not having chosen.

If you have never counted your pilots, the count is usually a bad afternoon and a very good quarter. I have yet to see an organization regret doing it, and I have yet to see one where the number was smaller than expected.

The Tortoise arrived at the review with a list, which she put on the table without saying anything, and then waited.

Tortoises are the most underestimated animal in any organization. They are slow, they are armored, and they outlive absolutely everyone in the room, which means that over a long enough period they are usually the only creature who remembers what was decided and why. This one had been compiling her list for two seasons without mentioning it, because she had wanted it to be complete before anyone had the chance to argue with it.

It ran to four pages.

The Fox read it with an expression that changed twice. The first change was surprise at the length. The second was the recognition, about halfway down the second page, that three of the entries had been started by his own team, one of them by a person who reported directly to him.

“How long have you had this?” he asked.

“A while.”

“Why didn’t you bring it earlier?”

“Because,” said the Tortoise, “the last time somebody brought a list like this to a room like this, everything on it got banned within a fortnight, and eighteen months later there was a longer list that nobody had.”

Why this is not shadow IT

Every enterprise has had shadow IT and every enterprise thinks it knows how to handle this. It does not, because the two problems only look alike from a distance.

Shadow IT had friction. Somebody had to find a tool, pay for it, get it working, and usually get it past a network. There was a procurement event, an invoice, a login, an integration. There were artifacts, and artifacts are catchable.

Shadow AI has almost none of that. The entry cost is close to zero. There is frequently no infrastructure footprint at all. And in the largest category, which I will come to, there is no procurement event whatsoever, because the capability arrived inside software your organization already licensed and somebody simply switched it on.

There is, quite often, nothing to catch. Which means the entire enforcement instinct that your organization built over fifteen years is pointed at a problem with a different shape.

The three tiers

What the Tortoise’s list actually contained, once it was sorted, fell into three tiers.

Tier one: personal subscriptions. Individuals expensing tools, or in a fair number of cases not expensing them and paying out of pocket because it was easier than asking. Visible in expense data if anyone looks. Usually small in cost and disproportionately large in the anxiety it generates, because it is the tier everyone can see and therefore the tier everyone talks about.

Tier two: features inside software you already own. The assistant embedded in the document tool. The summarization inside the service platform. The drafting feature in the communications suite. Nobody procured these. Nobody decided to adopt them. A vendor shipped an update and several hundred animals started using something new on a Tuesday.

Tier three: departmental builds. A team with some technical capability builds something real on the sanctioned platform, and it never registers as a project because nobody filled in a form. Often genuinely good. Almost always without an owner named anywhere, a runbook, or a line in any budget.

The tier nobody sees

Tier two is the biggest and the least visible, and I think it is the most under-discussed problem in the whole field.

Your organization is already paying for it. The cost sits inside a bundled licence line that was negotiated for something else entirely, which means it does not appear in any AI cost report, is not attributed to any capability, and shows up in no conversation about adoption. From a financial reporting perspective it is not AI spend at all. It is last year’s software renewal.

Meanwhile several hundred people are putting real work into it daily. The Tortoise’s list had more entries in tier two than in the other two combined, and every one of them had been discovered by her opening an administrative console and reading, which took her an afternoon.

This is worth sitting with. The largest category of AI use in most organizations is one that costs nothing extra, appears in no report, and was never decided on by anybody.

What the exposure actually is

The reflex is to worry about cost. In my experience cost is rarely the real exposure here, and treating it as such gets you a program that solves the cheap problem.

The real exposure is threefold. Data leaving where it was supposed to stay. Retention you did not choose and cannot describe. And, most seriously, a business process that now depends on something with no owner, no runbook, no monitoring and no budget.

That third one is what should keep people awake. Somewhere in your organization right now there is a month end process, or a customer response path, or a regulatory submission, that has quietly come to depend on something a single person set up in an afternoon. That person may have since moved teams. When it breaks, nobody will know what it was, what it did, or how to restore it, and the discovery will happen at the worst possible moment because that is when dependencies reveal themselves.

The reframe

Here is the part that takes most leadership teams a while to accept.

Every entry on that list is somebody solving a real problem, on their own initiative, without being asked, and usually without being resourced. Not one of those animals woke up wanting to circumvent anything. They had work to do and something in front of them made it easier.

Which means the Tortoise’s four page list is the single best product roadmap in the building. It is demand, validated by the fact that people were willing to work around the organization to get it. No survey will ever produce information that good. No workshop will surface it. Your people have already told you what they need, in the most credible way available, which is by doing it.

The Fox, to his credit, worked this out about ten minutes into the meeting and stopped being defensive about the three entries belonging to his own team. “So this is the backlog,” he said. The Tortoise, who had been waiting two seasons for someone to say precisely that, allowed herself to look mildly pleased, which on a tortoise is a very small movement.

Amnesty, and what makes it work

The practical mechanism is an amnesty. A defined window during which declaring what you built gets you support, migration help and a proper budget line, rather than a conversation with someone about policy.

Three things make an amnesty work, and all three are required.

• Credible non-punishment. If one person gets disciplined during the window, the window is over regardless of what the announcement said. This has to be stated at a level senior enough that people believe it.
• A genuinely better sanctioned alternative. Amnesty with nothing to migrate to is just a census. People declare, nothing improves, and they carry on exactly as before with more paperwork and less trust.
• A real deadline. Open-ended amnesties never close and therefore never create the moment of decision that makes them work.

Discovery, meanwhile, does not require surveillance and should not use it. Expense line analysis finds tier one. Reading your own administrative consoles finds tier two, and finds most of it in a single afternoon. Tier three is found by asking, which works considerably better than people expect once the amnesty is credible.

Three ways this goes wrong

The crackdown. A blanket ban, announced firmly. Usage does not stop. It moves to personal devices, personal accounts and personal networks, where you have no visibility at all. Your exposure has increased and your ability to see it has gone to zero, which is the exact opposite of what the ban was for.

Amnesty with nowhere to go. Everyone declares, the sanctioned platform is worse than what they were using, and within a quarter the list is growing again. You have spent your credibility and bought a snapshot.

Counting the wrong risk. A program obsessed with subscription costs, producing careful reports on a small number, while an unowned workflow sits inside a month end close and nobody has noticed.

The Field Kit

Concrete things to do this week.

If you sit in the Crow’s chair, run an expense line analysis for AI subscriptions this month, then go and look at what AI features are bundled into your three largest software renewals. The second exercise will find more than the first and cost you nothing.

If you sit in the Crocodile’s chair, inventory what is already licensed and switched on. Most of tier two is sitting in administrative consoles you already have access to. This is an afternoon of work and it is the highest return afternoon available to you this quarter.

If you sit in the Mandrill’s chair, treat your territory’s list as a demand backlog rather than a compliance finding, and fund the top three properly. You will get better outcomes and considerably more goodwill than any enforcement action would have produced.

For everyone: for every instance you discover, record the problem it was solving in a column next to the cost. That column is worth more than the cost column, and almost nobody creates it.

Jungle Lesson 4

Shadow AI is not an act of defiance, it is an unfunded requirement with a credit card. Kill the tool and the requirement is still there, only now it is invisible to you and expensive to somebody else.

Next time: the jungle counts its pilots for the first time and the number is genuinely absurd. Every one of them was individually cheap and individually defensible. Together they consumed most of a year, and not one of them made the next one any easier to start. Lesson 5 closes the first act with the pilot trap.

If you have someone in your organization who has quietly been keeping a list like the Tortoise’s, find out. They are usually in risk or compliance, they have usually been waiting to be asked, and they are usually the best informed person in the building.

The Beaver offered to show the Crow around the Watering Hole, and she accepted, mostly because she had approved funding for it twice and had never actually seen it.

Beavers cannot hear running water without building something. This is not a character flaw, it is a compulsion, and it is the reason the Watering Hole worked at all. It is also the reason it had considerably more moving parts than anyone in the Canopy realized.

He started with the part she knew about. “This is where the thinking happens,” he said. “This is the bit everyone means when they say the word.”

“Right,” said the Crow. “That’s the line in my budget.”

“That’s about forty percent of it.”

She stopped walking.

He opened a panel she had not noticed. Behind it, something was running steadily, working through the jungle’s documents, converting them into a form the system could search. It had been running all night. It ran every night.

“What is that costing us?”

“Depends how much anyone wrote this week.”

“Not how much anyone used it?”

“No,” said the Beaver. “That one doesn’t care whether anybody uses it.”

The Crow, who had spent a career learning that costs follow activity, took a moment with that. Then she asked him to open every other panel.

The layer you budgeted

Almost every organization budgets for inference and is surprised by everything else. Not because the other layers are hidden, exactly, but because the mental model arrived from somewhere else. You buy a thinking machine, you pay per thought. That is the shape of the thing as it is described in every article, every business case, and every conversation with a vendor.

The shape is wrong. Inference is usually somewhere between a third and half of the true cost of a running capability, and the proportion falls as the capability matures, because the supporting layers keep growing while the thinking gets cheaper.

Here is the full stack, in roughly the order it surprises people.

The seven layers

• Inference. The one you budgeted. Scales with usage, drops in unit price over time, and is the only layer most organizations can report on.
• Retrieval and indexing. Embedding your content, storing it, and re-processing it every time it changes. This scales with the size of your corpus and the rate at which people write things, not with how much anyone uses the system.
• Orchestration and glue. Queues, state, workflow, the compute that coordinates rather than thinks. Individually cheap, structurally permanent, and it never appears on a slide.
• Evaluation. Running your test sets, regression checks and scoring. Scales with release frequency, which means it grows precisely as the team gets better at shipping.
• Observability and logging. Capturing what went in and what came out, at volume, and keeping it for as long as somebody with an armored shell says you have to.
• Human in the loop. Review, correction, escalation, the person who checks the output before it goes anywhere consequential. This is a labor cost and it usually lands in a completely different budget.
• Rework. Output that was wrong, redone, or quietly discarded. Costs you twice and appears nowhere at all.

Seven layers. Most organizations can see one of them clearly, two of them vaguely, and are actively surprised by the rest.

The two that grow when nobody is using it

Retrieval and evaluation deserve their own paragraph, because they break the intuition that cost follows activity, and that intuition is the load-bearing wall of every cost conversation your finance team has ever had.

Retrieval cost tracks your content, not your usage. If a content team has a productive quarter and publishes four hundred new documents, your retrieval bill goes up, and not one additional animal has asked the system a single question. If somebody reorganizes a document library, everything gets reprocessed. If a well-intentioned team decides to index a large archive that nobody has opened since the last reorganization, you will pay to keep that archive current forever.

Evaluation cost tracks your release cadence. A team that ships weekly runs its test suites weekly. As the suites grow, which they should, the cost of every release grows with them. This is the correct behavior and it is still a cost line that nobody forecast, and it arrives at exactly the moment when a program is going well, which is the worst moment for a finance surprise.

Neither of these responds to a usage cap. Neither of these shows up in a conversation about adoption. Both of them appear on the invoice.

The layer in someone else’s budget

Human review is the one I see cause the most damage, and it is not close.

The capability produces output. Somebody checks it. That checking is real work performed by real people, and in almost every organization I have seen, those people sit in an operations budget, a service budget, or a shared function that has nothing to do with the AI program.

So the capability looks cheap. Its cost line contains inference and some infrastructure. The review labor it generates is invisible to it, sits somewhere else, and grows in direct proportion to how much the capability is used.

Then somebody decides to scale it, on the basis of a unit cost that excluded most of the marginal cost, and the operations budget quietly absorbs the difference until it cannot, which is usually about two quarters later and always somebody else’s problem to explain.

The Mandrill, when this was pointed out to him, did something I have a lot of respect for. He asked for the review hours to be attributed to his capability, knowing it would make his own business case look worse. It did make it look worse. It also made it real, and the version of the decision he made afterwards was a better one.

The invisible layer

Rework is the seventh layer and the one nobody can measure, which is precisely why it is worth naming.

Output that was wrong and had to be redone. Output that was fine and got discarded because the person did not trust it. Attempts that succeeded on the third try. Work generated, reviewed, rejected, and generated again.

You cannot instrument this precisely. What you can do is stop pretending it is zero, because zero is the number currently in every business case in your organization. A documented estimate, even a rough one, is a better input than an implicit assumption that the failure rate is nil. And the act of estimating it tends to surface how little anybody knows about acceptance rates, which is a useful thing to discover in a planning meeting rather than in an audit.

Fixed and variable

The last thing worth pulling out of the stack is which parts are fixed and which are variable, because that ratio determines the shape of every architecture decision you will make later.

Inference is variable. Human review is variable. Retrieval and evaluation are mostly fixed with respect to usage and variable with respect to other things entirely. Orchestration and observability are largely fixed once built.

A capability with a high fixed proportion has terrible unit economics at low volume and excellent unit economics at high volume. A capability that is almost entirely variable has flat unit economics forever. Neither is better. But if you do not know which one you have, you cannot answer the question of whether scaling it will help or hurt, and that question is going to come up.

One thing the Beaver said as we finished the tour has stayed with me. “Everyone asks me how much a question costs,” he said. “Nobody asks me how much it costs to be ready for one.”

Three ways this goes wrong

Inference tunnel vision. Months spent optimizing the visible layer while the other six grow unwatched. The optimization work is real and the savings are real and the total bill goes up anyway, which does considerable damage to the credibility of everyone involved.

Corpus creep. Retrieval costs rising steadily with no change in usage, and nobody connecting it to the fact that three teams have been busy publishing. This one can run for a year before anybody asks the right question.

The orphan labor line. Human review costs sitting in an operations budget, so the capability appears far cheaper than it is, and gets scaled on a unit cost that was never true.

The Field Kit

Concrete things to do this week.

If you sit in the Crow’s chair, pick one capability and demand the cost broken into all seven layers. Just one. You do not need the whole estate to make the point, and the exercise of producing it will teach the team more than the answer teaches you.

If you sit in the Crocodile’s chair, put retrieval and evaluation onto their own cost lines today, separately from inference. They are the two that grow silently and they are invisible inside an aggregate.

If you sit in the Mandrill’s chair, find the human review hours your capability generates and insist they are attributed to it. Yes, it makes your numbers worse. It also means the decision you make next is based on something true, and you will be the only person in the room who can say that.

For everyone: put a number on rework, even a guess, and write down how you arrived at it. Any documented estimate beats the zero that is currently sitting there by default.

Jungle Lesson 3

Inference is the layer you budgeted and rarely the layer that hurts. The expensive parts of an AI capability are the ones that grow when nobody is using it, and the ones that get paid for out of somebody else’s budget.

Next time: the Tortoise puts a list on the table. She has been quietly compiling it for two seasons and it is considerably longer than anyone expected, and several entries turn out to have been started by the Fox’s own team. Lesson 4 is about shadow AI, why the instinct to stamp it out is the most expensive available response, and why that list is the best product roadmap in the building.

If anyone has ever shown you a full seven layer breakdown of a live capability without being asked, keep them. They are rarer than they should be.

The Fox explained the number three times on the same day, to three different audiences, and gave three completely different answers. All three were true. That was the problem.

At nine in the morning he told the Crow that the overage came from higher than forecast request volume in two territories, and that the average unit cost had actually improved quarter on quarter.

At eleven he told the Crocodile’s team that the retrieval layer was over-fetching, that context sizes had grown by roughly half since launch, and that nobody had touched the routing configuration since the pilot.

At three he told the Mandrill that adoption was running ahead of plan, that his territory was seeing measurably faster proposal turnaround, and that the spend reflected genuine business pull.

Every one of those statements was accurate. Not one of them could be reconciled with the other two. And by Friday all three animals were quietly certain that the Fox was telling each of them what they wanted to hear.

The Hyena had been listening from a branch for most of the day, because it was more entertaining than working. She offered the only useful observation anyone made.

“He isn’t lying to you,” she said. “He’s answering in three currencies and none of you can do the exchange rate.”

The meeting is not the problem

I have watched a lot of organizations conclude that their AI cost conversations are failing because of politics. Finance is being difficult. Engineering is being evasive. The business is being unrealistic. Somebody suggests a workshop.

It is almost never politics. Politics is what grows in the gap afterwards, once three competent groups have spent a quarter failing to understand each other and have each drawn the obvious conclusion about the other two.

The underlying failure is more boring and much more fixable. Three groups are describing the same system in three vocabularies, each internally coherent, none of which converts into the others. Nobody has defined what the shared thing being counted actually is. So every meeting is a currency exchange conducted by people who each believe they are already speaking the common language.

Three currencies, no exchange rate

The Crow thinks in periods, budget lines and variance. Her unit is a committed number and her time horizon is the fiscal year. When she asks what something costs, she means what will appear against a line she has to defend, in a period she has to close. This is not narrow-mindedness. It is the job, and the job has a shape.

The Crocodile thinks in requests, throughput, utilization and latency. His unit is a system under load and his time horizon is roughly now. When he says the cost is fine, he means the cost per request is trending down, which it genuinely is, and which has nothing whatsoever to do with the Crow’s question.

The Mandrill thinks in outcomes, cycle time and headcount. His unit is a business result and his time horizon is whatever he committed to at the last review. When he says it is working, he means his territory is producing more of something he cares about, which is also true, and which nobody has connected to either of the other two answers.

Each vocabulary is correct. Each one is load-bearing for the animal using it. And each one answers a question the others were not asking.

What makes this worse than a normal translation problem is that all three groups have been in enough meetings together to believe they have already adjusted. The Crow has learned to say request. The Crocodile has learned to say budget. They are using each other’s words for their own concepts, which is not translation. It is a false cognate, and false cognates are more dangerous than an unknown language, because nobody notices the error.

Why dashboards do not fix this

The standard response at this point is to build something. Usually a dashboard, occasionally a whole platform, and there is a business case involving single source of truth.

Watch what actually gets built. Engineering data, rendered attractively, placed in front of a finance audience. Requests per day. Tokens by team. Average latency. Cost per thousand calls, in a nice color.

That is not translation. That is subtitling. The words are now legible to the Crow and the meaning is not, because the underlying unit never changed. She can read every number on the screen and still cannot answer the only question she has, which is whether this was worth it. So she asks that question again, out loud, in the review, and the room concludes that finance does not understand the technology.

Finance understands the technology fine. Finance is being handed the numerator and asked to reason about a ratio.

The Owl, at this point, produced a diagram. It mapped all three vocabularies onto a single canvas with color-coded arrows showing the relationships between them. It was, I want to be fair here, completely accurate. Everyone agreed it was very clear. Nobody’s behavior changed by a single decision, because a map of a disagreement is not a resolution of it, and the Owl had drawn the territory rather than deciding what to call the things in it.

The shared unit of account

What is missing is a shared unit of account. One thing that all three tribes agree describes the same object, sitting deliberately between the technical metric and the business outcome, close enough to each that both can reach it.

Not tokens. That is engineering’s currency and it belongs in engineering’s meetings, where it is genuinely useful. Not annual budget. That is the Crow’s currency and it aggregates away everything actionable. Not revenue. That is the Mandrill’s and it has too many other parents to attribute cleanly.

Something in the middle. A resolved case. An accepted draft. A processed document. A completed review. The unit of work the organization actually performs, which happens to be the one thing all three animals were already talking about without noticing.

Four tests for whether you have picked a good one.

• Countable without new instrumentation. If measuring it requires a project, you will not measure it, and the definition will quietly become an estimate within two quarters.
• Meaningful without explanation. If the Mandrill needs a preamble to understand what it represents, it will not survive contact with a steering committee.
• Attributable to someone. An excellent metric that belongs to nobody produces no decisions. It produces observations, which is a different and much less useful thing.
• Stable across quarters. If the definition moves, the trend line is fiction, and you will not notice until someone builds a business case on it.

The conversion chain

Once you have the unit, the argument becomes tractable, because you can lay out the chain and see where it is solid and where it is assumed.

Technical unit to work unit to business outcome to money. Four links. Requests to resolved cases. Resolved cases to reduced backlog. Reduced backlog to something in the ledger.

Most organizations attempt to jump from the first link to the last in a single move, and lose the argument at the first joint, because the person on the other side can feel the gap even if they cannot name it. The Crow could not have told you which link in the Fox’s Tuesday argument was weak. She could tell you immediately that something was.

The discipline is to draw all four links explicitly and then mark honestly which ones are measured and which ones are assumed. Almost always the first link is measured, the last is asserted, and the two in the middle are where the real work sits. That is not an embarrassing finding. That is the map of what to go and do next, and it is worth more than any dashboard you could commission this quarter.

The Crocodile, who had been silent for most of this, opened one eye. “So we’ve spent six weeks arguing,” he said, “about a conversion nobody had written down.”

Three ways this goes wrong

Subtitling. The same engineering data in a prettier chart, refreshed monthly, satisfying nobody. The tell is that the review meeting is the same length as before and produces the same number of decisions, which is none.

The composite index. Someone, usually with good intentions and a background in analytics, builds a weighted score combining nine metrics into a single number between zero and a hundred. It goes up. Nobody can act on it, because no single lever moves it and no team owns it. The composite index is what organizations build instead of choosing, and choosing was the whole task.

Unit drift. The definition changes quietly between quarters, usually because someone improved the measurement, and the trend line becomes a comparison between two different things. This one is insidious because it happens for good reasons, and it is only discoverable if the definition was dated when it was written.

The Field Kit

Concrete things to do this week.

If you sit in the Crow’s chair, ask each of the three groups to describe the same use case in one written sentence, separately, without conferring. Put the three sentences side by side. The gap between them is not a communication problem to be smoothed over in a workshop. It is the actual problem, now visible, in about twenty minutes.

If you sit in the Crocodile’s chair, publish the conversion chain for one capability, all four links, and mark clearly which links are measured and which are assumed. Do not wait until it looks good. The version with honest gaps in it is far more valuable than the version that took a quarter to make presentable.

If you sit in the Mandrill’s chair, own the business outcome end of the chain and define it in writing. Nobody else can do this and if you leave it vacant, somebody will cheerfully invent an outcome on your behalf, and you will be held to it.

For everyone: agree the unit of account in writing, with a date on it, before anyone commissions a dashboard. Tooling built on the wrong denominator is worse than no tooling, because it makes the wrong answer look rigorous, and rigorous wrong answers are much harder to dislodge than obvious ones.

Jungle Lesson 2

A disagreement you cannot resolve is usually a translation failure wearing a disagreement costume. Before you argue about the number, agree what the number is counting, write the definition down, and put a date on it.

Next time: the Beaver takes the Crow on a tour of the platform and keeps opening panels she did not know were there. It turns out that the layer everyone budgeted for is rarely the layer that hurts, and two of the expensive ones grow steadily whether anybody uses the thing or not. Lesson 3 is the anatomy of an AI invoice.

If your organization is currently three groups talking past each other about the same bill, I would be curious which of the three vocabularies is winning. In my experience it is whichever one the loudest person speaks.

The Crow had a spreadsheet, and the Crow was not happy.

Crows are the most underrated animals in the jungle. They count. They remember faces. They have been observed holding grudges across multiple years, which makes them the only creature in the canopy genuinely qualified to run a finance function. This particular Crow had been staring at a single line item for eleven minutes without blinking.

“Explain this to me,” she said, “like I am a bird who signs things.”

The Fox had spent two quarters telling everyone that AI was going to transform the jungle. He looked at the number. It was large. It was also four times larger than the number he had put in the plan, which was awkward, because he had personally written that number on a slide titled Conservative Estimate.

“So the good news,” said the Fox, “is that people are using it.”

“The good news,” said the Crow, “is a rounding error next to this.”

The Crocodile had been in the room for the whole meeting without moving. He had survived the mainframe. He had survived client-server, virtualization, and three separate cloud migrations, each announced as the last one. He opened one eye.

“It isn’t a cost problem,” he said, and closed it again.

He was right. It took the jungle another two quarters to understand why.

The meeting you are about to have

I have sat in that meeting more times than I would like to admit, on both sides of the table. It always plays out the same way. Someone brings a number that is bigger than expected. Someone else explains that this is because things are going well. Nobody in the room can prove either position, so the argument gets resolved by whoever has the most seniority and the least patience.

What makes it frustrating is that everyone in the room is competent. The Crow is not being obstructive. The Fox is not being reckless. They are both applying reasoning that has worked perfectly for fifteen years, to a category of spend where that reasoning quietly stops working.

Enterprises have spent a decade building genuinely good cloud financial management. Tagging strategies. Showback models. Reserved capacity. Rightsizing. The discipline works, and the people who built it are not fools. So when AI spend arrives, the obvious move is to point the existing machinery at it.

That machinery rests on four assumptions. AI breaks all four.

One: cloud spend is provisioned, AI spend is consumed

Cloud cost traces back to a decision. Someone requested an instance. Someone chose a storage tier. Someone signed a commitment. Every dollar has a person and a moment attached to it, which means every dollar can be reviewed, questioned, and reversed. This is not a minor property. It is the entire foundation of how cost governance works.

Inference cost does not work like that. It is generated in the moment, by thousands of small acts nobody approved individually. An analyst pastes in a long document. A workflow retries three times because a downstream system was slow. A well-meaning team member discovers that asking the same question five different ways produces a better answer, and tells their colleagues, who tell theirs.

The Beaver, who runs the platform, once described this to me perfectly. In cloud, he said, I can show you the dam. I built it, I know how big it is, and I know what it cost. Here, I can only show you the river, and the river does not consult me.

This is the first structural shift. Your spend has moved from a provisioning decision to a behavioral one, and behavior is not something a procurement process can govern after the fact. You can review a purchase order. You cannot review an afternoon.

Two: cloud has an idle state, AI has waste with no shape

Classic cloud waste is beautifully visible. An unused instance. An orphaned volume. A dev environment nobody switched off in March. You can find it, point at it, and kill it, and everyone in the room agrees it was waste. There is no argument to be had.

AI waste has no such courtesy. It looks exactly like work.

A model producing a perfectly good summary of a document nobody was ever going to read is waste. A workflow that retries silently and succeeds on the third attempt is waste, and it will never appear in any error log, because nothing errored. A team routing every request to the most capable and most expensive model available, including the ones that are essentially string formatting, is waste, and the output quality will be excellent, which is precisely the problem.

The Hummingbird is the purest expression of this. A pilot that burns astonishing energy, produces something genuinely impressive, and dies the moment anyone stops feeding it. Every jungle has a dozen. They are individually cheap and collectively ruinous, and nobody can tell you what any of them are for.

You cannot find this waste by looking at a bill. The bill will tell you that a lot of successful, useful-looking activity occurred. It is right. That is not the same as it having been worth doing.

Three: cloud cost is deterministic, AI cost is not

This is the one that upsets finance teams most, and I have some sympathy.

A gigabyte of storage costs the same today as it will next Tuesday. Volume times unit price gives you a forecast, and the forecast is correct. This is not a technique. It is the foundation on which every budget in your organization is constructed, and it has been reliable for so long that nobody thinks of it as an assumption at all.

Two identical AI requests can cost different amounts. Same input, different response length. Same task, different amount of retrieved context. Same question, but this time the system decided to check three sources instead of one. The variance is not a rounding error, and it is not a defect. It is how the thing works.

The Owl, our Enterprise Architect, produced a beautiful diagram about this. It had seven layers and a legend. It explained the variance completely and helped absolutely nobody, because the Crow’s problem was never comprehension. Her problem was that she has to commit to a number in September and be held to it in March, and she has just been handed a workload that refuses to hold still.

Owls have very large eyes. This is sometimes mistaken for wisdom.

Four, and this is the one that matters: cost scales with usefulness

Every other line item in your enterprise behaves the same way. When the number goes up, that is bad. When the number goes down, that is good. The entire apparatus of variance reporting is built on this, and until now it has never once been wrong.

AI inverts it.

If your AI capability is genuinely useful, people will use it more. If they use it more, it costs more. Growth in spend is what success looks like. Growth in spend is also what failure looks like, if what is actually happening is that a badly configured workflow is calling an expensive model in a loop.

These two things are indistinguishable on a bill. Identical shape, identical color, identical position in the variance report. One of them is the best thing that happened to your organization this year. The other is a slow fire.

This is the entire reason AI FinOps exists as a distinct discipline. Not because AI is expensive. Plenty of things are expensive, and enterprises have managed expensive things for a century. It exists because AI is the first major category of enterprise spend where the cost number, on its own, carries no information about whether the money was well spent.

Which means the traditional question, are we paying too much, cannot be answered. It is not a hard question. It is a malformed one. The question that can be answered is: are we getting enough for what we are paying? And that requires a denominator, which almost nobody has, which is why the meeting at the top of this article ends in a stalemate every single time.

Three ways this goes wrong

Having watched a fair number of jungles work through this, the failures cluster into three shapes.

Panic capping. The Crow sees a number, does the only thing available to her, and imposes a hard limit. Spend drops immediately, which looks like a win for about six weeks. What actually happened is that the highest-value users hit the ceiling first, because they were using it most, and they quietly went back to their old process. Twelve months later the organization concludes that AI did not deliver. It delivered. It was switched off.

Blind scaling. The opposite failure, and more common in the first year. Nobody looks at all, because the numbers are small and the enthusiasm is high. The Mandrill, who runs a large territory and is not a fool, has correctly worked out that being seen to move fast on this is worth more to his career than being seen to be careful. So he moves fast. By the time anyone looks properly, the spend is embarrassing and the political cost of an honest review is now higher than the cost of continuing.

Theater. The most expensive one, because it feels like progress. Somebody builds a dashboard. It shows spend by team, by model, by month, in three colors. It is reviewed monthly. It changes no decisions, because it shows only the numerator. Every meeting becomes an argument between people with opinions and no facts, held in front of a very attractive chart.

The Field Kit

Concrete things to do this week.

If you sit in the Crow’s chair, stop asking for total spend and start asking for cost per completed unit of work. Not cost per token, not cost per user, not cost per API call. Cost per resolved case, per accepted draft, per processed invoice, per whatever your business actually produces. You will not get a good answer the first time. Ask anyway. The absence of an answer is itself the most useful finding available to you right now.

If you sit in the Crocodile’s chair, instrument at the request level before anyone asks you to. Every call tagged with the team, the use case, and the business purpose. This is tedious, it is unglamorous, and it takes about three weeks. Retrofitting it after twelve months of production traffic takes about three quarters, and you will have no historical data either way. This is the single highest-leverage thing on this list.

If you sit in the Mandrill’s chair, name your denominator before you fund anything. Write down, in one sentence, what unit of work this is supposed to make cheaper or faster or better, and how you will know. If you cannot write that sentence, you are not funding a capability. You are funding a Hummingbird.

For everyone: find out today whether anyone in your organization can tell you what your AI spend was last month, broken down by business purpose. Not by vendor. Not by model. By purpose. The answer takes ten minutes to obtain and tells you almost everything about where you are.

Jungle Lesson 1

A cloud bill tells you what you bought. An AI bill tells you what you did. The first can be reviewed as a decision. The second can only be understood against a denominator, and if you do not have one, you do not have a cost problem yet. You have a measurement problem that is about to become a cost problem.

Next time: the Crow, the Fox and the Crocodile all describe the same system using three different vocabularies, none of which convert, and discover that the reason the meeting keeps failing is not disagreement. It is that nobody has defined a shared unit of account. Lesson 2 is about the three tribes and the one bill.

I spend most of my working life in rooms like the one at the top of this piece. If your jungle is currently having this argument, I would be interested to hear how it is going.