Here is the shape of the problem, and you have almost certainly met it. You stand up an agent to do something genuinely useful — triage an inbox, draft a reply, reconcile two records, flag the one thing in a hundred that a human should see. It half-works. It misses the obvious and flags the trivial. So you do the thing the whole industry trains you to do: you reach for a better model. The bill goes up. The behaviour gets a little better. And you file a mental note to try again when the next flagship ships.

I ran exactly that loop on my own email for longer than I would like to admit. And the reason it never resolved is that I was reading the wrong meter. The expensive part of that agent was never the decision. The decision — is this worth interrupting me for — is a single, cheap judgement. The expensive part was everything the model had to read and understand before it could make that judgement well. I was paying frontier prices for comprehension and calling it intelligence.

Two different things on one invoice

Split the invoice in two and the whole strategy falls out of the arithmetic. There are two ways an agent can get the intelligence it needs, and they behave like completely different line items on the books.

Model capability is an operating expense. You rent it. You pay for it on every single call, forever, and it depreciates — the model you tuned against this quarter is a legacy dependency next quarter, and the premium you paid for its cleverness evaporates the day a cheaper model clears the same bar. Renting intelligence per call is the pure-opex way to run an agent: no asset accumulates, and the meter never stops.

A compiled worldview is a capital expense. You build it once. Comprehension is paid a single time, per source, when the material is ingested and turned into a durable, structured artefact — and from then on every call every agent ever makes reads from that asset instead of re-deriving it. It does not depreciate with the next model release; it appreciates under maintenance, because each pass adds structure and cross-references the last pass could not see. This is the doctrine we have argued elsewhere under the banner that when execution gets cheaper, the constraints on execution become more valuable — here it takes a specific, accountable form.

Put like that, “wiki plus a mini model” versus “frontier model plus raw context” stops being a clever engineering preference and becomes something older and duller: substituting capital for marginal spend. It is the oldest industrialisation move there is. You build the machine once so that each unit costs less to produce forever after. The wiki is that machine, and comprehension is the unit it produces cheaply.

Name the trade: context arbitrage

Once you can see the two line items, the strategy names itself. There is a large — and, on every trend line I can find, widening — price gap between the frontier tier and the utility tier of models. Arbitrage is what you call it when you can buy the same underlying value on the cheap side of a spread and the market keeps paying the expensive side. A compiled worldview is what lets you do exactly that: capture the frontier-to-utility price spread on every task whose difficulty was context-depth masquerading as intelligence-depth.

The tell that a task belongs on this book — that you have been overpaying — is the double movement from the insight box above. When you add the substrate, the quality ceiling goes up (the agent gets noticeably better) and the model floor goes down (a far cheaper model now suffices) at the same time. Those two moving together are diagnostic. If a missing asset were not the problem, adding it could not improve quality and reduce the model requirement at once. That it does both is the receipt: you were paying frontier prices to compensate for a missing asset, not to buy intelligence the task actually needed.

You were paying frontier prices to compensate for a missing asset. The bigger model “sorta helped” because intelligence can paper over missing context — expensively, and only a little.

This is a different claim from the one this field guide's predecessor made, and the two fit together. The Scout and the Senior showed how to split a single agent along a time seam — a cheap read-only scout that explores and a frontier senior that decides — so you buy frontier judgement without paying frontier prices for the exploration that feeds it. That was the shape of one agent's loop. This book is about the asset that both halves read from, and the accounting that asset changes. The scout reads cheaply; the wiki is what makes cheap reading worth doing, because it is where the comprehension is banked.

The reader question this book answers is blunt and practical: how do I cut agent running costs without cutting quality? The answer is not a smaller model bolted onto the same broken setup, and it is certainly not a bigger one. The answer is to build the comprehension once, book it as capital, and spend utility-class prices on everything downstream. The rest of Part I puts numbers on that trade — what the capital actually costs, when it pays back — and then names precisely which of your tasks qualify. We start with the bill.

Two years ago my knowledge wiki was a clever thing I was slightly embarrassed by. It cost real money to build: every source went through a chain of model calls to be read, summarised, cross-referenced and filed, and the whole process was unmistakably extravagant for a personal project. Today the same machine runs nightly for cents, and the embarrassment has inverted — it would be extravagant not to have it. Nothing about the idea changed in between. What changed was the price of comprehension, and once that dropped, the capital-versus-opex trade from the last chapter stopped being a philosophy and became an arithmetic you can actually run.

So let us run it honestly, trade-offs first. This chapter is the part where a fair critic pushes back — a wiki is expensive to build; are you sure it pays? — and the only good answer is a number.

The capex is real, and it is lossy

Start by conceding what the trade actually costs, because pretending otherwise is how people talk themselves into building substrate for tasks that will never repay it. Wiki ingestion is expensive: it is many model calls per source, not one. It is synthetic augmentation — the agent reads the raw material and writes a compiled understanding of it, a summary-of-sorts that adds structure and cross-references. And it is lossy. The compiled page is not the source; detail is deliberately dropped so that relationships can fit. That loss is a feature, not a bug — but it means the wiki is genuinely a different, smaller, self-describing asset, not a free copy of your corpus.

That distinction is the whole discipline. The wiki is a capital asset, and capital assets are justified by utilisation. A press that stamps one part is a waste; a press that stamps a million parts is a factory. Reach for the substrate where the same comprehension will be read again and again, and leave the genuinely one-shot questions to cheaper, dumber tools.

The cost model, on an envelope

Here is the model in three quantities. The numbers below are illustrative — they are round figures to show the shape, not a benchmark of your workload — but the structure is exactly the one that governs the decision.

Eight hundred calls sounds like a lot until you notice the unit. A triage agent that runs on every inbound email, or a reconciliation pass that runs on every transaction, crosses eight hundred calls in days, not quarters. That is the point of expressing break-even as a call count rather than a payback period: the tasks worth compiling are exactly the high-frequency ones, and for those the calendar to break-even is trivially short. A task that fires eight hundred times a year would take a year to pay back the same asset — which is precisely why low-frequency work stays in the opex column.

The spread is not a rounding error you are clever to exploit; it is a structural, published feature of the market. A flagship model and a utility model from the same lab differ in per-token price by an order of magnitude or more, and prefix caching widens the effective gap further on any workload that re-reads a stable context — which is every wiki-backed loop, because the compiled worldview is a stable prefix. The arbitrage exists because the market prices intelligence, and most of your tasks are quietly buying comprehension with it.

Amortisation is the whole game

Strip everything else away and the number that decides the trade is one division: the capex divided by the reuse count. That quotient is the marginal cost of comprehension that finally shows up on your bill.

How the asset is actually built — how raw sources become a self-maintaining graph of claims and edges — is a craft in its own right, and one we have documented separately; treat it as given here. This chapter's job is only to insist that before you build it, you can name C, name S, and know your N*. If you cannot, you are not doing arbitrage. You are doing a science project.

Which raises the question the whole strategy depends on: which of your tasks are the high-reuse, context-shaped ones worth compiling — and which merely look like they need a smarter model? That is the next chapter, and it is the most expensive mistake in the field to get wrong.

The arbitrage from Chapter 1 only pays if you can tell which tasks are on the trade and which are not. Get that wrong in the safe direction and you build a wiki for something that genuinely needed a smarter model — wasted capex. Get it wrong in the expensive direction, which is far more common, and you spend years renting frontier intelligence to fix a task that a utility model plus a substrate would have nailed for a fraction of the price. So this chapter is a classifier: what does an arbitrage task look like, and what doesn't?

Most agent work is triage wearing a costume

Look closely at the agentic work that actually fills an enterprise and a pattern jumps out. It is overwhelmingly this: routing, triaging, drafting, flagging, reconciling. A support message arrives — which team? A document lands — what kind, and does anyone need to act? A draft reply — in this customer's voice, given this history. Two records disagree — which is right? None of these are hard decisions. Each is a simple call. What makes them hard is that the simple call is impossible until you have read and understood a great deal of context.

Read the italics. Every one of those tasks is trivial in the abstract and hard only because of the clause that follows — the “given everything already in flight,” the “given how this org actually works.” The difficulty lives entirely in the context, not in the reasoning. The decision is simple once you have read enough, and reading enough is the expensive part.

The misdiagnosis loop

The costume is convincing, which is why the whole industry keeps making the same mistake in the same order. The agent underperforms. The failure gets read as a capability gap. The response is to wait for a better model, or pay for a bigger one now. The bigger model helps a little — because raw intelligence can partially compensate for missing context, at a price — and that little bit of help is exactly the poison, because it confirms the diagnosis. So the loop repeats on the next release, and the next, each turn spending operating expense on what was always a capital problem.

The one-question diagnostic

You do not need a framework to tell the two apart. You need one question, and it is the ceiling-and-floor tell from Chapter 1, run as an experiment rather than an intuition: does a bigger model fix it, or does more context fix it? Hold the model fixed and add the context the task keeps reaching for. If quality jumps, the difficulty was context-depth — you have found an arbitrage task, and the correct move is substrate, not spend. If adding context changes nothing and only a smarter model moves the needle, the difficulty really is intelligence-depth, and this task is not on the trade.

The industry keeps misdiagnosing context-depth as a capability gap and waiting for a better model. The fix was substrate — and the substrate is buildable today, with the models already on the rankings page.

Where the substrate genuinely doesn't help

Fit, not hype — so here is the boundary, stated plainly, because a strategy that claims to fix everything fixes nothing. Some agent work is genuinely a capability or tooling problem, and a wiki does nothing for it. The tasks that are closed-world and tool-shaped — a continuous-integration fixer, a form-filler, anything whose entire knowledge lives inside its own APIs and inputs — do not have a missing-context problem. There is no worldview to compile because the world is the tool surface, and that is fully specified already.

That boundary matters because it keeps the strategy honest and keeps you from compiling substrate for tasks that will never read it. With the classifier in hand — simple decision, deep context, high reuse, fixed by more context rather than more model — Part I is done. We have the trade, the cost model, and the shortlist. Now the proof. Part II takes the single clearest instance I own, watched end to end, where the same model went from stranger to genius without getting one bit smarter.

I run my recurring, scheduled agent work on OpenClaw — the cron-shaped jobs that quietly do things while I get on with my day. Early on, I gave one of them access to my Gmail and asked it to do the most ordinary agentic task there is: triage. Tell me what deserves my attention; leave the rest alone. It was hopeless. It interrupted me about newsletters and receipts, stayed silent on the one thread that actually mattered, and generally behaved like a temp on their first morning who has been told to “flag anything important” and has no idea what important means here.

Then I gave it a wiki — a compiled worldview built from a few years of my email: who these people are, what we have going, what I care about, what I have already dealt with. I did not change the model. I did not rewrite the agent. I changed the input. And the same agent became a genius at triage. So much so that it now hardly ever tells me about my email at all — which, it turns out, is roughly the right angle.

Because nothing else moved, the experiment is unusually clean. This is not “a better setup performed better.” It is the same model, the same code, the same mailbox, with exactly one variable changed — whether the agent had access to a compiled model of my world — and the behaviour went from useless to uncanny. The next chapter treats that cleanliness formally, as a controlled experiment. This chapter is about why it works, because the mechanism is the reusable part.

Why triage was impossible without it

The task “is this email worth interrupting me for” feels like a judgement about the email. It is not. It is a judgement about the relationship between the email and everything else I know. An invoice is worth flagging only if I did not expect it, or if the amount is wrong, or if it is from someone I am in dispute with — and none of that is in the email. It is in my world. Which means triage is, mechanically, a diff operation: compare this new thing against the established state, and surface the delta. And a diff is impossible without something to diff against.

This is why the generic version of this product is useless and the wiki-backed version is not. “Is this interesting?” is not a property of an item. It is a relation between the item and what you already know. An AI news summariser that has never met you can tell you what an article says; it structurally cannot tell you whether it is interesting to you, because interesting-to-you is a diff against a model of you that it does not possess. The wiki is that model, which is why the same operation that is impossible for a stranger is trivial for an agent that has one.

A genius reading your inbox cold is still a stranger. Intelligence cannot reason from information it does not have — and a triage decision is almost entirely information you never put in the prompt.

Silence is the expensive output

The part people find counter-intuitive is the success metric. A triage agent that talks a lot feels like it is working — look, it is doing things! But volume is failure. The whole value of triage is suppression: correctly deciding, hundreds of times a day, that something does not deserve your attention, and staying quiet. My agent “hardly ever tells me about my email” is not a bug report. It is the high-judgement output. Every silence is a correct, confident, context-rich decision that this did not clear the bar.

Notice what this does to the model requirement. Once the wiki holds the world to diff against, the actual cognitive act left for the model — compare, and decide if the delta clears a threshold — is small. It does not need frontier reasoning. It needs to read the compiled context and make a simple call, which is exactly the profile a utility-class model handles well. The economics of that — why the mini model is not a compromise but the correct choice once the substrate exists — are the capex/opex flip from Part I, and I will not re-derive them here. This chapter's job was the mechanism: judgement is a diff, and the wiki is what you diff against.

Which sets up the sharper claim. My inbox did not improve through one lucky configuration. It improved after I had, without quite meaning to, run every hypothesis the industry holds about why agents fail — one after another, on the same task. The next chapter lays that accidental experiment out, because the three failures are as instructive as the one success.

The Gmail story from the last chapter is more valuable than a single before-and-after, because the “before” was not one thing. Over the months I spent trying to make triage work, I marched through every mainstream explanation for why an agent underperforms — each in turn, each a real attempt, each a failure. What I did not realise at the time is that I was running the field's three competing hypotheses as a controlled experiment on one fixed task. Here they are, with a fair mechanical account of why each one fails, because the failures rhyme.

Hypothesis 1 — the knowledge fits in the prompt

The first instinct is to tell the agent what matters. So the system prompt grows: here is who is important, here is what urgent looks like, here is how to handle this kind of sender. This is the prompt-stuffing hypothesis, and it fails because a prompt is a fixed-resolution photograph of the territory, taken at write time, for every future question at once. Whoever writes it has to guess in advance the exact level of detail every future email will need — so it is simultaneously too much (the agent pays attention budget on all of it, every single turn, relevant or not) and too little (the one detail this email needed was below the resolution the author happened to choose). You iterate the prompt forever because every miss looks like a missing sentence, and every added sentence dims the attention available for the rest.

Hypothesis 2 — memory will accrete over time

The second instinct is to let the agent remember. Give it a memory store and let it accumulate notes as it goes; surely it converges. This is the accretion hypothesis, and it fails more subtly. An append-only memory log stumbles into relevance one incident at a time. There is no synthesis — nothing ever steps back and reconciles what the notes collectively mean. There are no edges — nothing connects “this sender” to “that project” to “that commitment.” And there is no janitor — nothing prunes the stale or resolves the contradictory. It is drip-filling a lake and hoping for a map. It will take a very long time to get anywhere useful, and it will never get structure, because accretion is not compilation.

Hypothesis 3 — capability substitutes for knowledge

The third instinct is the expensive one, and the one this whole book is written against: throw a better model at it. I did. And better models sorta helped — the two most costly words in the field, because that faint improvement reads as confirmation. But it fails for a reason no amount of capability can fix: intelligence cannot reason from information it does not have. A more brilliant model reading my inbox cold is a more brilliant stranger. It can be dazzling about the text in front of it and still have no idea that this invoice is unexpected, or that this quiet sender is the one I have been waiting on, because that lives in a world it was never given.

Three hypotheses, three failures, and they fail for one shared reason: none of them gives the agent a compiled, structured, current model of the world to diff against. The prompt freezes the world at one resolution; the memory log never compiles the world at all; the bigger model reasons beautifully about a world it cannot see. Then I built the substrate — the wiki that synthesises, cross-references, and maintains — and pointed a mini-class model at it. The agent went from hopeless to perfect. The one variable that moved was the only one that had ever mattered.

The claim you can falsify in your own logs

This is the part that matters commercially, because it is not a philosophy — it is a bet you can settle. The experiment yields a falsifiable, demonstrable claim: a utility-class model with a compiled worldview outperforms a frontier model without one, on a real workload. Not a benchmark, not a vibe — a specific inbox, a specific agent, a result sitting in the cron logs. Run it yourself: take a context-shaped task, run it two ways — mini-plus-wiki against frontier-plus-raw — and measure both quality and cost. My prediction, from n-equals-one lived at close range, is that the cheap side wins on both axes at once.

Mini-plus-wiki beats frontier-plus-raw on the work that actually pays. It is the cheapest claim in AI to test and the most expensive one to keep ignoring.

That is the flagship proven: one task, four attempts, one variable, a clean result. The obvious objection is scale — fine for one person's inbox, but does the trade hold when the corpus is a whole organisation rather than a mailbox? It does, and it gets more interesting, because at organisational scale the cheap layers start doing something the frontier model cannot do for itself. That is Part III.

The Gmail case scaled the trade down to one person. This chapter scales it up to a whole business, because the arbitrage behaves differently — and reveals something new about itself — when the corpus is an organisation rather than an inbox.

I built an OpenClaw system for a dental practice. Deterministic collectors pull the raw operational data. Above them sits a stack of summarisation layers modelled deliberately on how humans report inside a company: a subordinate writes detailed reports, a manager compresses them, that rolls up quarterly, and eventually someone writes the board paper. I put progressively more capable models at each level, and at the very top a frontier model does a “board pass” over the compressed whole. And the board pass produced the best ideas in the entire system — the cross-silo kind, the ones that read as genuinely creative: YouTube did unusually well this quarter; push that theme into the other channels, pillar-post it, reuse the idea across the practice.

The seductive wrong answer

The obvious reading is that the frontier model is simply smarter, and smartness is what surfaces at the top. That reading is wrong, and getting it wrong will cost you, because it tells you to spend on the model when the leverage is somewhere else entirely.

Here is the mechanical account. Cross-fertilisation — noticing that a pattern in one silo applies to another — requires simultaneous visibility of the silos. You cannot connect YouTube to email marketing to recall rates unless all three are in view at once. And simultaneous visibility of a whole business is not an intelligence problem. It is a cost problem. The reason no one had those cross-silo ideas before was not a shortage of cleverness; it was that nobody — and no model — could afford to hold the entire breadth of the business in view at the same time. The cheap summarisation layers solved that. They compressed the organisation's breadth until it fit inside a single frontier context window.

Utility models are the optics; the frontier model is the eye. The optics are cheap and you need a lot of them; the eye is expensive and you need exactly one, pointed at what the optics compressed into view.

The human analogy is not a metaphor — it is the same mechanism. A corporate reporting hierarchy exists so that a board can see the entire company at once, badly. It is compression infrastructure built out of people, and its entire purpose is to trade fidelity for breadth until the whole thing fits in the few hours a board has. The AI pyramid does exactly that, faster and cheaper, and the “creativity” at the top is the same creativity a good board shows: the product of finally seeing everything together.

That allocation — commodity models on the breadth, a frontier model on the single judging pass — is the Model Barbell from The Scout and the Senior, and I will not re-derive it here. The point worth adding here is what it looks like when the barbell is arranged vertically, as a pyramid: the cheap end manufactures visibility, the expensive end spends it on judgement, and the arbitrage is that you only pay frontier prices for the one pass that actually needs to see everything.

Give the eye legs: reports become map layers

There is a flaw in the pyramid as I first built it, and the wiki suggests the fix. A pure summary cascade is one-way lossy compression. By the time information reaches board level, its provenance is gone. The apex model reads “YouTube did well” but cannot interrogate why, cannot descend to the underlying rows, cannot check whether the pattern is real or an artefact of one good week. It sees, but it cannot look closer. A board that can only read the summary and never ask a follow-up question is a board flying blind above a certain altitude.

The upgrade is to keep the cadence and the levels — they are genuinely useful compression — but make each level a map layer rather than a dead report. Give the apex model the top-level view and the drill-down toolbelt. Now when it spots the YouTube anomaly, it can descend to the underlying rows, confirm the pattern is real, and come back up with a claim that carries its source. The eye stops being a passenger of the summary and gets legs. This is the same read-side resolution ladder that governs decision-navigation interfaces elsewhere in the canon — here pointed at an organisation's own reporting stack.

The trade scales. Now the harder question, the one every buyer eventually asks: if the whole value lives in a compiled worldview that takes months to build, how does anyone ever get one started — and what stops a competitor from copying it? That is cold start, and it turns out the barrier and the moat are the same object.

Every wiki-backed product runs into the same wall, and it is worth stating in the buyer's own sceptical voice: the demo only sings because you have five hundred pages compiled about yourself. A new customer has nothing. So the product is only impressive once it already knows them — which is exactly when they don't have it yet. That objection is correct. It is also, once you turn it over, the best thing about the whole architecture.

The moat isn't the app

Start with what is actually defensible. It is not the reader app, the triage agent, or the interface — a competent team can clone any of those in a weekend. The defensible asset is each user's compiled worldview: the months of ingestion that turned their raw exhaust into a structured, cross-referenced model of how they think and what they care about. It takes real time to build and it compounds with use. A competitor can copy your product and still have nothing, because the value was never in the software. It was in the asset the software reads from — and that asset is per-user and non-transferable.

And here is the turn. The thing that makes the moat deep — that it takes months of ingestion to build — is precisely the thing that makes cold start hard. You cannot have one without the other. A worldview cheap enough to build in a minute would be worthless as a moat, because your competitor could build one too. The barrier and the moat are the same object, viewed from two sides. Which means the goal is not to eliminate cold start — that would eliminate the defensibility. The goal is to make cold start survivable.

The same object that blocks adoption is the one competitors can't copy. Don't try to remove the wall — the wall is the moat. Find the door.

Nobody starts from zero

The door is this: a new user is not actually empty. They arrive carrying years of exhaust — the by-product of work they have already done, sitting in systems they already own. Onboarding is not a cold build from nothing. Onboarding is ingestion of exhaust that already exists. The cold-start problem is really a “we haven't ingested your existing corpus yet” problem, and that corpus is large, real, and available on day one.

The same move works for a business, pointed at a different corpus. The SMB version of onboarding is a whole-practice operating review: you sit down and ingest how the business actually runs — its records, its reporting, its recurring decisions — and that review is the capex event from Part I. Build the practice's wiki once, and everything downstream gets smart at utility-class prices. Personal news curation and small-business advisory are not two products; they are one architecture pointed at two corpora. The proposal-compiler line of work made the same bet from the other direction — that a bespoke artefact per customer beats a generic one — and this is its supply side: the compiled worldview is what makes the bespoke artefact cheap to produce.

That curve changes how you price. If quality is flat until a coverage threshold and steep after it, then a free trial — which by design minimises onboarding to reduce friction — delivers the customer precisely the flat, unimpressive part of the curve and calls it the product. Minimising onboarding minimises the product. The capex event should be priced as a capex event: a paid engagement, or a deliberate onboarding investment, not friction to be sanded away. You are not lowering a barrier to entry. You are selling the construction of an appreciating asset.

And the retention story falls out honestly, which is rare. Because the wiki appreciates with use, switching cost compounds in the good direction: a customer who leaves abandons an asset they paid to build and that got better every month — not a contract they resent. Lock-in by accumulated value rather than by penalty is the only kind worth having, and it is the kind this architecture produces by default. The moat, the barrier, the onboarding and the retention are all the same object seen from different chairs: the compiled worldview.

One question remains, and it is the strategic one that reframes the whole trade. If the cheap, context-shaped work is where the value now lives, then which model releases should you actually care about — and why has the industry been watching the wrong ones?

Here is a confession, and it is the honest through-line of this whole book. Every time a lab shipped a new flagship model, I got excited. Benchmarks, demo day, the works. And I had it backwards. The releases that actually transformed my systems were the ones nobody threw a launch party for: the quiet announcements that the same intelligence now cost a fraction as much, cached, per token. Those were the events. I just could not see them, because they did not look like events.

Legible steps versus invisible exponentials

The asymmetry is structural. A frontier release is a legible event — it has a name, a benchmark table, a keynote, a step you can feel. “The same capability for a twentieth of the price, with prefix caching” is an exponential with no press release. It does not trend on launch day because it does not have a launch day; it is a curve, and curves are invisible until you plot them. But the price curve is the diffusion event — it is what actually changes what gets built — and I was watching the fireworks while the tide came in.

The reason this matters is that the binding constraint on the whole strategy was never judgement quality. Top models have been smart enough to do the judging for a while. What was uneconomical until recently was reading everything — and an exploration-heavy architecture spends the overwhelming majority of its tokens on reading. The constraint that actually moved was the unit cost of comprehension, and cheap-fast-cached models collapsed it. That collapse is what turned my wiki from a clever-but-extravagant toy into something that runs nightly for cents. The capability existed all along; the economics arrived later, and the economics were the event.

The dividend lands bottom-first — and only for the architected

Now the claim that is new on top of the well-worn “models are getting cheaper.” The model dividend does not land evenly. It lands bottom-first: each new cheapest-viable model widens what the readers — the scouts, the ingestion loops, the summarisation layers — can afford to read, and that compounds through every agent that shares the substrate. A frontier improvement, by contrast, only sharpens the single terminal pass. So the boring end of the barbell is where the compounding lives, and the exciting end just gets a little sharper.

But the sharpest version of the point is about who gets the dividend. Frontier gains are distributed evenly: everyone rents the same new brain on the same day, so no one gains a relative advantage. Cheap-token gains flow disproportionately to whoever has an architecture that can spend volume — exploration-shaped systems, ingestion pipelines, reading layers. Without a substrate to pour cheap tokens into, a price collapse just buys you a cheaper chatbot. With one, it compounds through everything you have built.

A price collapse is just a cheaper chatbot to everyone without a substrate, and a compounding advantage to everyone with one. The boring release is only boring if you have nothing to pour it into.

The correction I owe my own earlier writing

I have to correct something I published years ago, because the correction is the cleanest statement of the thesis. When the first DeepSeek model landed, I wrote that the unit economics of AI had finally dropped far enough to process data at the row level — and I was thinking about structured data. That was aiming the insight at the one domain that never needed it. Structured rows never required cheap AI; SQL has processed them essentially for free for forty years. What never had a per-unit price before was comprehension — and comprehension is only needed where structure is absent. Cheap models are the first technology that prices understanding by the document, by the email, by the unstructured thing. So the old thesis was right about the threshold and pointed at the wrong continent. The unstructured world was the entire addressable market.

Someone whose tokens are effectively free — a well-funded lab, an individual on an unlimited plan — can miss this distinction entirely, because the price of comprehension never enters their calculation. The operator running lean, the team of one, lives exactly at the price point where it is the whole game: cheap comprehension is the only reason a solo operator can afford to compile a worldview at all.

The honest amendment

This is not cheap-model triumphalism, and the amendment matters as much as the thesis. The frontier model keeps its monopoly on the smallest, highest-leverage token count in the whole system: the design conversation, the terminal judgement, the board pass from Chapter 6. Those tokens are few and they are decisive, and you should buy the very best model for them without flinching — the bill stays small because there are so few of them. The barbell did not collapse toward the cheap end. The two ends got more different: the exciting end became less scarce, and the boring end became more valuable. Both movements point the same way — toward the architecture that can tell the two apart and price each correctly.

Which is the whole book, now ready to be stated as a strategy rather than a set of observations. If cheap comprehension is the event, and most of your tasks are comprehension in disguise, then there is a repeatable move here — a way to find the mispriced work and capture the spread on it deliberately. That is the last chapter.

Everything in this book compresses to one move, repeated at every scale. Build the comprehension once, book it as capital, and run the recurring work on a utility-class model that behaves as though it knows the domain — because it does. An inbox proved it at n-equals-one. A dental practice proved it at organisational scale. The cost model said when it pays back; the cold-start chapter said how to start and why it defends itself; the price-curve chapter said why the cheap end is where the compounding lives. What is left is to turn all of that into something you do on Monday.

Find your arbitrage book

Arbitrage begins with an inventory of mispriced positions. Yours is a list of agent workloads, scored with the one-question diagnostic from Chapter 3. For each task, ask honestly: does a bigger model fix this, or does more context fix this? The tasks that more context fixes are your arbitrage book — every one of them is a place you are currently paying frontier prices to compensate for a missing asset. Rank that book by frequency times current model cost, because that product is the size of the spread waiting to be captured, and it tells you what to compile first.

The procurement test

The falsifiable claim from Chapter 5 is also your procurement test, and it settles the argument with evidence instead of opinion. Take the top task on your arbitrage book and run it two ways: utility-model-plus-wiki against frontier-model-plus-raw. Measure both quality and cost. This is the whole bet, made small and cheap and local — not a benchmark someone else ran, but your task, your data, your logs. My prediction, from having lived it, is that the cheap side wins on both axes at once. If it does, you have found a spread. If it does not, that task belonged in the intelligence-depth pile and you have learned that cheaply.

Start narrow on purpose. The temptation is to compile everything; the discipline is to compile the one thing that will be read a thousand times, prove the spread, and let the asset earn its way outward. Each task you add rides on the comprehension the last one banked, which is what it means for the asset to compound — and it is the same logic by which specifications, not code, became the appreciating thing to own in the build-versus-buy decision.

Where the asset went

Step back and see what the trade actually did. It moved the value out of the model — where the market can reach it, reprice it, and hand your competitor the same thing on launch day — and into a compiled worldview that is yours, per-user, appreciating, and unshippable by anyone upstream of you. The frontier model keeps its monopoly on the apex: the design conversation, the terminal judgement, the one pass that has to see everything. You keep the spread on everything below it. And because the worldview feeds back on itself — every use leaves exhaust that compiles into the next version — the advantage does not merely persist. It widens.

Stop waiting for a model that makes your agents smart. Build the asset that makes a cheap model behave as if it already knows your world — and buy the spread on every task the market keeps mispricing as intelligence.