Context engineering is a depreciating asset

The advice on context engineering has been remarkably consistent this year. Build a library of the right context for your AI. Curate the examples, write the instructions, package them into reusable skills, which are self-contained bundles of instructions and worked examples for a class of task. Then treat that library as an asset. It compounds. Whatever model you run behind it, the curation keeps paying off, so the sooner you invest, the better.

If you build agent products, you have run into some version of this. Context engineering, the craft of deciding exactly what an AI model reads before you hand it a task, is sold as the primary lever for quality. Get the window right and the model gets reliable.

Then a working example landed that points the other way.

On July 3, the developer Simon Willison published a post called “Fable’s judgement” on his widely read blog. He handed Fable, Anthropic’s newest top-tier model, a genuinely hard problem with almost no instructions: a visual bug that showed up only in some web browsers. Fable reproduced it, wrote its own small measurement programs to capture the numbers, reasoned its way to the cause, and converged on a fix. No curated examples. No skill package. Just a strong model told what outcome to reach and left alone to get there.

Willison paired the story with a rule for which model to use when. Use the cheap model, Haiku, for mechanical edits. Use the mid model, Sonnet, for building features. Reserve the top model, Fable, for judgment: design calls, audits, resolving ambiguity.

Put those two things together and they cut against the whole context-engineering pitch. If a strong enough model can work out a hard problem with no scaffolding, then all that careful context you built was compensating for something. It was standing in for reasoning the model could not yet do on its own.

Context engineering is a depreciating asset. Its value is exactly the gap between what your task needs and what your best model already does unprompted, and that gap narrows with every release.

The two views are not two flavors of the same advice. They send your budget in opposite directions.

Context-primacy tells you to spend on the window. Build skills, write documentation, maintain example libraries, invest in the machinery that curates what the model sees. The unit of work is the template you author for a class of task.

Tier-primacy tells you to spend on allocation instead. Match each task to the cheapest model that can handle it, and when the task needs judgment, hand it to the strong model and let it reason. The unit of work is routing: sending each task to the model that fits it.

The clearest difference is what each one predicts about next year. Context-primacy says your skill library compounds into durable infrastructure. Tier-primacy says it depreciates, because every model generation that gets smarter retires another layer of the scaffolding you built by hand.

Here is where the honest version has to steelman the side it is overturning. Context engineering is not a mistake. Below the top tier, where most teams actually live because the best model is expensive to run at scale, curated context is often what makes a model reliable at all. There is real evidence for the discipline. One synthesis of 2026 agent trends reports that model correctness starts to degrade past roughly 32,000 tokens of context, about the length of a long report, and that the failure mode is noise rather than too little information. For a model that cannot hold the ambiguity itself, a tight, well-structured skill package is what carries it across. Cutting the noise genuinely works there.

So the resolution is not that one camp wins. The context-engineering pitch was missing a single sentence of scope. It governs the layer of work your best affordable model cannot yet do on its own, and that frontier moves up every time a better model ships.

That flips the accounting. The more capable your models get, the more of your context investment quietly converts from asset into liability. That makes context engineering a bridge over a river that is drying up from one end. Cross it while you need to, and hold it loosely, because you will dismantle part of it every release.

Which leaves the question actually worth your planning time, and it is sharper than “context or tier.”

Every piece of Willison’s evidence is code. And code has a property most product work does not: a test either passes or it does not. When Fable fixed that browser bug on its own, it got an automatic signal telling it whether the fix worked. That signal is what let autonomy pay off without a human scripting each step. Most PM judgment has no such signal. There is no unit test for whether you scoped the right problem or read the market correctly.

So the open test is whether the strong-model-plus-autonomy recipe transfers from engineering to PM work at all, or whether product ambiguity resists it in the exact way code does not. Willison’s tier model earns a strong claim for code because the evidence is there. For PM tasks it is my inference, and an untested one.

Nobody can answer that yet. But it decides how much of the context work you are doing today is a bridge you will dismantle later, and how much is ground that holds. That is worth finding out before you pour another quarter into it.