What the Stack Does Not Solve

The ladder finished the assembly: five disciplines, five primitives, five levels, one stack. Fourteen parts of a series is a lot of confidence, and every series I publish ends the same way — with the ledger. Not a summary, not a victory lap: an honest accounting of where the material is thin, where a number is softer than its sentence sounded, and where the whole framework simply stops. This is that part. If the series earns your trust anywhere, it should be here, where I list the ways it might not deserve it.

The thesis I believe but cannot cite

Early in the series I wrote that the practitioners who get ten-times results from agents have built better context infrastructure, not better prompts. That sentence is the closest thing this series has to a thesis, and I owe you its epistemic status: it is an observation from practice, not a finding. There is no study behind it. No one has run the controlled comparison — same engineers, same tasks, prompts varied against infrastructure varied — and I am not aware of anyone who could, cleanly. What I have is pattern-matching: my own before-and-after, and the consistent shape of the practitioners I read, where the people producing remarkable output talk about context files, harnesses and evaluation, and almost never about wording.

I still believe it. But a belief repeated across fourteen parts starts to sound like a fact, and it is not one. Treat the series as an argument for a hypothesis, made by someone who has bet his own workflow on it — not as a proof.

A habit dressed as a threshold

The context parts of this series leaned on the smart-zone/dumb-zone idea: that agent output degrades well before the context window is full, and that the practical ceiling sits around forty per cent utilisation. The attribution matters more here than anywhere else in the series. Dex Horthy and the HumanLayer team argue that beyond roughly 40% context-window utilisation, output quality degrades — their workflow is built around staying under it. That is one team's working number, distilled from their own production practice. It is not a benchmark, and nobody should tune a pipeline to 40 as if it were a law of nature.

What is well evidenced is the direction. Anthropic's engineering guidance puts it plainly: "Context is a critical but finite resource for AI agents." And the degradation is measurable at the extremes: as of the Opus 4.6 release (February 2026), Anthropic reported that Sonnet 4.5 scored 18.5% on the 8-needle 1M-token variant of the MRCR long-context benchmark — while Opus 4.6 scored 76% on the same test. Two lessons in one pair of numbers: long-context degradation is real, and the models are improving fast enough that any specific figure is a snapshot. The direction is proven; the threshold is folklore. If your workflow depends on 40 being exactly right, you have built on a habit, not a finding. Watch your own agents and find your own number.

The discipline this series only waves at

Part 13 admitted this in one line; it deserves a paragraph. Evaluation design got a primitive — three to five test cases with known-good outputs for every recurring task — and it got an admiring description of StrongDM's holdout scenarios in part 14. What it never got is a how-to. There is no part of this series that walks through building an evaluation harness: how to grade non-deterministic output, how to score prose against intent, how to keep a holdout set honest when you are a team of one, how to know whether your cases measure anything.

The reason is uncomfortable and worth stating plainly: I do not yet have an evaluation practice worth teaching. My folder of cases is real and it has caught real regressions, but it is thin, and it has never survived contact with a genuinely hard evaluation problem. The gap in the series mirrors a gap in the field — everyone now says evaluation matters, and the craft literature on actually doing it remains the weakest shelf in the discipline. It also mirrors a gap in the stack itself: evaluation is the only layer that checks the other four, and it is the layer this series covers least. If there is a sequel, it starts there.

Every number here has a use-by date

This series opened on a figure: Anthropic's research reporting that the 99.9th-percentile turn duration in Claude Code nearly doubled in three months, from under 25 minutes to over 45. It quoted Boris Cherny's estimate that roughly 90% of Claude Code's own code is written with Claude Code — an interview claim, not an audit. It cited a long-context benchmark score from a specific model announcement. Every one of those was verified against its primary source when I wrote it, and every one of them is a snapshot of a field moving faster than publishing schedules.

That is why the figures in this series carry dates and owners in the prose — “Anthropic reported”, “as of the Opus 4.6 release”, “Cherny has said”. The habit is not academic fussiness; it is a load-bearing part of writing about this field honestly. If you are reading this a year after publication, assume the numbers have moved and re-check them before repeating them. What I will defend past their expiry dates are the structures: the disciplines, the primitives, the ladder. The numbers are scaffolding; the stack is the building.

When not to reach for the stack

A framework that claims to apply everywhere applies nowhere, so here is where I do not use any of this.

• When you cannot write acceptance criteria. Part 13's diagnostic cuts both ways. If three verifiable sentences will not come, the task is not under-specified — it is not yet a delegation at all. It is research, and research is better done in conversation, or by hand, until done has a shape. Forcing the stack onto an exploratory problem produces confident agents building the wrong thing to a high standard.
• When the work will never recur. The harness pays for itself across sessions; a constraint file, a context map and an eval folder are investments that amortise. A one-evening script for a one-time migration earns none of that. Prompt craft alone is the right tool — which is exactly why part 2 called it table stakes rather than obsolete.
• When verification costs more than doing. Some work is faster to do than to review: a subtle change in code you know intimately, a judgement call soaked in context that exists only in your head. Delegating it means writing that context down, reviewing the result against it, and discovering the write-down was the hard part all along. Do those yourself and save the stack for work whose criteria externalise cheaply.
• When the intent is not yours to encode. The Klarna arc reads the way it does in this series because the popular version of the story did not survive verification — and the corrected version's lesson is sharper: encoding the wrong organisational intent is worse than encoding none, because the agent will optimise it faithfully. If the people who own a trade-off have not decided it, an agent should not be executing it.

What I would do differently

Four things, owned in order of expense.

First, I would write the evaluation how-to before the series, not promise it after — the thinnest layer of the stack should not also be the last one addressed. Second, I would balance the sourcing: the context and harness parts of this series stood on deep, verifiable primary material, while intent and specification — by my own argument the higher-value disciplines — stood on thinner ground. The imbalance repeats the industry's bias: we document what is easiest to document, then mistake documentation density for importance. Third, I would run the claim ledger from day one. Verifying every figure against its primary source late in the process was expensive, and more than once the verification changed the argument rather than the number — the corrected story made a different and better point than the folklore version. Fourth, smaller: one running worked example across all fifteen parts instead of fresh miniatures per part. Composition is the skill the primitives teach, and a single project threading the whole series would have shown it better.

What the stack does solve

After a part of subtractions, the closing balance. What survives all of the above is the thing I actually use every day: when an agent's output is wrong, the stack gives me an ordered place to look. Was the instruction unclear — prompt. Did the model lack something it needed to know — context. Does it relearn that thing every session — harness. Did it optimise for something nobody wanted — intent. Could it not tell what done meant — specification. The fix almost always lives one layer above where the symptom showed, and knowing that turns a vague sense of “the AI got it wrong” into a diagnosis with a location. That is a modest claim, sturdier than any benchmark I could have cited, and it is the one this series was written to make.

The stack does not make agents reliable. It makes their failures legible — and legible failures are the raw material every discipline here is built from. If you arrived at this final part first, the beginning is the best place to start: what changed when agents stopped checking in.