The Beaver took the Crow back to the river.

He had described it to her a long time ago, in the first week of all this, when he was explaining why the Watering Hole could not be governed the way a dam is governed. I can show you the dam, he had said. I can only show you the river, and the river does not consult me.

What he wanted to show her now was what the river was carrying.

He picked a single ordinary request, one of thousands that day, and laid out everything that had travelled with it. The question the animal had actually asked, which was two lines long. Then the instructions, which had grown over eighteen months and now ran to several pages. Then twenty retrieved passages, because twenty had felt safer than ten when somebody configured it. Then the entire preceding conversation, resent in full, because that was the default.

The question was a rounding error in its own request.

“How much of this,” said the Crow slowly, “do we pay for?”

“All of it.”

“Every time?”

“Every time.”

The Crow, who thinks in things she can count and had spent two acts being told this subject was too technical for her, understood this immediately and completely, and became its most effective advocate in the jungle within about a week. Sometimes the cost lever that changes an organization is the one a finance person can see with their own eyes.

The input is the bigger number

In most mature enterprise workloads, the input costs more than the output.

This surprises people, because the mental model is that you are buying answers. You are buying answers, and you are also paying to ask, and the asking has quietly grown while nobody was looking at it. A two line question wrapped in six pages of context is a six page transaction with a two line payload.

Which means an optimization program focused entirely on the response side is working on the smaller half of the problem. Shortening outputs, choosing cheaper models, tuning generation. All useful, all downstream of a bigger number nobody is watching.

Four sources of bloat

Instruction accretion. System prompts grow every time something goes wrong and never shrink. This is the big one and it gets its own section below.

Retrieval over-fetch. Somebody set the retrieval depth during development, chose a number that felt safe rather than a number that was measured, and it has been fetching that many passages on every request ever since. The difference between ten and twenty is invisible in quality and completely visible on the invoice.

Conversation accumulation. Full history resent at every turn in workflows that do not need it. Some workflows genuinely do. Many are single-shot tasks carrying a conversation transcript for no reason other than that the framework does it by default.

Defensive stuffing. The entire document included because working out which section was relevant was harder than not working it out. Entirely rational for the person who did it. Permanent for the organization.

The immortal instruction

Instruction accretion deserves its own section because of how it happens, which is that it happens for good reasons every single time.

Something goes wrong. A model produces an output somebody objects to. There is an incident, or a complaint, or an uncomfortable meeting. The fastest available fix is to add a line to the instructions telling it not to do that again. It works. Everyone moves on.

That line is now sent on every request, forever. It costs a small amount, every time, in perpetuity. Repeat this thirty times over two years and the instructions are several pages long, most of which is scar tissue from incidents nobody remembers.

Now try removing one. You cannot know which lines are load-bearing without testing, and testing costs effort, and the downside of removing the wrong one is another incident with your name on it. So nobody removes anything. There is no organizational mechanism for deletion here and no career incentive to build one.

The Fox tried this in the following quarter. Of the lines his team could not immediately justify, a substantial portion turned out to make no measurable difference to output quality at all. Some of them had been added to solve problems in a version of the workflow that no longer existed.

Caching, and why nobody uses it properly

The highest-leverage lever in this post, and one of the most under-used things in enterprise AI generally.

If the front portion of your request is identical across many requests, it does not need to be processed from scratch every time. The saving on a workload with large stable instructions and small variable questions is substantial.

The reason it goes unused is almost never that people do not know it exists. It is that it requires the invariant content to sit at the front and the variable content at the back, which requires somebody to have thought about prompt structure as an engineering concern with a cost consequence, rather than as writing.

Most prompts are assembled in the order they were thought of. The instructions grew, the context got appended, the question went wherever felt natural. Nobody was wrong. Nobody was thinking about the ordering, because at pilot scale the ordering did not matter and by production scale nobody was looking.

Restructuring for cache hits is days of work with a permanent return. It is close to the best return per unit of effort available in this entire series.

Retrieval precision is a cost lever

Worth stating explicitly because it is one of the rare places where the cheap option and the good option are the same option.

Better retrieval means fewer passages needed to answer well. Fewer passages means less context. Less context means lower cost and, frequently, better output, because a model given ten relevant passages generally does better than one given twenty of which half are noise.

So retrieval tuning pays twice. Almost every organization treats it purely as a quality activity, funds it from a quality budget, and never connects it to the cost line it is directly driving. Making that connection visible is often what gets the work prioritized.

Context efficiency

The measurement I would introduce, imperfectly, rather than not at all.

What proportion of the context you supply actually influences the output? You cannot measure this precisely. You can approximate it, by ablation, by sampling, by simply checking whether retrieved passages are ever referenced in the answer.

Even a rough number changes conversations, because it converts an invisible cost into a visible ratio. A capability sending six pages of context to produce a two line answer with three relevant passages has a number attached to it now, and numbers get optimized in a way that vague concerns do not.

Why this compounds

One forward-looking point, because it is the reason this lesson sits where it does in the series.

In a single-call workflow, context bloat is additive. You pay for it once per request. Annoying, fixable, bounded.

In an agent workflow, context is re-transmitted at every step of the loop. A single lazy prompt is now being paid for five, ten or forty times per task, depending on how many steps the system decides it needs. The bloat multiplies rather than adds.

Which means every piece of context hygiene you do now becomes considerably more valuable the moment anything in your estate becomes autonomous. That is the next lesson and it is the one where all of this compounds badly.

Three ways this goes wrong

The immortal instruction. A line added during an incident two years ago, sent on every request since, purpose unknown, removal feared, cost permanent.

Cache-hostile structure. Variable content at the front, destroying prefix caching entirely, usually because nobody knew the ordering had a price.

Fetch and forget retrieval. A depth configured on day one, never tuned, treated as a quality setting by a team that has never been told it is also a cost setting.

The Field Kit

Concrete things to do this week.

If you sit in the Crow’s chair, ask for the input to output ratio on your largest capability. One number. If input dominates heavily, there is real money in this post and you now have the evidence to ask for it.

If you sit in the Crocodile’s chair, audit the system prompts for lines nobody can justify, and restructure for cache hits. Both are days rather than quarters, and both are permanent.

If you sit in the Mandrill’s chair, stop demanding a prompt addition after every isolated error. Each one is permanent and each one is charged on every request forever. Ask for the fix that has a cost of zero on the other ninety nine thousand requests.

For everyone: give prompt and retrieval configuration a named owner and a review cycle. Unowned, it only ever grows, because growth is what every individual incident rationally produces.

Jungle Lesson 13

You are billed for the question as well as the answer, and in most enterprise workloads the question is the bigger number. Every line added to a prompt after an incident is a permanent tax paid on every request forever, and nobody has ever been thanked for removing one.

Next time: the Tortoise has been saying the same three sentences for four lessons and everyone has been treating them as an obstacle to route around. In this one the room finally understands that she has been describing a cost driver the whole time, and the entire architecture conversation reorganizes itself around her. Lesson 14 is about data gravity, latency floors, and control of the inference plane.

If you want a quick sense of whether this post applies to you, go and read your longest system prompt end to end. Most people have never done this. It is usually a short and instructive experience.