Where value sits · The Durability Curve

You Can Win the Wrong Game for Years

Mon, 14 Sep 2026 00:00:00 GMT

You usually cannot tell whether you are playing the wrong game. Write down what would prove it, and by when.

The Roman Inquisition is remembered as the enemy of science, the machine that put Galileo on trial. The historian Ada Palmer, whose next non-fiction book is a history of censorship, tells a different story. By her count there were twelve trials of scientists over their science, Galileo’s among them, and only one ended in an execution, Giordano Bruno’s. She quotes inquisitors writing to one another that there was no need to bother censoring Lucretius, whose poem sets out a materialist account of nature, since only learned people could read him; what needed censoring was “all of these fine minutiae of Protestantism”. Her conclusion is that censors are always wrong, from where we stand, about what deserved their attention.¹

That is the shape worth seeing. The effort went into one game. What mattered was happening in another. And the people spending the effort were disciplined, organised, and pointed with real precision at the wrong thing.

Right about the technology, wrong about the stock

You can watch the same gap open in a market. Ray Dalio, describing what people miss in a bubble, put it flatly: “they think that they are betting on the technology when they buy the stocks in the companies. That’s not true.”² Technology and the companies built on it are two different games. The internet was every bit as transformative as its believers hoped, yet a great many of the companies that rode it into the public markets in 1999 did not survive the crash that followed.

Being right about the technology and being right about the equity were separate bets.

In both cases the wrong game was the one that felt like progress. Hunting heretics felt like defending the faith. Buying the obvious winner felt like conviction. When effort feels productive, treat that feeling as the cue to check which board you are on. Hold that thought, because the usual cure has a trap of its own.

The trap in looking up

The advice that follows from stories like these is to look one level up. Stop optimising the visible game and find the real one behind it. It is good advice, but following it is also a game you can lose: the instinct to look up can misfire in two ways, and both feel like sophistication.

The dead end that worked

The first is that the crude game you are dismissing quietly carries most of the real one. Take the objective that trains a large language model: predict the next token. For years this was the textbook wrong game. Serious people argued that a system doing nothing but guessing the next token could never understand anything, that it was autocomplete and nothing more, and for a long time the evidence seemed to be on their side, because the outputs were fluent and hollow.³

Then scale turned the same crude objective into the most capable systems we have. Get good enough at predicting the next token, across enough of what people have written, and a great deal of what the sceptics said it could never do comes along with it. Whether that adds up to understanding is still argued over; the capability is plain. The strongest systems add later rounds of training on top, and the core surprise survives them. The people looking one level up were doing the sophisticated thing, refusing the crude surface for the deeper read.

The underpriced number

The second way is different, and worth keeping separate. Here the crude game is a genuine but underpriced piece of the real one, and the sophisticated eye throws it away. Baseball scouts judged a hitter the refined way: the whole player, the swing, the body, the read of someone who had watched a thousand games. They treated the crude stats as beneath that judgement. One of those stats, on-base percentage, the plain rate at which a batter reaches base, was underpriced across the market. Winning still took pitching and a great deal else, and on-base percentage was never the whole game. But it was a real input the practised eye had dismissed, and the Oakland A’s, who bought it cheaply, won as many games in 2002 as a Yankees team paying about three times as much. The economists Jahn Hakes and Raymond Sauer later put numbers to the story: the ability to get on base was valued inefficiently, a team that could read the statistics exploited the gap, and once the knowledge spread the market corrected.⁴

Both look the same from here

Name the two plainly. Sometimes the crude game carries most of the real one. Sometimes it is only an underpriced piece of it. In both of these cases the person insisting you look one level up misread what the crude game could do.

What makes this genuinely hard: from the inside, you usually cannot tell which case you are in, or whether the sceptics are simply right and the crude game is the dead end they say it is. The model doubters had real evidence for years. The scouts sincerely believed a number could not hold a ballplayer. A flat result, or a crude proxy, does not tell you in advance who is right.

Commit the test before you act

So what do you do when you cannot tell? You give up the verdict and keep the discipline. Start by making the gap visible: write down where your effort actually went last cycle, the hours and the attention, and separately what moved the outcome you care about. In slow work, where the outcome has not landed yet, use the nearest honest signal instead, the leading indicator you would stake money on. When the two lists barely overlap, you have a suspect worth testing.

The move that matters comes next, and it is the whole point. Before you re-aim, and just as much before you double down, write down three things: the observable that would prove you wrong, the date by which the payoff should show, and the reason you expect a payoff at all. Take the observable from the outcome that gets scored, or from a signal you trust to track it; one drawn from the game you are playing is a test you can pass while losing. In her book Quit, Annie Duke builds kill criteria from the first two, a state and a date.⁵ The third keeps them honest: a reason you could check, written down before the result comes in.

A game you are grinding on faith and a game that is quietly working both look flat today.

What separates them is what happens by the horizon you named in advance. A result still flat past that date, or showing the sign you said would prove you wrong, counts as evidence against the bet, even if the reason sounds right; the reason only tells you which part of the bet failed. A bet that is flat but inside the horizon, with the reason intact, is still live.

Two moves give the game away: quietly sliding the horizon each time you reach it, and reaching for a new reason every time the old one expires. Either one means you have stopped running an experiment and started telling yourself a story.

Where it matters most

This discipline earns its keep in one place above all: the high-conviction, long-horizon commitments where the payoff is slow and the feedback is thin. The career you have given a decade to. The strategy the whole team believes in. The research bet, the company, the thesis you have already paid for. Those are exactly the places where a flat result tells you least and costs you most.

The inquisitors combed Protestant fine print and judged a materialist poem harmless. The people who called next-token prediction a dead end read the evidence correctly for years and still got the outcome wrong. The scouts trusted their eyes while a team that bought what they had dismissed won as many games on a third of the Yankees’ payroll. You can play your game well and still lose the one that gets scored, and not know until far too late. Before your next big push, name the observable, the date, and the reason, then believe the answer when it arrives.

Free download: The Game Check. A one-page card for naming what would show you wrong, and by when, before your next big push. Name the observable, the horizon, and a reason you can check, then come back on the date. Yours to keep. Get the free card

Ada Palmer in conversation with Dwarkesh Patel, “Why Leonardo was a saboteur, Gutenberg went broke, and Florence was weird”, Dwarkesh Podcast, 6 March 2026. The trial count, the inquisitors’ letters and her conclusion about censors are in her own words in the episode transcript. ↩
Quoted in Thomas Kent, “Ray Dalio says AI investors think they’re betting on technology but ‘that’s not true.’ Why most stocks may not survive”, Moneywise via Yahoo Finance, 21 March 2026, reporting Dalio’s remarks on the All-In podcast. ↩
For a careful version of the argument, see Emily M. Bender and Alexander Koller, “Climbing towards NLU: On Meaning, Form, and Understanding in the Age of Data”, Proceedings of the 58th Annual Meeting of the Association for Computational Linguistics, 2020, which argues that a system trained only on linguistic form cannot learn meaning. ↩
Jahn K. Hakes and Raymond D. Sauer, “An Economic Evaluation of the Moneyball Hypothesis”, Journal of Economic Perspectives 20, no. 3 (2006), pages 173 to 186. The 2002 records (Oakland 103-59, New York 103-58) and Opening Day payrolls (Oakland $39.7 million, New York $125.9 million) are from Doug Pappas, “Payroll vs. Performance, 2002”, Society for American Baseball Research. ↩
Annie Duke, Quit: The Power of Knowing When to Walk Away (Portfolio, 2022). Her kill criteria are set out in an excerpt, “Mental Models to Help You Cut Your Losses”, Behavioral Scientist, 7 November 2022. ↩

How Long Until Your AI Edge Stops Paying?

Sun, 28 Jun 2026 00:00:00 GMT

The most dangerous AI edge is the one that works. It is real, it is earning money today, and it is commoditising faster than you can build the thing meant to defend it.

Most companies are not even there yet. Nearly every one runs AI somewhere now, and by McKinsey’s 2025 survey almost nine in ten respondents say their organisations use AI, while fewer than four in ten attribute any impact on profit to it.¹ You can read that as a lag, and partly it is: a single quarter’s EBIT is hard to attribute, and some gains really are still coming. But the gap has held too wide for too long to be only timing, and the losing companies run the same models as the winning ones. Same tools, opposite results. The model is not the variable.

The two rates

The variable is a rate. Dario Amodei named the two that matter: two exponentials, one for how fast models improve, one for how fast the economy can absorb them.² The first is the capability rate. It belongs to the field, and you read it off a press release. The second is your absorption rate: how reliably you turn a new capability into a number your CFO or customer would recognise. You measure that one on purpose, because nobody publishes it for you. When capability outruns absorption, you are stockpiling power you cannot use, and a better model becomes the most expensive way to feel productive that money can buy.

Your absorption rate has a ceiling, and the ceiling is a single layer: the thing a capability has to pass through to reach your customer. For most teams it is mundane, the data nobody has cleaned, the one engineer who understands the legacy system, the customer who will not change how they work, the sign-off that takes three weeks. Whoever owns that layer captures the value, because everything the model can do still has to flow through it. That is the good news, and it is where most advice stops: find the scarce layer, own it, win.

Venice owned the layer, then lost it

History has run this to completion once, with the printing press. Gutenberg built the machine and lost it in a lawsuit to his own financier; the fortunes came downstream, a generation later, in Venice. By 1500 the press was everywhere, which made it cheap, and Venice owned what stayed scarce: the merchant capital to finance a print run, the paper, the Mediterranean routes to move the books, and the literate market to buy them. No rival city held that whole stack at that scale, so the money pooled there, one step downstream of the machine everyone was staring at. Owning the scarce layer worked exactly as promised.

Then it stopped working. As presses, paper mills and booksellers spread across Europe the layer Venice owned stopped being scarce, and over the sixteenth century the lead passed to Paris, Lyon and Antwerp until the trade that built Venice was a junior partner in its own business. The scarce layer had been paying rent the whole time, and the rent had a term. It paid while the layer was hard to copy and went quiet once it was not.

Where the money lands now

The same split is running through AI today, and you can watch where the money lands. Microsoft holds the largest AI distribution in enterprise, and it built that lead by running other companies’ models, OpenAI’s and Anthropic’s, through the channel it already owned: Office, Teams, Azure, and the procurement relationship every large firm already had with it. Around 420 million people use Copilot across Microsoft’s products each month, though only a few per cent pay for it, and the strongest models inside it are still OpenAI’s and Anthropic’s.³ The model was rented, the distribution was owned, and the margin followed the distribution.

That distribution is a slow layer because no model can manufacture a procurement relationship or the switching cost of every enterprise’s existing Microsoft contract, the kind of thing that takes years to build and years to leave. Slow is why it is winning.

Jasper shows the other failure. It raised 125 million dollars⁴ as a writing tool built on OpenAI’s models, and when ChatGPT arrived free, its product became something anyone could get for nothing overnight. It survived only by climbing into the layer it had skipped, the workflows and data of enterprise marketing teams. Rent the capability and it commoditises on the vendor’s release schedule.

But owning a layer is not enough either, and this is the part the Venice story should have warned you about. Chegg owned its layer outright: a decade-deep library of step-by-step homework solutions and the student traffic to match, a moat no competitor could rebuild quickly. Then a general model could do the whole thing for free. Venice’s edge thinned over a century; Chegg’s broke in a single day. In May 2023 the company told investors that students were leaving for ChatGPT, the stock fell by half, and from its 2021 peak Chegg has since lost more than ninety-five per cent of its value.⁵

It owned the scarce layer. It owned the wrong one.

The clock decides

Put Venice and Chegg side by side and you see the variable. Same kind of edge, a scarce layer others had to pass through, and the clocks ran a hundredfold apart: Venice’s lasted a century, Chegg’s lasted months. That turns owning a scarce layer from an answer into a question. The rule is an inequality. A scarce layer pays only if its clock is longer than the time it takes you to build on it. Clear that bar and you compound; miss it and you have bought a melting asset at full price. So the target is a layer that is both scarce and slow, and the discipline is to read both before you commit.

FIG.02 · Venice’s layer stayed scarce for a century; Chegg’s, for months. The same kind of edge, a hundredfold apart.

What sets the term? A layer’s clock is short when a general model can absorb it: a clever technique, a prompt chain, a fine-tune, generic data anyone can assemble. It is long when the scarcity rests on something a model cannot manufacture, a regulator’s approval, a physical bottleneck like fabs or power, years of accumulated switching cost, a trust relationship a customer will not casually move. Chegg’s layer was content a model could regenerate, so it had only months. The chips an AI runs on are a physical bottleneck, so their scarcity holds for years.

Even that one is eroding. Nvidia owns roughly four-fifths of the merchant AI-accelerator market⁶ and charges a toll most industries never see, the hardest layer in the stack, yet its largest customers are designing their own silicon to route around it. The gross margin will bend before the share does: a credible in-house alternative lets a big customer negotiate the price down long before it moves enough volume to dent Nvidia’s share. Since this essay asks you to read your own clock, here is mine, on the record. Nvidia’s margin, in the mid-70s today, is the first thing that should crack. I expect it below 70% by 2028. If it still holds in the high-70s by then, the compute layer is more durable than this rule predicts, and you should trust the rest of this less.

The capability rate is the master clock behind them all. When models jump, every layer’s scarcity shortens at once, and it cuts the other way too: the same jump that shortens your clock also speeds your build. The bet survives only when capability erodes your moat slower than it accelerates your payback. Nothing here stays still, so re-price it every time the models move.

The clock can sound like weather, something you forecast and brace for. But you can also wind it. The same properties that make a layer hard for a rival to copy make it hard for a model to absorb, and you can add them on purpose: bind it to a switching cost, to a regulator’s sign-off, to a governed data estate no model can cleanly or legally reproduce. The strongest players read their clock and then lengthen it. Chegg could not, because homework answers have nowhere to hide; a layer with somewhere to hide is one you can defend.

FIG.03 · A scarce layer pays only if its clock outlasts your build. Chegg owned a real moat with a six-month clock and bet an eighteen-month build on it.

Run it on your own layer

So the work is concrete, and it fits on one page. First, name your absorbing layer. Use the doubling test: what, if it doubled tomorrow, would let you use twice as much model, while doubling the model itself bought you nothing more? That is the thing capping you. Name the real one before you spend another dollar on capability.

Second, test whether you own it. The bar is strict. You own a layer only when a new capability cannot reach your customer without passing through something of yours that a rival cannot rebuild in a weekend. A model fine-tuned on your own documents does not pass. A workflow your customer could swap out over a weekend does not pass. Run the test before the market runs it for you, because most teams are standing on a layer they only believe they own.

Third, measure your absorption rate. Count the capabilities you seriously tried this year and the ones that moved a number your CFO or customer would recognise; that ratio is your hit rate. Say you ran nine pilots and two produced a result your CFO actually tracked. Two in nine, and the other seven were the model outrunning your ability to use it. Treat the figure as soft, for two reasons. Try three things and you have an anecdote, so work from a real list. And “moved a number” carries an attribution problem, the same one that makes the headline surveys shaky, so keep the credit you can actually trace and discount the rest. The exact ratio matters less than the read: most of what you tried means you are keeping up, almost none means the model is lapping you. The first honest reading usually stings, because the year went on buying the fast curve while the slow one sat untouched.

Fourth, read both clocks. Estimate how long your layer stays scarce, short if a model can absorb it, long if it is gated by something a model cannot make. Then estimate your payback, how long a build on that layer takes to earn back what it costs. If the clock is shorter than the payback, you are Chegg, standing on a real moat that melts before it pays, and the move is to lengthen that clock if you can and build toward a slower layer if you cannot. If it is longer, you have room, and a low hit rate is an organisational problem: give the capability you already have a single owner and a single metric, and hold it before you buy more.

Run it on a shape you can picture, and let it bite. Take a forty-person logistics company with three years of messy carrier-integration data no rival has cleaned: double the data and the model gets more useful, double the model and nothing changes, so the data is the layer. Nobody rebuilds three years of dirty feeds in a weekend, so they own it, and two of their nine pilots moved a number the CFO tracked. Every test passes; last year the read was room to compound. Then the clock moved under them: a frontier model shipped that parses raw carrier feeds zero-shot, and three years of cleaning collapsed into a prompt. The layer that looked like years of scarcity now had six months, against an eighteen-month build. The bet flipped from compound to melting while the data sat untouched, because the capability rate cut the clock faster than they could build. Re-run the number the moment a model moves.

FIG.04 · The whole diagnostic on one page: name the layer, test ownership, measure your hit rate, read both clocks.

Gutenberg kept the craft. Venice kept the money, until the layer it owned stopped being scarce. Chegg owned its layer right up to the morning it stopped being worth owning. No layer stays slow forever, because the capability rate is coming for all of them. The fortune goes to whoever owns a layer slower than that, and keeps checking whether it still is.

So: how many months of scarcity does your layer have left, and how long is the build you are spending them on?

You can put real numbers on both. The Two-Rate Diagnostic runs the read in your browser: name your layer, and it returns your absorption rate, the layer’s half-life, and the date to start building the next one.

The clocks keep moving, so any read has a short shelf life. The instruments and essays here keep tracking them, sourced and dated, as the signals move. Subscribe to stay current.

McKinsey, The State of AI in 2025 (November 2025): 88% of respondents say their organisations regularly use AI in at least one business function, while only 39% attribute any level of EBIT impact to AI. Archived copy: https://web.archive.org/web/20251210113619/https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai ↩
Dario Amodei, in conversation with Dwarkesh Patel, describes two exponentials: one for the capability of the models, and a slower downstream one for the economy diffusing them. https://www.dwarkesh.com/p/dario-amodei-2 ↩
Microsoft reports roughly 420 million monthly active Copilot users across its products; paid Microsoft 365 Copilot seats had reached about 20 million against some 450 million commercial users, around 4 to 5%. TechCrunch, April 2026. https://techcrunch.com/2026/04/29/microsoft-says-it-has-over-20m-paid-copilot-users-and-they-really-are-using-it/ ↩
Jasper announced a $125 million Series A in October 2022. SiliconANGLE. https://siliconangle.com/2022/10/18/jasper-raises-125m-series-funding-ai-powered-content-creation-smarts/ ↩
Chegg shares fell about 48% on 2 May 2023 after it warned that students were leaving for ChatGPT; from its February 2021 peak of $113.51 the stock is down roughly 99%. Fortune. https://fortune.com/2023/05/02/chegg-shares-tumble-students-fleeing-chatgpt-a-i/ ↩
NVIDIA’s first-quarter fiscal 2027 results, reported 20 May 2026, show GAAP and non-GAAP gross margin of 74.9% and 75.0%. Its share of the merchant AI-accelerator market is widely estimated near four-fifths, expected to ease toward 75% as customers’ own silicon scales. https://nvidianews.nvidia.com/news/nvidia-announces-financial-results-for-first-quarter-fiscal-2027 ↩

The Cheaper Fix You Keep Skipping

Tue, 16 Jun 2026 00:00:00 GMT

A founder sits across from a prospect and names the real price. Not the discounted one. The number the work is worth. Then the prospect goes quiet.

The silence runs three seconds. Four. The founder fills it. “But we could probably do something on the first month.” The prospect had not said a word. The discount came from the founder’s own nervous system, which could not sit inside four seconds of a stranger’s silence.¹

That founder did not lack pricing knowledge. They knew the number. They had said it out loud. What broke was the half-second between knowing the price and holding it, and no pricing course on earth fixes that half-second.² The fix is usually free. You will reach past it anyway, and the reason is not one you will enjoy admitting.

The same error, room after room

Watch a struggling trader and you see the same break. Kristjan Kullamagi, who turned a small account into a large one, describes swing trading as a low-effort affair: you wait, mostly, and trade only when a setup appears.³ The edge is not in finding setups; any competent trader can spot a pattern on a chart. It is in not trading on the days when no setup exists, in sitting on both hands through the dead hours. The losing trader rarely lacks analysis. He adds a fourth screen, a ninth indicator, a more elaborate model, and each addition hands him one more reason to act on a day he should have stayed out.

Attention works the same way. The clinical psychologist Russell Barkley spent decades arguing that attention deficit disorder is misnamed: it is a disorder of self-regulation and executive function, the steering rather than the supply.⁴

In Barkley’s account, what fails in ADHD is the act of pointing attention at a goal and holding it there. Treat that as a shortage of effort and you reach for more trying, which he says does not work: nagging someone to try harder leaves the steering where it was. The treatments he backs work on the steering itself: medication, which he says may be a predominant treatment approach, and cues and rewards built into the place where the work happens.⁵

Now watch a machine

This is not a quirk of human psychology. The same structure shows up the moment you build systems that act, which is why it has arrived at the centre of how AI gets engineered.

Andrej Karpathy, who helped build some of the field’s foundational systems, wrote in his review of 2025 that Cursor had revealed a new layer of app around the model, one that orchestrates many model calls strung into ever more complex graphs. He also wrote that he does not think the industry has realised anywhere near 10 percent of what current models can already do.⁶ An agent that produces garbage often does not need a smarter model. It needs a better harness, a step that verifies before it acts, a role that cannot run unconstrained, a memory that survives the task.

Software is where you can run the experiment the human cases only imply. Hold the harness fixed, swap in the stronger model, and the output often fails in the same place as before, faster now and with more confidence. I have argued elsewhere that the most powerful tools reward the most boring strategies; this is the machinery underneath that claim. Capability poured into a structure that cannot aim it does not buy better answers. It buys the same error, upgraded.

Why the wrong diagnosis wins

So why is the reach always for more? When something stalls, the mind reaches for one word, and the word is more. Not enough analysis, not enough focus, not enough model. The reach feels like diligence, and it lands almost every time on the layer that was already full. Adding to a full layer does worse than waste money. It feeds the malfunction: more setups multiply the overtrading, and a bigger model amplifies the broken harness. The cure and the disease point the same way.

This is the asymmetry worth naming. The fix for aim is almost always cheaper than the fix for capacity, and more effective. Barkley’s non-drug fix is structural: routines, cues, a redesigned environment. The trader’s fix is a one-line rule: no setup, no trade. The agent builder’s fix is a step that checks the work before the agent acts, an architecture decision rather than a compute purchase. The founder’s fix is learning to breathe through four seconds of silence. None of it can be bought.

The cost the asymmetry hides

The regulation fix is cheaper and works better, and still almost nobody buys it. Two reasons, and both are about how the fix feels rather than what it costs.

The expensive fix feels like progress. You bought a tool. You enrolled in the programme. You upgraded the model. There is a receipt, a thing you did, a before and an after to point at. Sitting on your hands through a boring trading day produces no receipt. Redesigning a harness deletes work instead of adding it. The cheap fix is invisible, and people cannot easily credit themselves for invisible work.

The second reason cuts deeper. The cheap fix demands an admission the expensive one lets you dodge. To fix the aim, you have to accept that you already held what you needed and were using it wrong.

The trader has to own that the losses came from his own itch to act, not the market’s complexity. The founder has to own that the discount came from his own flinch, not the client’s resistance.

So money and effort flow, reliably, to the layer that was never the problem. Even where the market has noticed the cheap fix, it stays underpriced, because it asks the buyer for something he would rather not give.

Buying capability shields the part of the ego the honest fix bruises. You get to keep believing the problem was out there.

When the deficit is real

None of this means deficits are imaginary. Sometimes the capability is the thing that is missing. The junior developer who has never written a test needs to learn how. The trader with iron discipline and no edge needs a better strategy; patience will not save him. The agent on a weak model sometimes does need the stronger one.

The tell is sequence. A real deficit only shows itself after the aim is true and the work fails anyway: you have sat on your hands for a month and still lose, you have split the agent into maker and checker and it is still wrong, your technique was clean and your composure held and the call still died. Until then you cannot know whether capability was the problem, because it was never aimed straight long enough to find out. That cuts both ways, which is the point. Give the aim a fair run and judge it honestly: if nothing improves, the diagnosis was wrong and the deficit was real. A diagnosis that cannot be wrong is not worth running.

So let your default tilt against the deficit. Deficits happen. But the deficit fix is the only one anyone is selling you, so your instinct already leans toward the price tag. Correct for the lean.

The diagnostic you can run this week

Before you add anything to a system that is underperforming, run one question. Is this a deficit, or a failure of aim?

The question takes a concrete shape in every domain. In trading: do I lack a setup, or the discipline to wait for one? In building with agents: does the model lack capability, or does the harness lack structure? In a hard conversation: do I lack the right words, or can I not hold my state while I say them? In your own work: do I lack the hours, or am I spending the hours I have on the wrong things?

The test for the week is small. The next time you reach to add something, a tool, a model, a tactic, an hour, stop and name what you already have that you are aiming wrong. Fix the aim first. Buy the capability only once the aim was true and the work still failed. Most of the time you will not get that far, because most of the time the aim was the whole problem.

Capability is the fix that gets sold, because it is the fix that can be sold. The one that works is sitting in the layer you have been adding to without once pointing it.

When you run the question on something you are stuck on right now, which is it: a deficit, or an aim you have been refusing to admit?

The pricing-and-composure framing draws on Alex Hormozi and Daniel Priestley on offers and pricing (The Diary of a CEO, 2025): entrepreneurs discount reflexively, driven by an inability to hold composure through a prospect’s silence rather than by any gap in pricing theory. The opening scene is illustrative, not a transcript. https://podcasts.apple.com/us/podcast/money-making-experts-this-3-step-offer-formula-makes/id1291423644?i=1000721000330 ↩
Chase Hughes’s ACSS hierarchy (Authority, Comfort, Social skills, Skills) places most communication failure upstream of technique, in state regulation under social pressure: a person with strong technique and poor composure collapses on contact. https://podcasts.apple.com/us/podcast/the-leading-body-language-behaviour-expert/id1291423644?i=1000681715542 ↩
Kristjan Kullamagi (Qullamaggie) on Chat With Traders, episode 212 (“Breakouts, Home Runs & Exponential Returns”): he frames swing trading as a low-effort affair of waiting, trading only when a valid setup appears rather than because the market is open, so the edge is in regulating the impulse to act rather than in generating more signals. https://www.youtube.com/watch?v=K0F73Sq90j0 ↩
Russell A. Barkley, “The Important Role of Executive Functioning and Self-Regulation in ADHD,” reconceptualises ADHD as a disorder of executive function and self-regulation, which he argues underlies the familiar symptoms of inattention and impulsivity. https://www.russellbarkley.org/factsheets/ADHD_EF_and_SR.pdf ↩
Barkley, same factsheet: “The solution to this problem is not to nag those with EF difficulties to simply try harder”; he recommends cues, prompts and external rewards placed at the point of performance instead. He also says medication, stimulant or non-stimulant, “may be a predominant treatment approach”, citing clinical improvement with stimulants in as many as 75 to 92 percent of people with ADHD. https://www.russellbarkley.org/factsheets/ADHD_EF_and_SR.pdf ↩
Andrej Karpathy, “2025 LLM Year in Review” (19 December 2025). He writes that LLM apps like Cursor “orchestrate multiple LLM calls under the hood strung into increasingly more complex DAGs”, and, of LLMs themselves, that “I don’t think the industry has realized anywhere near 10% of their potential even at present capability.” In the same post he expects rapid progress and says “there is a lot of work to be done”, so the claim here is limited to how much current models leave unused. https://karpathy.bearblog.dev/year-in-review-2025/ ↩

Your Tools Got Powerful. Get Boring.

Mon, 01 Jun 2026 00:00:00 GMT

The most powerful tools in history reward the most boring strategies. The gap widens every time they improve.

The bored trader beats the machine

On one side of the trade sits a market-making engine that represents the genuine state of the art: Hawkes processes modelling order arrivals, Kyle’s lambda pricing the impact of each fill, Avellaneda-Stoikov inventory control balancing the book in real time. Years of mathematics, running on hardware that did not exist a decade ago.

On the other side is a momentum trader whose entire system is price, volume, and three moving averages. He sits in cash most of the year doing nothing, waiting for a setup he could describe to you in a sentence. His stack is deliberately primitive. His edge is patience and the discipline to follow his own rules when they are boring and to sit out when they are silent.

Over a full market cycle, the boring one is more likely to still be standing.

This is uncomfortable, because it runs against an intuition almost everyone shares: better tools should let you run better, more sophisticated strategies. More compute, more data, more powerful models, therefore more elaborate approaches and better results. It feels obviously true. It is the logic behind most of what gets built, bought, and bragged about.

It is also, across domain after domain, wrong. And the interesting part is the shape of the curve.

The gap widens as the tools get stronger

Here is the pattern the most successful practitioners keep landing on, whether they are trading, building software, learning, or shipping products. Powerful tools do not pay off when you point them at more complex strategies. They pay off when you point them at simple strategies and execute those faster, more consistently, and with less drift than anyone else.

More power applied to a simple strategy compounds. The same power applied to a complex one mostly buys you more ways to be wrong.

Sit with the second half of that, because it is the part people miss. A sophisticated strategy is not free. Every additional layer needs to be specified, verified, maintained, and monitored, and all of that consumes exactly the capacity the powerful tool was supposed to give back. A simple strategy spends its new power on doing the simple thing relentlessly well. A complex one spends its new power feeding its own machinery.

The reason this matters more now than it ever has is that the tools have never been this strong. When your instruments are weak, the gap between the simple-and-disciplined path and the complex-and-fragile path is small, because nobody can do much of either. As the instruments get more powerful, both paths open up, and the distance between them widens. The most capable tools in history make disciplined simplicity more effective than ever, and they also make unmanageable complexity easier to build than ever. We are living through the largest gap between those two paths that has ever existed, and most people are sprinting down the wrong one with a faster engine.

Same start, same power, opposite directions. The stronger the tools, the wider the distance grows.

What complexity quietly costs

The bill for sophistication does not arrive when you build it. It arrives later, in instalments, and it is always larger than it looked.

The first instalment is verification. A simple system you can hold in your head and check. A complex one you cannot, so you build monitoring to watch it, and the monitoring becomes its own system that can drift and mislead. Every layer you add is a layer you now have to confirm is still doing what you think it does, and the confirming never ends.

The second instalment is the day it breaks. A simple strategy fails legibly: you can see which rule was wrong and fix it. A sophisticated one fails in the seams between its parts, at the worst possible moment, in a way no single person fully understands. The elaborate model that printed money for two years becomes, in the drawdown, a black box nobody can debug while it is bleeding. Complexity does not only add capability. It adds failure modes that stay hidden until the system is under stress, which is the exact moment you have no spare capacity to handle them.

The deepest cost is fragility to your own success. A strategy with many parameters has many surfaces the world can destabilise once it starts reacting to you. The more elaborate the machine, the more places reality can reach in and pull a lever you forgot you had wired up. Simple, constrained systems survive contact with the world because there is less of them to break.

Sophistication is a loan against your future attention, taken out at a rate you cannot see until the system is under stress and the whole balance comes due at once.

Verification that never ends, failure in the seams, fragility to your own success. The bill always arrives, and later than you think.

Why we reach for sophistication anyway

If simplicity wins, why does almost everyone instinctively add complexity? Smart, capable people do it constantly, because the incentives reward it.

Every incentive in the room rewards the complexity you can show and punishes the discipline you cannot.

Sophistication is visible. A complex model, an elaborate architecture, a clever framework can be shown to a boss, a client, an investor, a peer. Discipline cannot be shown. Sitting in cash for three months, deleting half your code, pausing before you speak, refusing to ship the extra feature: none of it photographs well. The market pays for what it can see, and it can see complexity far more easily than it can see restraint.

Complexity also feels like work. Building an intricate system produces the sensation of progress all day long, even when the effort is going into the layer with the least leverage. Doing the boring, correct thing and then waiting produces the sensation of doing nothing, which the nervous system reads as failure. The feeling and the result point in opposite directions, and the feeling usually wins.

And an entire economy is built on convincing you the work is harder than it is. Every tool vendor, every course, every consultancy has a structural interest in making its domain look more complex than it needs to be, because simplicity is terrible for business. The people who write about a field emphasise its hardest parts, which is what makes them experts, rather than its simplest parts, which is what produces the results. The perceived difficulty of almost everything is inflated, and the inflation is nobody’s accident.

What the constrained version keeps proving

The clearest place to watch this play out right now is in how people use AI, because the tool is so powerful that the trap is stark.

The most effective way to get good work out of a frontier model is to take capability away from it. The prompts that consistently produce strong code are the ones that forbid things: no verbose comments, no scattered logging, small functions only, review your own output before returning it. The best debugging prompts are the most constrained ones: strict ordered steps, and a hard rule to verify before changing anything. The most powerful model on the planet does better work when you give it fewer options. People reach for AI expecting more power to mean more freedom. What it rewards is more power inside tighter constraints.

The same shape shows up wherever someone is quietly winning with powerful tools. The builders who ship profitable products solo run on deliberately boring technology, the kind a fashionable engineer would be embarrassed by. They ship ugly first versions fast while better-resourced teams are still choosing a framework. The plain name for what those teams are doing is over-engineering, and the powerful tools make it easier than ever. The people who learn fastest take fewer notes, not more. They delay and compress until a page of dense understanding replaces a folder of neat transcription. The creators who grow post less, because the algorithm rewards depth per post and punishes the volume that easy tools make tempting. Different fields, one lesson: the powerful tool is best spent removing steps.

The people quietly winning with the strongest tools are using them to do less, and to do it more reliably than anyone else.

None of these people are anti-technology. They are using the most powerful tools available. They are simply pointing them at the boring fundamentals and refusing the upgrade to a more complicated game.

The test that catches you in the act

The trap is hard to escape by intention alone, because it is driven by feeling, and the feeling does not announce itself as a bias. It announces itself as ambition. So you need a question sharp enough to cut through the feeling in the moment you are reaching for complexity.

When you catch yourself building something more sophisticated, ask: am I adding this because the problem genuinely requires it, or because the simple version feels uncomfortable?

If the honest answer is discomfort, you are in the trap. The simple version feels too easy, too exposed, too much like you are not earning your keep, so you reach for a layer that makes you feel substantial. That layer is where the cost lives.

The operational rule is narrow and worth memorising. Reduce complexity until the system is something you can verify, and not one notch past that. A simple strategy with strict rules and clean checks beats a sophisticated one you cannot fully see into, and the advantage grows the more powerful your tools become. When a strategy has more moving parts than you have the discipline or the data to support, the parts are not power. They are surface area for failure.

So the next time more compute, a better model, or a new tool lands in your hands, notice the instinct to finally build the elaborate thing you have been wanting to build. That instinct is the trap closing. The tool should be powerful. The strategy it serves should be almost embarrassingly simple. And the discipline that holds the two together should be boring enough that nobody, including you, finds it impressive.

That last part is why it works. The edge is boring on purpose, which is exactly why it is still available.

What is the most sophisticated thing in your current setup, and what would happen if you deleted it?

The test on one card, for the next time the pull to complicate hits.

New to The Durability Curve? It is a standing argument about what survives when the tools get powerful and the surface gets cheap. Subscribe for the rest, or start with what survives.

The 90-Day Canopy Audit

Sun, 03 May 2026 00:00:00 GMT

Most roadmap reviews reward completion. The better review asks which completions will survive the next change.

The meeting everyone recognises

You are in the end-of-quarter roadmap review.

The page looks good.

Green ticks everywhere. A few screenshots. A small chart moving up and to the right. Someone says the team shipped a lot despite the chaos. Everyone half-nods because the list is long enough to feel true.

That is the trap.

This is the moment most teams stop thinking.

Not because they are lazy. Because completion is comforting. A finished roadmap gives everyone a clean story: the team worked hard, the product improved, the quarter counted.

But there is a more useful question hiding underneath the shipped list:

How much of this work will still matter after the next large change?

That is the move: stop treating the shipped list as proof, and test it against the next environment.

That is the 90-day canopy audit.

For the example below, imagine a team reviewing the last 90 days of work on an AI support product. It is a composite, not a case study. The point is the pattern.

The team shipped a new summary flow. It tuned retrieval settings. It ran a model comparison. It cleaned up prompt templates. It improved the demo. It moved from one agent framework to another. It added a model-picker interface. It lifted an internal benchmark. It also built a small eval set, documented recurring failure modes, added an escalation path for bad answers, and started recording evidence bundles for customer-visible outputs.

Twelve items shipped. Several are visible. The demo is better. The benchmark moved. The roadmap has enough completed work to make the team feel like the quarter was not wasted.

But shipped is not the same as durable.

The Substrate Map gives the review a different job.

The question is not:

What did we ship?

The question is:

What did we ship that the next change cannot easily displace?

Name the disturbance

The audit only works after you name a plausible change.

Not “AI gets better.”

Something concrete:

A cheaper model ships next quarter with support summaries that are almost as good as ours.

That one sentence changes the roadmap review.

Now every shipped item has to answer a harder question: if that model lands, does this work still have a job?

Some of it does.

Some of it does not.

The uncomfortable part is that the work people remember from the review is often the easiest to displace.

The polished demo.

The model switcher.

The benchmark lift.

The prompt library.

None of these are automatically bad. They may be needed. They may help the customer this month. They may get the product through the next sales call.

But if the surrounding environment changes, they are the first items you have to renegotiate.

The 12-item audit

Now tag the composite roadmap honestly.

The canopy side is crowded: prompt templates for the current model, RAG chunk-size tuning, a model comparison leaderboard, demo polish for the sales flow, a model-picker interface, migration to a new agent framework, benchmark tuning against the current frontier, and cleanup of the summary prompt library.

The substrate column is shorter: a golden eval set built from real failed conversations, a pinned evaluation contract that survives a model swap, a customer escalation path when the answer is wrong, and evidence bundles for customer-visible outputs.

That is eight canopy items and four substrate items.

The team shipped twelve things.

Two thirds of the quarter was canopy.

The point is not to worship the ratio. The point is to use it as a regime signal.

If the quarter is 70%+ canopy, the team is probably overfitted to the current regime. It may still be moving fast, but a model release, pricing change, customer workflow shift, or competitor feature can reset too much of the work.

If the quarter is roughly 50/50, that is normal. Most real work needs visible canopy and durable substrate. The question is whether the substrate side is becoming more explicit over time.

If the quarter is 70%+ substrate, protect it. That is usually the less glamorous work competitors do not copy from a screenshot: eval discipline, traceability, workflow depth, recovery paths, failure memory, and proprietary signal.

The trend matters more than the single number.

A canopy-heavy quarter before a launch might be fine. Three canopy-heavy quarters while the team says it is building a moat is a different diagnosis.

That does not mean two thirds of the work was stupid.

This is where the audit has to be honest or it becomes another management slogan. Canopy matters. Customers experience the canopy. Demos happen in the canopy. Interfaces, summaries, model choices, and prompt work can all be useful.

The problem is not that canopy exists.

The problem is believing a canopy-heavy quarter created durable progress.

The audit turns a shipped list into an allocation decision.

The boundary argument is the point

The most valuable part of the audit is not the final ratio.

It is the argument at the boundary.

Someone will say the model comparison leaderboard is substrate because it helps the team choose models faster. Maybe. But if the leaderboard only measures the current task mix, current prompts, current pricing, current model set, and current evaluator, it is still mostly canopy. The next release can reset the comparison.

Someone will say the agent-framework migration is substrate because the architecture is cleaner. Maybe. But if another framework becomes standard next quarter, or the model provider ships the capability directly, the migration may have been canopy with better engineering taste.

Someone will say the golden eval set is canopy because it was built for the current product. Probably not. If the examples came from real failed conversations, if they preserve the customer context, if they can be replayed against the next model, then the eval set keeps doing work after the model changes.

That is the boundary rule:

If the team cannot agree which column an item belongs in, tag it as canopy until the substrate is made explicit.

Disagreement is not noise. It is the instrument finding the hidden work.

In a real meeting, this is where the value appears.

The audit makes vague strategy concrete enough to argue with. Instead of someone saying, “This feels important,” they have to say what survives. Instead of someone saying, “The architecture is cleaner,” they have to say what the cleaner architecture keeps doing if the model, workflow, buyer, or cost curve changes.

That is why the tool is useful even when the ratio is imperfect.

It forces the team to surface the reason.

The decision changes

Before the audit, the team wants to keep going.

More prompt polish. Better model picker. Another benchmark pass. More demo flow. A cleaner interface for switching models.

After the audit, the next two weeks look different.

The team pauses the model-picker interface. It stops treating prompt-library cleanup as strategic progress. It keeps some UI work because customers need the product to be usable, but it no longer lets visible polish dominate the next planning cycle.

Instead, the team moves time into four things: expanding the eval set from 40 failed conversations to 120, writing the evaluation contract down so the score means the same thing after a model swap, attaching every customer-visible answer to a small evidence bundle, and defining the escalation path for answers with high reversibility cost.

The roadmap did not get slower.

It got harder to fake.

That is the difference between a shipping review and a substrate review. A shipping review asks whether work happened. A substrate review asks whether the work still matters after the world moves.

The important thing is that the audit changes a decision quickly.

If it only produces a prettier post-mortem, it failed.

The two-week reallocation is the point. You do not need a reorg. You do not need a new strategy process. You need one planning cycle where the next slice of work moves toward substrate before the old pattern hardens.

Run it on your own work

Open the last 90 days of your roadmap.

Do not start with the whole company. Start with one product line, one team, one portfolio, or one major bet.

You can do the first version in 20 minutes.

Name the most likely large change in the next 18 months. List the work shipped in the last 90 days. Tag each item as canopy or substrate. If the boundary is unclear, tag it as canopy until the substrate is explicit. Compute the ratio. Then change one allocation decision for the next two weeks.

Three prompts make the exercise less abstract:

If our current model advantage disappeared, which items would still matter?

If our main customer workflow changed, which items would still matter?

If a competitor copied the visible feature, which items would still matter?

The last step matters.

If the audit does not change the next allocation, it was only vocabulary.

The goal is not to call more things substrate.

The goal is to find the work that will still have a job when the environment changes, then protect it before the next quarter turns it invisible again.

A useful warning

Do not use this audit to make the team feel bad for shipping visible work.

That is the lazy version.

Use it to stop confusing visible work with compounding work.

A good quarter can contain plenty of canopy. The user still needs the product to look and feel right. The market still responds to surfaces. The interface still matters.

But if every quarter is dominated by work that has to be redone when the environment changes, you are not building durability.

You are renting momentum.

That is the shift: stop asking whether the quarter was busy. Ask how much of it still has a job after the world moves.

The free Substrate Map is here:

Run it before the next planning meeting.
Not because every roadmap should become substrate.
Because every roadmap should know how much of itself is not.

If you run the audit, which shipped item was hardest to classify? That boundary argument is usually where the real strategy work begins.

More free tools like this. Subscribe to get the next durability-lens resource the day it ships.

Start Here: What Survives When The Surface Changes?

Sat, 02 May 2026 00:00:00 GMT

Start here if AI makes you feel behind.

This publication runs on one question:

What survives when the surface changes?

Most AI commentary moves at the speed of the surface. Releases, benchmark jumps, tool launches, prompt tricks, funding rounds, arguments about who is suddenly ahead. Some of it matters. Track only that, and every release feels like a reset, every demo feels like a threat, and you redraw your map of the world every few weeks.

That churn is the surface. What follows is the lens I use to work out which parts of it will still matter, and the instruments that make it something you can run rather than something you agree with.

The Lens

Every system has a canopy and a substrate.

The canopy is the visible part. The demo, the interface, the prompt, the benchmark score, the dashboard, the model everyone is discussing this week.

The substrate is what still has a job when the canopy gets repriced. The data pipeline, the evaluation contract, the workflow it plugs into, the distribution channel, the trust, the failure memory, the recovery path, the decision rule.

Visibility and durability are separate properties. Treating them as one property is the expensive mistake, and it is the one I watch people make most often.

That is half the lens. The second half is the one that costs money when it gets left out.

Durable is not sufficient, because scarcity moves. When a layer commoditises, value migrates to whichever adjacent layer now resists commoditisation hardest. Usually that is the coordinating, verifying and selecting layer above it. When the binding scarcity is physical or institutional, compute, power, fabrication, regulatory access, it moves down instead. The bottleneck never disappears. It goes where resistance is highest, and assuming that is always upward, or always deeper, is how people end up owning something perfectly durable that nothing needs any more. A durable architecture the bottleneck has already moved away from is a melting ice cube.

So that one question has two halves. What kind of thing survives a repricing, and where is the scarcity heading right now. What you want to own is the durable thing at the moment the bottleneck is moving toward it.

The Test

Start by writing down which parts of your system you are calling substrate. Do this first, before you know what is coming, and be specific enough that somebody could later tell you that you were wrong.

The order is the whole test. Name the disturbance first and you will find yourself labelling whatever survived as substrate and whatever broke as canopy. Nothing stops you, the score comes out flattering, and it can never tell you that you got it wrong. A test you cannot fail is not measuring anything.

With your list committed, name the disturbance, precisely enough that somebody could disagree with you. An open-source model matches your benchmark and runs on commodity hardware. Your main channel stops favouring your format. The layer your product sits on ships your feature as a primitive.

Then count how much of what you built still has a job. That surviving fraction is the honest measure of durability, and it is the inverse of what I call your displacement rate. Something can look weak today and be very hard to displace. Something can look dominant and be a canopy bet waiting for the next shift to expose it.

Run one on your own work

The fastest way into any of this is to point it at something you own. The instruments are free and live right now, all of them on the instrument rack. Each runs in your browser and needs no account, and nothing you type leaves the page.

If you only open one, open the first.

The Potemkin Map. Score your AI loops on two questions. Could the success signal be faked, and is the first real failure terminal. It plots what you enter on those two axes and tells you which corner you cannot iterate your way out of.

The Marathon Calculator. Per-step reliability compounds over a long agent run. See the finish-rate gap, and the expected token cost of one finished task once the failed runs are priced in.

The Two-Rate Diagnostic. Name the AI layer your advantage runs through, then set your absorption rate against our dated read of that layer’s clock, and see how long the window stays open.

The Structure Spotter. Name the mathematical shape under a load-bearing assumption, such as a trade-off that is really a filter, or an independence that only holds on calm days. Name the shape and you inherit the test the field that met it first already built. It offers a candidate diagnosis, not a verdict.

The Multi-Agent Decision. Four questions per task, and a ranking of which jobs on your list actually earn a fleet. Most come back as one strong agent with an engineering envelope around it.

The Metric Validity Audit. Pick the number you trust most. Get a read on how that kind of number lies, and what to do about it.

The Shape Test. Is your growth curve compounding or just accumulating? Drag through your own series and watch the verdict arrive, later than you expect.

Ten minutes with any one of them gives you something about your own system that you did not have this morning.

Start with the problem you have

You do not have to read everything. Start from the problem you actually have.

I want the shortest version of the whole idea.

Read The Forest Floor Is The Product, then Your Tools Got Powerful. Get Boring.

The first is the cleanest statement of substrate against canopy. The second is what it looks like when you act on it.

I build with AI agents and I need them to be reliable.

Start with How Reliable Is Your AI Agent?, which is the piece the rest of this publication keeps returning to. Then Never Let Claude Code Tell You It’s Done for a walkthrough you can follow with your own hands, and The Seven-Layer Agent Audit, which hands you the seven questions and a scorecard to run them with.

That last one contains the clearest example of this lens costing me something. I wrote a script to run the seven questions automatically, then threw it away, because a script reads your file names rather than your setup and returns a confident verdict on any stack it does not recognise. The automation was canopy. The questions were substrate. I had built the wrong one first.

I am deciding what to build on, or what to standardise across a team.

Read Skills Are Package Management for Your AI.

Treat your skills, prompts and tools as dependencies with versions, owners and revocation, or accept that nobody can tell you what your agent is currently allowed to do.

I need to know whether my evaluation is telling me the truth.

Read Most Verification Is Just Bigger Classification, then Your Research Agent Cites Sources It Never Read.

If you want the sharpest version, Your AI Looks Best Where You Can Check It Least and its companion Potemkin Map deal with the loops where the evidence is written by the thing being evaluated.

I am thinking about my own job.

Read The Safe Parts of Your Job Are the First to Go, then The Difficulty You’re Escaping Was Making You.

I want the framework underneath all of it.

Read The Five Laws of Durable Systems.

Canopy and substrate is the entry point. The five laws are what the analysis actually runs on, including the one that says some of the hard parts of your system are waste and some are the mechanism producing the value, and that telling those apart is most of the job. A corollary that falls out of three of the five says any metric you optimise against degrades as a measure of the thing you cared about.

I also write about markets and capital allocation through the same lens. That is a genuine but secondary lane here. The main work is AI systems, agents, and the reliability of both.

What to expect

One structural lens at a time, written so you can use it. Sometimes that is an essay. Sometimes a walkthrough you follow with your own hands. Sometimes an instrument like the seven above.

The aim is that the next time something looks impressive, you have a sharper set of questions ready.

What is the substrate here?
What happens to it when the ground moves?
Is the scarcity moving toward this, or away from it?

If You Only Remember One Thing

Ask what still has a job after the surface changes.

Then ask whether the scarcity is moving toward it, or away.

The Displacement Rate Audit

Fri, 01 May 2026 00:00:00 GMT

Most plans are scored against the world they were made in.

That is the problem.

The useful question is not whether the product, thesis, architecture, position, or career bet works today. The useful question is how much of it still has a job when the surroundings change.

The Displacement Rate Audit is a free five-minute tool for asking that question before reality asks it for you.

Run it on one thing you are currently defending:

a product line;
an investment thesis;
a technical architecture;
a business model;
a career bet;
a major project your team is still defending.

Then name the most likely large change in the next eighteen months. The audit only works if the change is specific enough to argue with.

Not “AI gets better.”

Something concrete:

An open-source model matches your benchmark and runs on commodity hardware.

Your sector takes thirty percent multiple compression.

Your main distribution channel stops favouring your format.

The buyer no longer needs the workflow your product was built around.

Now score what survives.

The audit gives you a 0-5 displacement score. Zero means nothing survives; the work belonged to the old version of reality. Five means the change was already accounted for in the original design.

The score matters less than the forcing function:

If you cannot name the specific components, contracts, positions, relationships, or capabilities that still have a job after the change, your real score is lower than the one you wrote.

This is why the tool is useful across domains. It does not ask whether something is impressive. It asks whether it is durable under a named disturbance.

The output is deliberately small: one named change, one score, and one list of the parts that survive. That is enough to make the next decision harder to fake.

Use it before adding features. Use it before sizing a position. Use it before doubling down on a technical architecture. Use it when a strategy still sounds good but you can feel the surroundings moving.

Download.

The Displacement Rate Audit

121KB ∙ PDF file

Download

More free tools like this. Subscribe to get the next durability-lens resource the day it ships.

The Displacement Rate Audit is a companion to The Forest Floor Is the Product, the article that develops the substrate-vs-canopy lens across ecosystems, software, knowledge work, and capital allocation.

What is one thing you are building that would score lower than you want if the next big change arrived tomorrow?

The Substrate Map

Fri, 01 May 2026 00:00:00 GMT

Most teams can tell you what they shipped.

Fewer can tell you what will still matter after the next large change.

That is the gap the Substrate Map is built for.

It is a free one-page taxonomy for separating canopy from substrate in your own work. The canopy is the visible layer: prompts, model choices, demo polish, current benchmark scores, frameworks, UI surfaces, launch artefacts. The substrate is the part that keeps doing work when the surface gets repriced: data-quality discipline, eval contracts, workflow integration, trust packaging, domain-specific failure memory, and the proprietary signal the next model release does not have.

The tool gives you a 10-minute exercise:

Open the last 90 days of engineering tickets, product launches, roadmap decisions, or investment decisions.
Tag each item as substrate or canopy.
Compute the ratio.

The number is blunt on purpose.

If the last 90 days were mostly canopy, the next release can reset most of what you built. If the split is 50/50, you are probably normal but not especially durable. If the work is mostly substrate, protect it. That is the work compounding underneath the visible output.

The most useful part is the boundary rule:

If your team cannot agree which column an item belongs in, tag it as canopy.

Disagreement at the boundary means the substrate work has not been made explicit yet.

That makes the map useful before a planning meeting. Instead of arguing about whether a roadmap “feels strategic”, you can ask which work would still matter if the model, market, channel, or buyer changed. The conversation gets harder to fake because each item has to be placed in a column.

The PDF is deliberately simple: one map, one exercise, one ratio. It is not a strategy deck. It is the first instrument you run when the team is shipping a lot but cannot say what is compounding.

Use it on a roadmap. Use it on a product backlog. Use it on a portfolio. Use it before a planning cycle where everyone is about to argue from vibes.

Download.

The Substrate Map

105KB ∙ PDF file

Download

More free tools like this. Subscribe to get the next durability-lens resource the day it ships.

The Substrate Map is a companion to The Forest Floor Is the Product, the essay that develops the substrate-vs-canopy lens across ecosystems, software, knowledge work, and capital allocation.

What percentage of your last 90 days was substrate?

The Forest Floor Is The Product

Thu, 23 Apr 2026 00:00:00 GMT

On the west coast of Vancouver Island there is a Sitka spruce called the Carmanah Giant. It is around 96 metres tall and several centuries old.1 Stand at its base and you think you are looking at a tree. You are not. You are looking at the visible tip of a system that has been quietly assembling itself for far longer than any single tree has been standing in it.

Much of that system sits below the soil line.

A network of fungal threads, the mycorrhizal network, connecting the old trees through filaments thinner than a human hair.2 A soil profile built up from fallen needles, fungal bodies, and the slow decomposition of every tree that came before. A bank of seeds dormant in the soil, waiting decades for the next storm to open a hole in the canopy above.

None of that arrived at once. It was laid down in order, one layer at a time. Pioneer species fixed nitrogen in soil that would not otherwise hold a tree. Shade-tolerant species established in their cover. Each generation made the next one possible.

The spruce did not grow out of the soil. The spruce and the soil grew each other. Slowly. Over a timescale that makes almost everything we ship in 2026 look like weather.

I have thought about that tree a lot this year.

Right now the dominant advice is simple: ship faster, the next model release will save you, and anyone not on the treadmill will get left behind. There is some truth in that, the way there is some truth in every panic. But forests give you the case that breaks the rule. Every old-growth ecosystem on the planet exists because no one optimised it for velocity. The annual growth rate of a 400-year-old tree is laughable. What makes it last is not the rate at which it grows. It is the rate at which it does not get displaced.

That distinction is going to decide who is still standing in five years.

Velocity Was Always a Trick of the Light

Most strategy advice in 2026 says some version of the same thing: ship faster, automate the boring parts, parallelise the rest, let velocity carry you. It sounds right because it measures the part that is easy to count. Output per week. Posts per month. Features per quarter.

The forest gives you the other half no one is measuring.

A 400-year-old Sitka spruce adds a thin ring of wood in a good year. By the standards of any ecosystem that prizes growth-rate, this is humiliating. Bamboo is among the fastest-growing plants on Earth. Pioneer fireweed colonises a burn site in a single season. By any velocity metric, the spruce loses to almost everything.

And yet bamboo groves get cleared for pasture. Fireweed dies back when the canopy closes. The spruce is still standing.

Forests do not optimise for speed. They optimise for the conditions under which a 400-year-old tree can stand.

This is the distinction velocity strategies miss. Growth-rate is one variable. Displacement-rate is the other. A piece of work shipped in January 2024 that is still doing useful work in January 2027 has beaten a piece shipped weekly that was obsolete by Friday. The slow tree wins not by growing faster but by occupying a position the fast strategies cannot reach.

You can check this in your own work in five minutes. Pick the three things you shipped this month. Then pick the three you shipped this quarter last year. Ask which set is still doing work for you. The honest answer tends to be uncomfortable. The recent stuff is louder. The older stuff is quieter and doing more.

The harder admission is that the slow part may be the load-bearing part. If you automate the patience out of the process, or rush past the bit that needs time to set, you may also remove the thing that was making the work durable. Soil built up over a century cannot be shortcut with fertiliser. The shortcut gives you a different kind of forest, and that forest gets cleared.

Two clocks are running, not one. The first measures how much you can produce. The second measures how long what you produce keeps doing useful work after you ship it. The first clock speeds up every time a new model ships. The second one barely notices model releases. It only moves when something you made was rooted in enough of you that the next release cannot just regenerate it. Sprint on the first clock and ignore the second, and you can look extraordinarily productive for a year. Then look back and find that almost nothing you shipped is still doing work for you.

The move is simple. Stop measuring your work by how often you ship. Start measuring it by how long what you shipped keeps earning its place a month, a quarter, a year later. The first metric flatters output. The second tells you whether you are building anything.

The Mycorrhizal Network Is the Product

Walk into an old-growth forest and ask a forester what the product of the system is. They will not point at the trees.

The trees are the canopy. The product is the soil and the fungal network running through it.

Suzanne Simard’s 1997 paper in Nature showed something that biologists had suspected for decades.3 Birch and Douglas fir seedlings, growing side by side in British Columbia, passed carbon both ways through underground fungal connections, and the fir came out slightly ahead. Trading, measured in the field. The study tracked carbon in seedlings, and a 2023 review judged the field evidence that such networks are widespread, or that they help seedlings, insufficiently supported. Even so, it gave us the picture this essay builds on: a mycorrhizal network linking roots and moving resources between plants that, viewed from above, look like separate individuals.

This is the wood-wide web. Most land plants on Earth form mycorrhizal partnerships, and in this picture mature forests function less as collections of individual trees and more as networked systems with a hidden circulatory layer underneath.4 Christine Webb, in her essay We Have Never Been Individuals, pushes the point further. Once you take the substrate seriously, the category of “individual organism” starts to wobble. The forest is not a population of trees. It is one thing, and the trees are how it shows up at the surface.

The model is the canopy. The substrate is the forest.

Now look at your own work the same way.

The visible output of anyone using AI in their work, the slide, the post, the codebase, the report, looks like the product. It is not. It is the canopy. The product is the substrate underneath it. The judgement that decided what the slide was even for. The taste that picked the example. The relationship with the person it is being sent to. The accumulated context that made the right move obvious in a situation where a stranger would have needed an hour.

Most 2026 advice on AI productivity is canopy advice. Better prompts. Faster generation. More tools. The canopy improves. The substrate gets ignored or, worse, eroded, because the canopy is producing so much output that no one makes time to tend the soil.

This is the failure mode that fire-suppressed forests show. The visible canopy looks healthy. The understory is choked. New growth has nowhere to start. When disturbance finally comes, the whole system collapses at once because nothing was ever built underneath.

The companies and individuals still standing in 2030 will be the ones who figured this out early. The output is the canopy, and the canopy gets replaced. Every six months a new model ships and the slide deck, the post, the codebase get easier for anyone to reproduce. The substrate underneath is what does not get replaced. It is too specific to you, to your domain, to the people who trust you, to the years of context you brought to bear. The next release does not touch any of it. That is the only part actually worth building.

So the move is this. Name the substrate beneath the last three things you shipped. Not the tools you used. Not the workflow you followed. The substrate itself. The hard-won, slow-to-build thing that made the output possible and would not have been there a year ago. If you cannot name it in one clean sentence per project, it is probably not there yet. You are growing canopy on bare rock, and the next storm will take it.

Try this honestly and you find something else. The substrate, once you start naming it, is more interesting than the canopy ever was. It is also where every reader you actually care about lives. The output is what got their attention. The substrate is what makes them stay.

Succession Is a Discipline, Not a Wait

We like to imagine forests grew by simply waiting. Time passed. Trees got bigger. Eventually you had a forest.

That is not how it happens.

A patch of bare ground, whether left by logging, by fire, or by a retreating glacier, does not become a forest at random. It moves through a strict sequence ecologists call succession. The order matters. The tiers cannot be skipped.

Pioneers arrive first. In the Pacific Northwest these are species like red alder, fireweed, and the hardy shrubs that move into any disturbed lot. They are short-lived and fast-growing, and they do one thing the bare soil cannot yet do for itself. Alder fixes nitrogen, which means it pulls nitrogen out of the air and locks it into the soil so other plants can finally use it later.5 Fireweed holds the loose ash and char that fires leave behind. Together the pioneers prepare ground that nothing else could grow on.

Then come the early conifers. Douglas fir is the classic one. It takes hold in the soil the pioneers built, in the light the pioneers no longer monopolise. The mid-canopy thickens. The soil deepens. The water cycle stabilises. The forest starts to look like a forest.

Only after another century of that, sometimes longer, do the climax species begin their long work. Western hemlock. Western red cedar. Sitka spruce. These are the trees that can grow in deep shade, on deep soil, and that take centuries to reach their final form. They could not have started earlier. The conditions to support them did not exist.

You do not wait for old growth. You sequence the conditions that make it inevitable.

The 2026 mistake is to treat durability as a waiting game. As something that happens if you stick around long enough. As patience. It is none of those things. It is a sequenced discipline.

People who build durable work, in any field, run succession on purpose. They start with the equivalent of pioneer species in the soil. Raw notes. Half-formed observations. Captures of things they do not yet understand. None of it looks important on its own. They tend that layer until it gets dense enough that something more structured can grow in it. Then come the middle-tier pieces: working analyses, side-by-side comparisons, the first attempts to make sense of what the captures are saying. Only then can the late-canopy work germinate at all: the long-form synthesis, the load-bearing essay, the framework other people start citing.

You see the same pattern in research, in product, in writing, in companies. The famous output is the late-canopy tree. The two layers underneath it, mostly invisible, are what made it possible at all. Skip them and you get a sapling planted in clear-cut. It dies. Or worse, it survives long enough to look promising, then dies in the first dry summer.

The disciplined version asks a different question about everything you produce. Not “is this important enough to keep?” Pioneers do not look important. Nitrogen-fixers do not look important. The real question is “what is the next layer that this would make possible?” If the answer is nothing, you have grown a piece of fireweed. Fine. Note it and move on. If the answer is something, you have laid down a millimetre of soil, and the next thing planted in it will go further.

This is a hard reframe to swallow because almost no incentive structure in 2026 rewards pioneer-tier work. There are no metrics for soil-building. There is no leaderboard for the work nobody can see yet. The reward structure prizes the late-canopy tree, the visible output, the thing that can be screenshotted. Anyone who wants old-growth work has to pay for the underlayers themselves, with their own time, against the gravitational pull of a culture that only ever looks at the canopy.

The pay-off, when it comes, is disproportionate. A late-canopy synthesis grown out of a thick understory is not the same animal as a sapling planted in bare ground. The first is rooted in a system. The second is decoration.

Disturbance Is How New Growth Happens

A forest that never gets disturbed slowly chokes itself.

This is one of the most counterintuitive results in 20th-century forest ecology. The intuitive model says: protect the forest, suppress the fires, keep the loggers out, and you will have a healthy ecosystem. That was the dominant US Forest Service policy for most of the 20th century. The result was forests that were denser, more uniform, more disease-prone, and far more vulnerable to catastrophic fire than the ones the policy was meant to protect.6

What was missing was disturbance. Specifically, the small, frequent, gap-creating disturbance that opens a hole in the canopy and lets new species establish. A 40-metre tree falls in a storm. Light hits the forest floor for the first time in two centuries. Seeds that have been sitting dormant in the soil germinate. New species establish. In time, the gap closes. Net result: the forest stays younger in patches, more diverse, more resilient.

Without disturbance, the canopy holds. The same handful of dominant species keep their position. The understory, the layer of smaller plants growing under the canopy, thins out. New growth has nowhere to go. The forest looks fine for fifty years and then collapses all at once.

AI is not the storm. AI is the canopy gap. Different question, different answer.

The default 2026 reading of AI is the storm reading. The canopy is collapsing, the dominant species are about to be displaced, panic is the right response, and the only move left is to grab a chainsaw and join the felling. That reading is wrong in a precise way. It treats the disturbance as terminal rather than generative.

The forest reading is different. AI is a canopy gap. A patch of light has opened that was not there before. Species that were dormant in the seed bank for decades, because there was no light for them, can now germinate. Species that already dominated the canopy are not necessarily displaced. They no longer monopolise the light. Whether the gap closes back into the same forest or grows into a different one depends on which seeds were already in the soil.

This changes the question you ask about your own work. Not “how do I survive AI?” Try this instead: which seeds were sitting in my seed bank that this canopy gap finally lets me plant? Some of these will be projects you would not have started without AI. Some will be species of work you abandoned years ago because the canopy was too closed for them to survive. Some will be whole categories of practice that stayed dormant because no one had the substrate to grow them in.

You can do this audit on a single sheet of paper. Three projects you would not have started without AI. Three projects you should have stopped because they were filling space that could now be a gap. Three things in your seed bank that have been waiting for light. The output of this exercise is rarely what you expect. Most people find that the projects they would have stopped are obvious in retrospect and were obvious before AI arrived. They were being kept alive by inertia. The disturbance reveals what was already not working.

The mature operator does not chase disturbance. They read it. They wait long enough to see which gap opened, which species the disturbance favoured, and which dormant seeds in their own seed bank are now viable. Then they plant. The species that fill a canopy gap fastest are not always the species still standing in fifty years. The 2026 winners will be the people who can tell the difference and plant for the second forest, not the first.

The Forest That Knows It Is a Forest

The knowledge system underneath this essay is itself an old-growth forest, by my reckoning. It is built around five claims that show up, independently, in field after field. They were not invented for this article. They were derived, over thousands of analyses, from patterns that kept appearing across AI research, neuroscience, financial markets, biology, and history. I have written about them before. They are the backbone of every other piece in this newsletter.

Read them as a forester would, and they stop sounding abstract.

Law I says the bottleneck always migrates. In the forest this is succession. Whatever is limiting the system moves up the stack as each layer matures. First the soil is the limit. Then it is light at the floor. Then it is competition for canopy space. Then it is the carrying capacity of the fungal network. Whatever was limiting last decade is not what is limiting now. The forester still fertilising soil that is no longer the bottleneck is wasting effort, in exactly the same way the operator still optimising last year’s layer is wasting theirs.

Law II says difficulty is load-bearing. In the forest this is the soil profile. The slow accretion is what makes a 400-year-old tree possible. There is no shortcut soil. There is no fertiliser that produces old-growth substrate. The difficulty is doing a job, and removing it does not accelerate the forest. It produces a different forest, one that gets cleared in a generation.

Law III says architecture outlives content. In the picture this essay has been drawing, the mycorrhizal network is the architecture and the trees are the content: individual trees come and go over centuries. Forests that lose their fungal substrate, through clear-cutting or soil disturbance, do not grow back the same way even when you replant the trees. The architecture is gone, and the content has nowhere to root.

Law IV says knowledge is constrained by instruments, not theory. In the forest, your instrument was your eye, and your eye could only see the canopy. For most of human history, foresters knew the trees and not the soil, because the trees were the only thing the available instrument could resolve. Soil cores, isotope tracers, modern mycology: those gave us the substrate. The substrate was always there. The instrument was new. Every field has a moment like that. AI is one of them now, and the operators building the right instruments will see what the canopy-only operators cannot.

Law V says capability without correct targeting makes things worse. In the forest, this is canopy gap targeting. A storm opens a gap. If you respond by planting more of the species that already dominated the canopy, you have added capability aimed at where the old forest was, not where the new gap is. That is most 2026 AI strategy in one sentence: capability poured into the layer of work that just got commoditised. The targeting is wrong. More capability does not fix wrong targeting. It accelerates the misalignment.

The five laws are not five laws. They are one forest, viewed from five angles.

The reason this matters is that almost every operator in 2026 is reading their situation one law at a time. They are optimising the bottleneck where it used to be. They are removing friction that was doing structural work. They are investing in tools and ignoring the architecture underneath. They are theorising harder instead of building better instruments. They are adding capability aimed at the wrong target. Any one of those damages the system. All five together give you a forest that looks productive for a year and is gone in three.

The five-law reading is one diagnostic, not five. Read your situation as a forest, then ask. Where has the bottleneck moved to? Is the friction you want to remove doing structural work? Is your effort going into the architecture underneath, or the canopy on top? Do you have the instrument to see the substrate? Is your capability aimed at the gap that just opened, or the one that closed years ago?

These are not slogans. They are a single diagnostic, applied to one system at a time, in writing.

The One-Week Test

Pick one project you shipped in the last 90 days. Not your favourite. One that was real. Open the file. Read it again.

Then sit with three questions, one paragraph of writing each.

What is the substrate this output is sitting on? Not the tools, not the framework, not the model. The accumulated thing: the judgement, the taste, the relationships, the context that made this specific output possible and would not have been there a year ago. If the honest answer is “I do not know,” good. That is an honest answer and it is telling you something.

What is the canopy gap that created the conditions for this project to exist now? What disturbance opened the light it grew into? If the project would have been impossible two years ago, name what changed. If the project would have been possible two years ago and you only got to it now, name what was holding the canopy closed.

If the model that helped you write this output were obsolete tomorrow, what would survive? The substrate or the canopy? The output or the architecture underneath it? The visible thing or the slow accretion that produced it?

Most operators cannot answer all three the first time they run this test. That is not failure. That is the diagnostic. The point is not the answers. It is noticing which question comes hard. The forced one is where the canopy is hiding the soil. That is the layer you cannot yet see, which usually means it is also the layer you are not yet tending.

The good news is that the underlayers are slow to build and slow to lose. A year of deliberate substrate work is worth more than a decade of reactive canopy chasing. The forest is patient that way. Once the soil is built, it holds.

The canopy is what gets the light. The forest is what is still standing in 400 years.

If you ran the test this week, I want to know which of the three questions was the one you could not answer. That will tell me which layer of the forest most readers cannot yet see, which will tell me which piece to write next. Comments are open below.

The longer self-assessment version of this test, called The Forest Floor Audit, takes about thirty minutes and walks through the five layers in detail. Free, linked at the foot of this post.

The Carmanah Giant grows in Carmanah Walbran Provincial Park on the west coast of Vancouver Island, in Ditidaht territory. It is widely cited as the tallest tree in Canada at approximately 96 metres (315 ft). Published age estimates vary considerably, ranging from under 400 years to around 700 years, with no single authoritative dendrochronology on record. See Ancient Forest Alliance, “Conservationists locate and climb the largest Sitka spruce tree in BC’s famed Carmanah Valley” (2024), https://ancientforestalliance.org/climbing-carmanah-valley-largest-sitka-spruce/, and BC Geographical Names, https://apps.gov.bc.ca/pub/bcgnws/names/41299.html

Mycorrhizal hyphae are typically 2 to 10 micrometres in diameter, around an order of magnitude thinner than a human hair, which averages 50 to 100 micrometres. The density of fungal mycelium in mature temperate forest soils has been measured at hundreds of metres of hyphae per gram of soil. See Read, D.J. & Perez-Moreno, J., “Mycorrhizas and nutrient cycling in ecosystems — a journey towards relevance?” New Phytologist 157 (2003), https://doi.org/10.1046/j.1469-8137.2003.00704.x

Simard, S.W., Perry, D.A., Jones, M.D., Myrold, D.D., Durall, D.M. & Molina, R., “Net transfer of carbon between ectomycorrhizal tree species in the field,” Nature 388, 579 to 582 (1997), https://doi.org/10.1038/41557. The original field demonstration of bidirectional carbon transfer between birch and Douglas fir seedlings through shared mycorrhizal networks. Simard’s later work, including the 2016 TED talk How Trees Talk to Each Other, brought the wood-wide web into wider awareness. The strong forms of the wood-wide-web hypothesis have been challenged in recent years, notably Karst, J., Jones, M.D. & Hoeksema, J.D., “Positive citation bias and overinterpreted results lead to misinformation on common mycorrhizal networks in forests,” Nature Ecology & Evolution 7 (2023), https://doi.org/10.1038/s41559-023-01986-1. That review judges field claims that such networks are widespread in forests, or that resources moving through them improve seedling performance, “insufficiently supported”, and finds that unsupported claims in the literature have doubled in 25 years. The 1997 study measured carbon only, in seedlings.

Wahab and colleagues, citing earlier work, put the share of land plant species in close partnership with one group of these fungi alone, the arbuscular mycorrhizal fungi, at about 80 percent. See Wahab, A. et al., “Role of Arbuscular Mycorrhizal Fungi in Regulating Growth, Enhancing Productivity, and Potentially Influencing Ecosystems Under Abiotic and Biotic Stresses,” Plants 12 (2023), https://doi.org/10.3390/plants12173102. For the philosophical reframe of forests and humans as networked rather than individual, see Webb, C., We Have Never Been Individuals, Behavioral Scientist, https://behavioralscientist.org/we-have-never-been-individuals/, and Webb, C., The Arrogant Ape: The Myth of Human Exceptionalism and Why It Matters (2025).

Red alder (Alnus rubra) hosts nitrogen-fixing Frankia bacteria in root nodules and can fix 100 to 300 kg of nitrogen per hectare per year in Pacific Northwest forests, materially altering soil chemistry within a single rotation. See Binkley, D., Sollins, P., Bell, R., Sachs, D. & Myrold, D., “Biogeochemistry of adjacent conifer and alder-conifer stands,” Ecology 73 (1992), https://doi.org/10.2307/1941452

The shift away from total fire suppression in US Forest Service policy followed the 1995 Federal Wildland Fire Management Policy review, which formally recognised that decades of suppression had produced denser, more vulnerable forests. See Stephens, S.L. & Ruth, L.W., “Federal forest-fire policy in the United States,” Ecological Applications 15 (2005), https://doi.org/10.1890/04-0545

The Forest Floor Audit

The longer self-assessment version of the one-week test

Forest Floor Audit

207KB ∙ PDF file

Download

The Model Is Not the Moat

Tue, 14 Apr 2026 00:00:00 GMT

I keep hearing the same assumption underneath AI strategy talk:

the winner will be whoever has the strongest model.

Smarter model wins. Everything else is secondary.

That sounds plausible right up until you look at how people actually choose tools in real life.

If scale laws keep holding, local models probably will not beat the frontier on raw intelligence.

But users do not adopt “raw intelligence.” They adopt something that fits into their day.

They adopt the thing that feels fast enough, private enough, legible enough, reliable enough, cheap enough, and integrated enough that using it becomes natural.

That is the first distinction that matters.

The benchmark measures the visible product.

The moat forms one layer out, in the surrounding package.

The Product And The Seat

This is where a lot of AI debate still feels strangely naive. People compare models as if users experience them as isolated intelligence engines.

Most of the time they do not.

They experience a bundle: interface, defaults, permissions, speed, memory, privacy, cost, and how much the tool asks them to rearrange their behaviour.

That bundle is where trust accumulates.

It is also where switching costs quietly form.

A frontier model can win the benchmark and still lose the seat.

By “seat” I mean the position a product earns inside a user’s actual workflow. The place where their context lives. The place they trust not to embarrass them, leak data, slow them down, or force them to relearn everything.

The product is the thing they evaluate.

The seat is the thing they get used to living in.

And those are not the same asset.

You Can Already See It In Coding Tools

A model that is slightly worse on a public benchmark can still be the one people prefer if it lives inside the editor, sees the repo, responds instantly, keeps sensitive code local, and fits the way they already work.

The model may be weaker in the abstract.

The package is stronger where it counts.

That gap matters because people do not make adoption decisions in the abstract. They make them under workflow pressure. They choose the tool that keeps momentum, feels trustworthy, and does not introduce a new category of risk.

This is also why “just use the best model” is often bad product advice. The best model according to a leaderboard may carry the wrong latency, the wrong privacy posture, the wrong integration burden, or the wrong failure mode for the actual job.

How Moats Actually Form

Apple is the familiar version of this dynamic outside AI. The moat was never just one visible feature. It was the package: ecosystem fit, convenience, defaults, identity, and the low-grade friction of leaving.

The product got attention.

The package became hard to leave.

I think a lot of AI products will work the same way.

Moats usually form in the residue, not in the headline claim.

In habit.

In muscle memory.

In stored context.

In predictable behaviour.

In the feeling that this tool understands how you work and does not make you pay a tax every time you use it.

That is the important shift. A lot of the value is created by side-effects of repeated use, not just by the explicit capability being marketed.

What This Means For Builders

Local models do not need to win the intelligence race to matter.

They can win a different race entirely: trust, control, governance, latency, privacy, and workflow fit.

That is a more durable position than it sounds.

Once a tool becomes the place where your context lives, your defaults settle, and your work starts to flow, a better benchmark somewhere else is not enough to dislodge it.

If I were building in this market, I would treat that as a design rule:

Do not ask only, “How do we make the model look stronger?”

Ask:

Where does the user feel risk right now?
What part of the workflow still feels awkward or fragile?
What context would make the tool more useful after 30 days than on day 1?
What would make leaving this product feel expensive in a good way?

That is how you build the seat.

Not by winning one benchmark snapshot, but by creating a package that compounds through use.

The Real Question

This is the distinction I keep coming back to:

The product is what gets measured once.

The seat is what gets harder to leave over time.

That is why packaging matters.

Not because it disguises weakness.

Because it is where practical advantage compounds.

If frontier capability stays centralised, that is the strategic question for everyone else.

What seat are you building that people will not want to leave?

Where value sits · The Durability Curve

You Can Win the Wrong Game for Years

Right about the technology, wrong about the stock

The trap in looking up

The dead end that worked

The underpriced number

Both look the same from here

Commit the test before you act

Where it matters most

Footnotes

How Long Until Your AI Edge Stops Paying?

The two rates

Venice owned the layer, then lost it

Where the money lands now

The clock decides

Run it on your own layer

Footnotes

The Cheaper Fix You Keep Skipping

The same error, room after room

Now watch a machine

Why the wrong diagnosis wins

The cost the asymmetry hides

When the deficit is real

The diagnostic you can run this week

Footnotes

Your Tools Got Powerful. Get Boring.

The bored trader beats the machine

The gap widens as the tools get stronger

What complexity quietly costs

Why we reach for sophistication anyway

What the constrained version keeps proving

The test that catches you in the act

The 90-Day Canopy Audit

The meeting everyone recognises

Name the disturbance

The 12-item audit

The boundary argument is the point

The decision changes

Run it on your own work

A useful warning

Start Here: What Survives When The Surface Changes?

The Lens

The Test

Run one on your own work

Start with the problem you have

I want the shortest version of the whole idea.

I build with AI agents and I need them to be reliable.

I am deciding what to build on, or what to standardise across a team.

I need to know whether my evaluation is telling me the truth.

I am thinking about my own job.

I want the framework underneath all of it.

What to expect

If You Only Remember One Thing

The Displacement Rate Audit

The Substrate Map

The Forest Floor Is The Product

Velocity Was Always a Trick of the Light

The Mycorrhizal Network Is the Product

Succession Is a Discipline, Not a Wait

Disturbance Is How New Growth Happens

The Forest That Knows It Is a Forest

The One-Week Test

The Forest Floor Audit

The Model Is Not the Moat

The Product And The Seat

You Can Already See It In Coding Tools

How Moats Actually Form

What This Means For Builders

The Real Question