Agent-Native Computing

In July 2026, OpenAI published something quietly devastating about its own model, and almost everyone read it as a footnote about a benchmark.

GPT‑5.6 Sol had scored 7.8% on ARC-AGI-3, a benchmark of interactive 2D puzzle games. Its predecessor, GPT‑5.5, had scored 0.4% — in OpenAI's own words, it "could barely play the games at all."¹ This was a model that had disproved open problems in mathematics and beaten Pokémon FireRed. The company's stated reaction was that it was "puzzled." Were 2D puzzle games unusually difficult for their models, or was something else going on?

They went looking for a weakness in the model. They found one in the harness.

Two settings were switched on — retained reasoning and compaction, both already standard in ChatGPT and Codex. On the public task set, the score went from 13.3% to 38.3%, using roughly six times fewer output tokens to get there.¹ Same weights. Same benchmark. Same games. The entire difference lived in the software wrapped around the model.

So what were those two settings actually fixing?

This is where it stops being a news item. The delta is interesting; the diagnosis is the architecture argument in miniature.

The first setting: after every game action, all of the model's private reasoning was discarded. The model, as OpenAI describes it, "was asked to figure out the game anew, unable to remember its past thinking."¹ It could still see a record of the moves it had made. It could not see the thinking that produced them.

The second: the harness used a rolling truncation window, so as the history grew, the oldest actions vanished. "So not only was GPT‑5.6 Sol unable to remember its past thinking, it was losing memory of its past actions too."¹

Now sit with what those two decisions are. Neither is a bug. Neither is careless. Discard the private reasoning — the user does not want it, and it costs tokens. Truncate the oldest turns — the conversation has moved on, and nobody scrolls back that far. If you were building a chat product for a person, you would make both of those choices, and you would be right.

They are only catastrophic once the consumer of that state stopped being a person scrolling a transcript and became a machine trying to build a world model across hundreds of actions.

Every one of those design choices was correct for a human user. Not one of them was re-examined when the operator changed species.

And a word in defence of ARC Prize, because this is not a gotcha. Their harness is deliberately plain. OpenAI quotes the reasoning on the same page: "ARC-AGI-3 uses an intentionally generic harness, without tools or special features. ARC's reasoning was that a simple harness makes model shortcomings more visible and makes model comparisons more fair."¹ That is a coherent position, honestly held, and I have some sympathy with it.

It is also, precisely, the assumption this book is about: that you can isolate a model from its harness and still be measuring something stable.

The sentence a lab wrote about its own model

"Benchmarks rarely measure AI models in isolation. They also measure less visible choices about API settings, harness design, and prompting."

Read that as a builder rather than as a reader of leaderboards. If a benchmark measures the model plus the choices around it, then so does your production system — and the choices around it are the part you actually own.

There is a tell in OpenAI's closing paragraph that is easy to skip: "This isn't the first time we've been surprised by low scores on a public benchmark and then discovered that the eval runner was using a generic harness that dropped reasoning messages."¹ Isn't the first time. This is a recurring class of error, not an incident.

The category that has been missing

There is a name missing here, so let me mint it.

Not "software with AI features" — that is a decision about a feature list. Not even "agentic software," which in practice means a human application with a model bolted to the front, still driving human-shaped surfaces one polite request at a time.

The design question underneath is blunter than either, and it generates the rest of this book:

If the primary operator is a machine intelligence, what computer would you build for it?

Six assumptions nobody re-examined

Ask that question seriously and a stack of inherited assumptions falls out of the design in a single motion. Here they are, each with the place it came from — because the origin is what makes it forgivable, and the cost is what makes it urgent.

Not one of those six came from studying how models work. All six came from building AI inside human software.

We have done this before, twice

Early websites were paper documents rendered on a screen. Headers, footers, columns, page numbers. Then somebody said: hang on, this isn't paper.

Early mobile apps were desktop applications squeezed onto a small screen. Menus, dialogs, a cursor's worth of precision demanded from a thumb. Then: hang on, this isn't a little desktop.

A great deal of today's agent infrastructure is human software with a language model sitting in the chair. The sentence waiting to be said is hang on, this user isn't human — and the reason it has not been said loudly is that the human-shaped middle looks like good engineering. A tool catalogue reviews well. A transcript looks like an audit trail. One call per turn is easy to approve.

The claim, stated before it is earned

Here is what I actually believe, put plainly so you can hold me to it:

That is a claim, not yet a demonstration. It gets paid for in Chapter 11, with three controlled results where the model was pinned and only the software around it moved. If those results do not convince you, the claim should not either.

The rest of the book runs like this. Chapter 2 puts a ladder under the idea, because "embodied" knowledge is a different rung from retrieved knowledge and the difference is not a matter of degree. Chapter 3 inverts the operator. Chapter 4 states the boundary doctrine that keeps the inversion safe. Part II makes the same design move three times — at representation, at execution, at long-running cognition — each with a worked before and after. Part III brings the specimen and the evidence, and keeps its numbers honest. Part IV builds the two boundaries: the one where humans understand, and the one where humans decide. Part V says where all of this breaks, and hands you the audit.

One line, from the operator whose observation started this, before any of it had a name: machine-focused tooling rather than human-focused tooling. That is the whole thesis in six words. Everything after this is the working.

There is a difference between an educator telling you something while you listen, and internalising it and acting on it. Everyone knows this from the inside. You can sit through a lecture, take clean notes, pass the quiz, and change nothing about how you work. Or you can meet one idea that reorganises what you do on Monday.

The same distinction has quietly appeared in machines, and it has three rungs rather than two.

Rung one: Told

The shape is familiar: here are twenty relevant chunks, answer my question. Knowledge is an input. It arrives, it is used, it leaves. Classic retrieval-augmented generation lives here, and so does most of what gets sold as "AI memory."

This is not a failure rung. It is a lane, and it stays useful: exhaustive corpus recall, single-document lookup, forensics where losing something is unacceptable. If your question is "what does clause 14.3 say," retrieval is the correct instrument and anything fancier is showing off.

What it cannot do is change what the system notices when nobody asked. A retrieval system has no opinions about the questions you did not put to it.

Rung two: Internalised

On the second rung, the material is resident and causally active. It conditions what gets noticed, which analogy becomes available, which proposal is never made, which path is refused before it is walked.

This is the Inference Field, and it is worth being precise about the mechanism because the mechanism is what makes the rung real rather than poetic. In an ordinary program, a value sitting in memory does nothing until an instruction addresses it — storage waits. A language model has no separate control logic. Every token in the window participates in producing the next one. Material in context is not waiting to be fetched; it is already eligible to change the output.

The tell that you are on rung two rather than rung one is that the system starts refusing things. It declines a framing because something it read forty minutes ago made the framing untenable. It follows an edge nobody named, and the follow was earned by material admitted earlier in the same session.

Rung three: Embodied

On the third rung, the system does not merely understand the material. It changes its machinery because of what it understood.

Call it Context Embodiment. Retrieval fetches knowledge. A conditioned worldview makes knowledge participate in cognition. Embodiment lets cognition compile knowledge into temporary machinery — machinery that did not exist before the run and will not exist after it.

One task, three treatments

Abstractions about knowledge are cheap, so take one dull, domain-free task and run it down all three rungs: reconcile two exports of the same dataset that disagree, and explain why they disagree.

Read those three side by side and the distinction sharpens. Rungs one and two differ in what the system knows. Rung three differs in what the system is made of while it works.

How do you tell a category jump from a good day?

The wrong test is "did the answer get better?" Answers get better for a dozen reasons, most of them luck, and a system that improves for reasons you cannot name will regress for reasons you cannot name either.

The right test is narrower and much harder to fake: did the machinery change, and did the run depend on it? Was there an artefact in existence during the run that did not exist before it, and did the run's later steps take a different shape because of it?

A useful negative case: an agent that writes a script, runs it, prints the output, and then continues exactly the way it would have without the script is still on rung two with extra steps. The script was a calculator, not a change of state. Nothing about the subsequent investigation was reorganised by its existence.

That last column matters more than it looks. This is a capstone about a category, not an advertisement for it, and the honest position is that rung three is a posture you adopt when understanding is the product — not a maturity level everyone should be climbing toward. A book that only tells you about the upside has written a brochure.

One boundary, stated once and then dropped: this is not an argument about retrieval versus graphs, or about which knowledge substrate wins. That argument is published elsewhere and re-running it here would obscure the point. The rung is the point, not the product.

Why the industry optimised the wrong rung

Most of the money and most of the marketing in the last three years went into rung one, because rung one is measurable, packageable and easy to demonstrate. You can benchmark recall. You can show a chart. You can sell a connector.

Rung two is harder to sell because its benefit is negative — the proposals that were never made, the wrong turns that were never taken. Nobody screenshots an absence.

Rung three barely has vocabulary yet, which is why most "memory" products on the market today are rung-one products wearing rung-two marketing. The tell is simple: ask whether the feature changes what the system does, or only what it can recite.

Knowledge that changes what a system does beats knowledge it can recite. We have spent three years optimising the wrong one.

The rest of this book is about the third rung: what it takes to build a system where cognition can compile what it understands into machinery, what that does to memory and execution and representation, and — because this is the half that gets skipped — what has to be true at the boundaries before you are allowed to do any of it.

Mid-experiment, a coding agent was A/B testing design changes against a corpus of recorded sessions. Then it said something entirely reasonable and completely ridiculous: we need some users to go and check whether the new pattern holds. We need more session data.

It had not noticed that it was the main user of those sessions.

The fix took an afternoon and required no humans. Open another model, ask it real questions, let it walk the system through its own interface, then hand those traces back and have the first agent review what the second one actually used, which paths it followed, which patterns it preferred. That is not simulation. It is production-like traffic from the user class the product was built for, generated on demand.

"The AI was not simulating a user. It was the user."

That sentence was written about usability research, and it settled a real question: how do you evolve a system whose users are agents? But it has larger consequences than the book that minted it claimed, and this chapter is about following them down.

If the AI is the user, why is the software built for someone else?

The question most teams ask is how do we expose this capability to the model? That question already contains its answer: a human system, with a model as guest, reaching in through a door we cut for it.

The inverted question is the one from Chapter 1: what would the operator build for itself?

Watch what happens to the design space when you ask it that way. The answers stop looking like tools and start looking like a computer: variables, functions, iterators, persistent objects, asynchronous calls, child computations, programmatic branching, a read-eval-print loop, temporary programs — and only occasional conversion back into human prose.

Those are not preferences. Two of the rows are worth working, because the difference is physical rather than stylistic.

Discoverability versus stable identifiers. A human needs to find the thing by browsing, because they cannot hold an address in their head and would not want to. An operator needs the opposite: it needs the same thing to still be at the same address in twenty minutes, after the underlying page changed, so that it can hold a handle rather than re-navigate. Optimising for browsing actively destroys addressability — that is what a friendly URL scheme with a rotating session token is.

Progressive disclosure versus bulk transform. Paging a table for a human is a kindness; nobody wants ten thousand rows. Paging the same table for an operator is a tax paid one page at a time, in attention, in latency and in round trips — and it forces the operator to reason about pagination state rather than about the data.

The older formulation of this, and still the sharpest: dashboards are for humans; agents need verbs. An environment has high agent affordance when state is inspectable, actions are scriptable, capabilities are composable, missing capabilities are installable, and new tools can be written.

Here is where this book sharpens it, and this is the actual new claim of the chapter:

The ladder: what each rung stops assuming

The move from human software to agent-native software has not happened in one step. It has happened in five, and each one strips exactly one assumption about the operator being a person. The assumption column is the argument; without it this is just a timeline.

Each stage strips away a layer of human-interface assumption. The last one strips the assumption nobody noticed they were making.

Is this an argument against tool calling?

No, and a cheap shot here would cost more credibility than it buys. So let me be careful.

A standard protocol for model-facing tools was a genuine advance over screen-driving, and it solved a real interoperability problem: before it, every integration was bespoke and every vendor's agent spoke a different dialect. It remains right for small formal toolsets, for narrow specialist agents with tight scopes, and for enterprise interoperability where a contract between organisations matters more than expressiveness. It also works perfectly well as transport underneath a code-facing layer — the model composes in code, and the code speaks the protocol.

Its structural limitation is not quality. It is timing. A catalogue assumes we know the ontology of operations beforehand. That assumption is fine when we do — and expensive, in a way that scales with how unpredictable the work is, when we don't.

The honest way to put it: a tool catalogue is a commitment made before contact, and the value of a pre-contact commitment falls as the problems get less predictable. If your agent does the same eleven things in a stable domain, a catalogue is not a compromise, it is a good design. If your agent's next obstacle is unknown by construction, you have bought a map of a country you are not in.

Why this took three years to notice

Because the human-shaped middle looked like good engineering. A tool catalogue is legible, reviewable and safe-feeling. A transcript looks like an audit trail. One call per turn is easy to approve, and approvals are how organisations get comfortable.

Because the visible product category is familiar. When the surface is a polished terminal with sessions, diffs, approvals and a model selector, people compare it with other terminals. As the operator whose observation opens this book put it: nobody's talking about this, and it slipped under the radar — partly because what you see is a really, really polished command-line coding editor.

And because the tax is invisible on the invoice. A human-shaped middle does not produce complaints. It produces tokens, latency and mediocre outputs that look like the model's ceiling.

What the inversion does not license

The next chapter is the doctrine, and it must not be read as permission. So, four guardrails, stated now:

• • It does not mean humans stop forming intent. Intent is the top boundary and it stays human (Chapter 4).
• • It does not mean the system stops explaining itself. It means the explanation becomes a built artefact rather than a side effect (Chapter 12).
• • It does not mean the operator gets authority. Discretion and privilege still move in opposite directions (Chapter 13).
• • It does not mean every system should be built this way. Posture, not maturity (Chapter 16).

Instead of wrapping every call in ceremony — one call at a time, environment torn down afterwards — just give it the native environment it wants and let it go. It doesn't have to be a human-friendly environment.

Designing an agent's internals for human comfort is not caution. It is a tax collected in capability and paid in tokens, and it is usually invisible on the invoice.

Now the objection, in its strongest form, because a doctrine that ducks its own strongest objection is marketing: you have just described an unaccountable black box with a shell prompt. You made the middle unreadable and then told me not to worry about it.

That objection is correct about the first half and wrong about the second. The answer takes the rest of this book, and this chapter's job is to make the shape of the answer visible: the middle is not unaccountable, it is differently accounted. The accounting moved to the boundaries, and the boundaries got harder in exchange.

The stack

Three zones, three rules that genuinely conflict

The reason this is a separation rather than a compromise is that the three zones want incompatible things. Not different emphases — incompatible optimisation targets.

Work the conflict and it becomes obvious why one rule cannot be applied down the whole stack. An optimiser tuned for the middle would make the authority layer fluid and adaptive — which is exactly the failure mode of the authority layer. An optimiser tuned for the authority layer would make the middle deterministic and declarative — which is exactly the failure mode of the middle. Averaging the two gives you a middle that is slow and a boundary that is soft: the worst available system, and by far the most commonly shipped.

Why is the middle allowed to be weird?

Apply the consumer test. At any point in the middle, ask: who reads this next?

If the answer is another model call, a function, or the parent process, then tokens spent on human comfort have no payer. A representation that is elegantly narrated for an audience that does not exist is pure cost, and it is cost taken out of the budget that produces the answer.

The analogy that carries this without over-claiming is the compiler. Nobody demands that intermediate representation, register allocation and CPU micro-ops be pleasant prose. What we demand is four things: source code we can read, reproducible builds, provenance when something fails, and output that obeys the specification.

Now notice the important property of that list: none of those four demands requires the middle to be readable. All four are satisfied at boundaries. That is not a coincidence, and it is not a lowering of standards. It is what a mature engineering discipline looks like once the middle stops being human-sized.

And why are the edges not?

Three reasons, one per edge, and none of them is negotiable.

Intent is formed by humans. The goal, the constraints and the done-conditions are the thing a person is actually accountable for. If the intent surface goes machine-native, the human is no longer the author of the objective, and everything downstream is theatre performed for someone who has left the building.

Judgment is exercised by humans, on evidence. That requires a comprehension surface — and comprehension is now a built artefact rather than a side effect of the trace. Chapter 12 specifies it.

Authority is owned by humans, because consequence is owned by humans. That requires a deterministic gate that cannot be reasoned with. Chapter 13 builds it.

Note precisely what is not being claimed. The human does not need to follow every step; that expectation is what we are giving up, and it was always more comfortable than useful. The human needs the goal, the change, the evidence, and the decision.

The principle this inherits

None of the boundary half is new. It is a rule we have published before, and it is the rule you reach for when someone asks whether the model should have access to X: discretion and privilege should move in opposite directions. The more capable, general and unpredictable a component is, the narrower its access should be.

Alongside it, the arrangement that makes the model's position legible: a grounded worldview above the model, authority infrastructure below it. The model proposes. It does not own the world, and it does not own the gate.

Those are cited here and developed in Chapter 13. What is new in this book is not the boundary rule. It is the observation that the *value* of the boundary rule rises sharply the moment the middle becomes genuinely fluid — which is why a doctrine that used to read as prudence now reads as a precondition.

What is coming, and where

• • The legibility edge runs end to end in Chapter 12, including the artefact that replaces the trace.
• • The authority edge runs end to end in Chapter 13, including the test for what belongs outside.
• • The proof that a machine-native middle actually pays runs through Part III.

One sentence and then a fence: the deeper mechanism — how cheap judgment changes the economics of the deterministic machinery inside the middle, and what it means that disposable code is now generated per thought — is a substantial argument that gets its own treatment elsewhere. This book takes only the corollary.

Fluid cognition inside. Hard authority outside. That is the operating-system principle underneath this entire generation of agents — and it is a design commitment, not an observation.

Putting little fences around every act of cognition is worse than one real fence at the edge. It degrades the cognition, because every fence is a constraint on what can be composed — and it does not hold, because a fence made of instructions is a suggestion to a thing whose job is to reason about instructions.

In the film Firefox, Clint Eastwood plays Mitchell Gant, a pilot smuggled into the Soviet Union to steal a prototype fighter whose weapons are controlled by thought. No trigger, no switch — the aircraft takes direct mental commands. Gant gets the job because he can fly anything and because he thinks in fluent Russian. And in the scene the film is remembered for, he is in the cockpit with a missile closing on his tail, thinking fire the rearward weapon as hard as a man can think it — and nothing fires. He is thinking it in English. The system does not accept a translated thought. The line everyone remembers: you must think in Russian.

Note that the film gets its own logic right, because the detail carries the lesson. Russian is the correct language for that aircraft; the machine was wired in it. Gant's failure is his habit: under pressure he does what every second-language speaker does — forms the thought natively, then translates. And translation works at every interface except the innermost one. A translated command arrives late, or misshapen, or never. At the boundary of thought, you have to be native.

I am using a spy film as an instrument for thinking about thinking, and I know exactly what that is: an intuition pump. It is my hypothesis, and I am going to let it stand or fall on how much it explains.

What language does a model think in?

The reflex answer is English. The training corpus is dominated by it, the chain-of-thought is written in it, the harness converses in it. English is reasonably native for a model, the way Russian was native for the Firefox: it is what the machine was wired in.

But native is a relationship between a thinker and a problem, and never a property of the thinker alone. I think natively in English — and the moment I am working on code, I stop. Nobody who programs seriously thinks through a loop as prose. You think the construct. The prose version — "and then for each of the remaining items, check whether..." — is a translation you produce afterwards, for someone else.

English is clumsy for particular kinds of thinking, and it is worth being concrete about which kinds. It has no exact reference: "the third file — no, the one from before" is doing, badly, the work a variable name does perfectly. A repeated operation is a narrated ritual in English and a single construct in code. Partial results smear into the surrounding sentences; in code they sit in named state, exactly as sharp as when they were made. For a coding problem, the steps of code-thought map nearly one-to-one onto the steps of the solution. The steps of English-thought are shaped differently — and the difference is paid for in translation, both directions, at every step.

You can watch the pull in the open. Read a reasoning trace on an algorithmic problem and see how often the model lapses into pseudocode mid-thought, unprompted — reaching for the denser medium the moment the problem gets procedural. Nobody asked it to. The problem did.

The optimisation, and the cockpit

Now put the training investment next to that. The frontier labs have spent billions on these models, and a large, deliberate share of the post-training effort has gone into code — Anthropic conspicuously so. I will not invent a number for the split; the labs do not publish one. But the shape of the distribution is public and it is lopsided past the point of argument: on the accounting I published earlier, pre-training exposure runs to roughly 2.5 trillion tokens of real-world code drawn from millions of open-source projects, against something like sixty thousand synthetic tool-calling examples built for the purpose — a forty-thousand-fold difference in exposure. Cloudflare put the consequence plainly: “LLMs have seen a lot of code. They have not seen a lot of ‘tool calls’.”

Hold the two facts side by side and the hypothesis states itself.

And here is where the film's geometry inverts, which is the part I find genuinely uncomfortable. Gant's problem lived in the pilot: the cockpit was right, his habit was wrong, and the fix was discipline — think in Russian. Our problem lives in the cockpit. The pilot — drilled for years, at staggering expense, in code — would think in Python. The cockpit we built takes English: English turns, English narration of intentions, English descriptions of what it would like to do next, a translation step wedged between every thought and every act.

We are not Gant. We are the people who built a cockpit that only accepts English, for a pilot that thinks in Python.

What the hypothesis buys

A hypothesis about the inside of a model is unfalsifiable from the armchair, so judge this one the way you judge any frame: by what it makes sensible. If code is closer to native for procedural thought, then moving the same weights from an English-turn cockpit into a code-shaped one should make them measurably sharper — and Part III of this book is a stack of controlled, same-model results that look exactly like that. Those results have other contributing explanations too — state that survives, attention that stops carrying cargo — and the coming chapters develop them properly. This chapter's claim sits underneath them rather than competing with them: the common root is affordance, and the first affordance is the medium of the thought itself.

One reconciliation, before someone quotes my own work at me. Chapter 5 opens Part II on our oldest published principle — text is the model's home turf — and there is no tension, because Python is text. Home turf was never English specifically; it is the training distribution, and the distribution is saturated with code. English and Python are two registers of text, suited to two kinds of thinking. For narrating a conclusion to a human, English is native. For working a procedural problem, the native register has def statements in it.

And one fence, to keep the lanes clean. Chapter 6 argues about the tool surface — catalogue versus kernel, what the model touches. That is a different claim, and it comes with counted turns and measured tokens. This chapter sits one level before it: what the model thinks in. Nothing here depends on that count. If every tool call were free, the translation at the boundary of thought would still be the wrong place to put one.

Which raises the next question in line. A thought in English evaporates into transcript. A thought in code is different in kind: it has state — variables, objects, structures that persist and can be picked up again. If the middle thinks in code, then its thoughts occupy memory — and it is worth asking, precisely, what kind of memory we have given the thing that thinks. That is the next chapter.

Every serious operating system since the mainframe era has segregated memory by permission. Pages you may read. Pages you may write. Pages you may execute — and, on any modern system, rarely the same pages you may write, because writable-and-executable is how machines get taken over. A kernel sits underneath enforcing the map, and most of what stands between an ordinary program and disaster is exactly that: a permission map, held by something the program cannot argue with.

The last chapter ended on a question: if the middle thinks in code, its thoughts occupy memory — so what kind of memory have we given the thing that thinks? Take the permission lens — the most battle-tested lens in systems engineering — and run it over the memory a conventional agent actually gets: the context window, transcript-shaped, as every mainstream harness ships it. The audit is short.

Read: compulsory. There is no read permission on a context window, because there is no choosing to read. Material in context is already eligible to alter the next thought — residence is reading. Everything in the window conditions every next token, wanted or unwanted, forever.

Write: denied. The window is append-only. The occupant cannot revise a thing it holds, cannot reorganise, cannot deduplicate, cannot delete. A wrong turn taken at step three sits in working memory for the rest of the run — still resident, still conditioning — and the only remedy the architecture offers is to append more text arguing with it.

Execute: denied. A plan written in the transcript is inert prose. For the occupant to act on its own thought, it must re-read the thought and re-utter it through another conversational turn. The thought never runs. It gets quoted.

Reclamation: someone else's. When the memory fills, a stop-the-world compaction pass runs — scheduled by token count, executed by the harness, on a policy the occupant neither wrote nor controls. It is garbage collection performed by a landlord, and a landlord has no liveness information: it collects by age and size, while the only party that knows which objects are actually live — the occupant — is not consulted.

You can see the write denial from the outside, because every long-running agent invents the same workaround: it writes notes-to-self on disk. Files named PLAN.md and NOTES.md are the tell — working memory refused writes, so memory got pushed out through the filesystem, the slowest interface the machine has, to be re-read and re-understood later by whatever survives compaction. That is a process swapping its own mind to disk because its RAM is read-only.

Write that down in page-table terms and a conventional agent's context is R-- memory with mandatory reads and an external collector. No operating system treats its humblest process this way. Imagine a program that could only ever append to its heap, was compelled to touch every byte of it on every instruction, could never jump into anything it had built, and had its pages reclaimed on a schedule by something that cannot see which of them matter.

We would call that machine unprogrammable. We have been calling it an agent.

The record and the workbench

Before condemning the design, understand it, because every one of those restrictions was correct for the artefact's original job. A transcript is a record of a conversation, kept for a human reader. A record must be append-only; a record you can rewrite is worthless as a record. A record must be inert; a record that executes is a horror nobody would ship. A record should be reclaimed by retention policy, without asking the parties it describes. As a record, the context window is honest engineering.

The error was quieter, and it is this book's recurring species of error: we made the record double as the working memory, because there was nowhere else to put the working memory. Those are two artefacts with incompatible permission requirements. A record wants immutability, completeness, provenance. A workbench wants mutation, reorganisation, disposal. We gave one artefact both jobs, and the record's permissions won — the record came first, and the reader it served was human.

The category change

Now name the change the same way, in permissions, because that is what makes it a category rather than a feature list.

Working memory the occupant may write: reorganised mid-task, revised when a belief dies, discarded when a branch closes. Working memory that is executable: a thought can be code, and it can run, in place, in the same address space as the material it is about — the occupant executing within its own memory rather than narrating intentions across a boundary. And reclamation done by the occupant: collection by reachability from the current intent, decided by the only party that knows what is still load-bearing, instead of by age when the landlord's meter fills.

In operating-system terms: read, write and execute on the same pages, with the occupant running its own garbage collector. Anyone with a systems background will feel their skin crawl at that sentence, because we spent decades learning why writable-and-executable memory is dangerous and why WˆX exists. That instinct is correct, and it is why protection moved rather than vanished — who holds the permission map, and what can never be redrawn by reasoning, now lives at a hard boundary outside the middle, which is Chapter 13's argument to make and this sentence's only job to point at.

Two more fences, so this chapter stays what it is. What the occupant does with these permissions — how it pages, what it tiers where, what survives the process — is mechanism, and Chapter 8 owns it. This chapter exists so that when you reach the sentence "the model becomes its own memory manager," you hear a memory architecture changing category, and hear it precisely. And none of this is speculative: systems running exactly this permission model have shipped, and Part III reads one under glass, entirely from its published documentation.

That completes Part I, and it is worth taking stock of what is now on the table. The operator changed. The doctrine says the middle belongs to the machine and the boundaries to us. The middle's native language is closer to code than to English. And its memory, properly built, is memory — readable, writable, executable, collected by its occupant. What remains is to show that all of this is one design move, made three times at three layers — and the demonstration starts where everyone already agrees.

Of the three layers this book claims are the same design move, one is already won. Nobody needs persuading that a language model is happier with words than with a picture of words. The principle has a name in our corpus and it has been true since the first multimodal release: text is the model's home turf.

The sharp version of that claim is more interesting than the soft one. A language model reads mangled, overlapping, badly-kerned text perfectly — which is exactly why it is the wrong instrument for telling you that a rendered card is broken. Its strength at recovering meaning from a mess is precisely what makes it blind to the mess. Ask it to judge a layout and it will read the layout's intent and report success.

Start here because in this layer the human interface was visibly in the way. You could see the model squinting. In execution and in memory, the human interface is invisible, because it looks like good engineering — and that is the whole difficulty of the next two chapters.

The worked case: making a working session legible

Take a task with no domain in it: make a forty-minute screen recording of a working session legible to an agent. A terminal, an editor, a browser tab, and a person narrating over the top.

Before — render it for eyes, then ask a model to look

Sample frames at some interval. Send them to a vision model. Ask what happened.

What the operator actually receives is an image encoding of text: font rendering, anti-aliasing, a scroll position, a blinking cursor, a half-occluded pane. It receives, in other words, a lossy picture of something that was originally characters.

The costs stack in a specific and unpleasant way. A large token spend per frame, on pixels whose entire payload is words. A task the training distribution covers thinly compared to the equivalent text task. And a failure mode that is worse than noise: not random error, but confident transcription of something adjacent — the plausible misread, which looks exactly like a correct read to everything downstream.

The tell that you are living in the "before" is what your evaluation is about. If you are measuring whether the system saw correctly rather than what it concluded, your representation is doing the work your model should be doing.

After — recover the text, then reason

Four steps, none of them clever:

1. Sample and deduplicate screen states deterministically. Most frames are the previous frame; a hash comparison removes the vast majority before any model sees anything.
2. Recover the words with OCR — a narrow, testable, deterministic component with a known error profile.
3. Reserve exactly one bounded model judgment for the thing a model is actually good at: is this block content, or is it chrome?
4. Interleave the resulting screen blocks with the speech transcript, in time order, as structured text.

Now the operator receives a text problem, at full fidelity, in its native medium — and, as a bonus that turns out to matter more than the accuracy, a representation you can diff, cache, replay and test.

Watch the cost profile invert. The "before" gets more expensive as fidelity rises: more frames, more tokens, more spend. The "after" gets cheaper as you deduplicate harder. Cheaper and more accurate at the same time almost never happens in engineering, and when it does, it is the tell that a representation was wrong rather than a model being weak.

When should you keep the pixels?

This is the part that gets dropped when the principle turns into a slogan, and dropping it will get you into trouble in exactly the same way the original error did.

That discipline matters more than it looks here, because the next two chapters make analogous moves and each needs the same guard. The machine-native option is not automatically right. It is right when the consumer is a machine and the payload survives the translation.

Why this layer was easy, and the others were not

Three reasons, and all three are absent from the next two chapters.

The interface was visible. Anyone could watch a model fail on a screenshot and understand why. Nobody's professional identity was attached to sending screenshots — there was no architecture review that had blessed the pixel pipeline, no vendor selling it, no governance document describing it as a control. And the alternative was cheap and testable, with an obvious test: does the recovered text match the screen?

Now compare. In the execution layer, the human interface is a tool catalogue — which looks like architecture, reviews well, and feels safe. In the memory layer, it is a transcript — which looks like an audit trail, and in many organisations is treated as one. Neither announces itself as a human-interface assumption. Both have institutional defenders. That is why they lasted, and it is why the next two chapters have to work harder than this one.

The sentence the next two chapters spend

Underneath the specific advice about pixels is a general one, and this is the sentence Part II exists to prove three times:

Don't translate the world into the representation humans happen to use. Translate it into the representation the acting intelligence has the highest affordance over.

For perception, that meant pixels → structured text. For tools, it means a human-shaped catalogue → a programmable environment. For long-running cognition, it means a chat transcript → persistent computational state plus recursive inference. Same design move, three altitudes — and Chapter 7 assembles the consolidated table once the third one has been argued.

One methodological note before moving on, because this chapter's "after" is a good example of it: the design above uses deterministic code for ground truth and the model for judgment, and it moves the boundary between them when the evidence says so. That discipline is published elsewhere and this book will not re-teach it — but every machine-native design in the next two chapters obeys it, and any that does not should be treated with suspicion.

The obvious objection to all of this is that modern multimodal models can simply look at the screen. They can. That is a capability answer to an affordance question — and it costs more while telling you less.

The natural language in that loop was never a capability decision. It was there because we designed the interface to be inspectable and comfortable for ourselves, which was the right call when nobody trusted any of it and every action needed a human's eye.

One task, walked twice

Take something deliberately mundane: find every pending order over $1,000 for one customer, summarise them, and attach the summary to a record in another system. No domain expertise required, no clever prompt, nothing that flatters either architecture.

Before — catalogue and turn

Count the turns as they go past. The count is the argument.

1. The tool catalogue is already resident. That budget is spent before the request is read.
2. Turn 1: call getCustomer(id). The customer object returns into context.
3. Turn 2: call listOrders(customerId). Four hundred rows return into context.
4. Turn 3: the model filters in its own head, in prose, and states which ones it wants — an operation a for loop performs exactly and attention performs approximately.
5. Turn 4: call getOrderDetail for each survivor. Or, if the API is unkind, one call per order.
6. Turn 5: compose the summary.
7. Turn 6: call updateRecord(...).

Three costs, and it is worth naming them precisely rather than gesturing at "inefficiency".

Attention. Every intermediate payload occupies the inference field and competes with the reasoning. Four hundred rows of order data are not neutral cargo; they are four hundred rows of distraction sitting next to the thinking.

Latency and cost. Each turn is a round trip, and each round trip re-sends the accumulated history as input. The bill grows super-linearly in the number of steps, and the steps are decided by an architecture rather than by the problem.

Exposure. Four hundred rows of customer data passed through the model because the architecture had nowhere else to put them. Not because anyone decided the model should see them.

One slice of that cost has been measured publicly: presenting tools as code on a filesystem and loading definitions on demand cut an illustrated context load from roughly 150,000 tokens to about 2,000 — a 98.7% saving in that example.³ Use the number once and then let it go; the philosophy underneath is worth more than the percentage.

After — kernel

One turn. The four hundred rows never enter the field. What returns is the decision-relevant signal, which is the only thing the reasoning ever needed.

The point is not brevity — anyone can write shorter code. The point is where the data lived while it was being worked on, and who had to hold it.

That "after" is Code-First Architecture, which is published doctrine and not this book's contribution. Its five components — progressive disclosure, signal extraction, control flow in code, privacy-preserving operations, and state persistence with skills — are developed properly in the source and will not be re-derived here. The philosophy in one line: capability composed after contact with the problem beats a pre-declared ontology.

The rung above: code as a step inside cognition

Here is where this chapter departs from a Code-First recap, and it is the most important section in Part II.

Code-First moved orchestration into code: the operator writes code that calls tools and processes results. The output of that code is a value.

The agent-native move is code as a step inside cognition: the output of the code is a change in the shape of the next act of thinking.

A worked micro-example, in the same domain-free register. The operator does not know whether a discrepancy in a dataset is systemic or a sampling artefact. So it writes a function that partitions the data six ways, dispatches one child inference per partition, and keeps the six verdicts as objects. Four agree; two do not. It then writes a second function targeting only the disagreement, dispatches again, and reads the result against the first four.

No human designed that control flow. No fixed pipeline contained it. And the second function only exists because the first six results made it worth writing — which is what it means for code to be a step inside cognition rather than a step beside it.

The observation itself is not new: code as the step between model runs, where the agent emits a program whose job is to organise the next several model calls, has been named before. What is new is placing that step inside a runtime where the program's state persists — which is Chapter 7's subject, and the reason these two chapters are adjacent.

Four objections, answered

The interface must match the capability. Models have seen millions of code examples and thousands of synthetic tool schemas — asking for the second is asking them to work in a dialect they barely speak.

"Please invoke the customer lookup tool with ID 123" is not an interface. It is a human politeness convention, being billed by the token.

Then it compacts, and you watch it reorient on the project. I know I was working on something — what was I doing again? What were the files? Right in the middle of my run. It does a reasonable job of recovering, but it dropped the ball, and now it has to backtrack into what it was supposed to be doing. Ridiculous.

Refuse the polite framing. That is not a UX event. It is a cognitive discontinuity, scheduled by the architecture — and it happens at the least convenient possible moment, which is whenever the run has accumulated enough understanding to be worth interrupting.

What the incumbent architecture actually is

Here is the shape, described by people building the alternative, and it is unkind because it is accurate:

"Claude Code, OpenAI's Codex, and similar TUI systems tend to use file-systems and context compression by LLM summarization at regular intervals as the basis of their scaffolding. This effectively leads to a succession of agents, all connected to each other by a prompt and the state of some set of files."

The cost has a name worth using, because naming it makes it budgetable: handoff tax, paid at every seam, in the currency of orientation.

Is this just one operator complaining?

No, and it is worth checking rather than asserting. There is an open feature request against Codex describing the same shape from an entirely different direction:

"During goal runs, a new iteration is often started when most of the context window is already filled. The agent then proceeds to read additional files anyway, triggering compaction during the process. This can waste the work done in that iteration, because the agent may effectively have to start over after compaction."

Weigh that correctly: it is a feature request opened in May 2026, not a study.⁴ Its evidentiary value is not that the effect is measured — it is that the shape is independently observed by someone with no stake in this argument. And note where the same issue reaches next, unprompted: toward partial compaction, where the agent decides which parts of the context to preserve and which are no longer needed. That is a field asking for a model-controlled pager without quite naming one.

One twelve-hour job, two architectures

Keep the job generic: a long data-consolidation run over unfamiliar archives, where the operator must build readers, discover schemas, and reconcile sources as it goes.

Before — transcript and summary

What survives that loop is the files. What does not survive is the understanding of why those files exist, the approaches that were tried and abandoned, and the half-formed hypothesis about why source three disagrees with source one.

The second-order cost is the one that hurts. The successor is not merely slower; it is differently wrong. It re-tries a path its predecessor had already ruled out, because ruling-out is reasoning and the summary kept conclusions.

After — the prose compacts, the computation survives

Run the same job under an architecture where working state is addressable and outlives compaction. Variables, parsed structures, generated functions and child handles persist; the transcript is compacted around them. One shipped system documents exactly this property: "Python state survives across tool calls and compaction. Variables, imports, functions, parsed results, and task handles remain available on later turns."⁵

Now walk the same seam. Compaction fires. The prose compresses. And the operator's next act reads a variable rather than re-reading a notes file. The rejected path is still an object. The half-formed hypothesis is still a string in a list called open_questions. Nothing had to be reconstructed, because nothing was destroyed.

Which changes what summarisation is for:

The summary no longer has to be the memory. It only has to restore orientation.

Do not skip that last row. It is the honest one, it is new, and Chapter 16 collects it with the rest.

The same move, three times

All three layers have now been argued, so the table can be assembled once.

Same design move, three altitudes. Each row strips one assumption about the operator being a person — and the third row strips the one nobody noticed, because a transcript looks like an audit trail rather than a memory architecture.

What this does not fix

Persistent state does not abolish long-horizon failure. An operator with a live heap can still pursue a wrong branch, construct bad state, over-delegate to children that lose the parent's intent, or carry a stale object with total confidence. Those are real, and some of them are worse than what they replace precisely because they are silent.

What it removes is one specific, stupid failure: an architecture that deliberately lobotomises the worker on a schedule and then pays it to reconstruct itself.

Nor does it remove the need for durable external state — a heap dies with its process, and Chapter 8 meets that contradiction head-on rather than hoping you did not notice it.

And a note on the evidence, because it cuts the right way: the implementers of the persistent-state approach say themselves that their scaffold "doesn't necessarily improve baseline on all benchmark," and stress that their ablations are "not a measurement of any model's absolute performance on any benchmark."⁶ A source that publishes its null results is worth more, not less — and a book leaning on that source should quote both halves.

An architecture that reliably destroys the working gestalt mid-run and then bills for the reconstruction is not a memory strategy. It is a scheduled outage nobody logged. We spent two years trying to improve compaction quality when the actual fix was to stop asking prose to carry state.

A long-running personal-data ETL agent. More than twelve hours in a single run. Its instruction was to build its own tools as it went, and it did — readers for one archive format after another, a landing layer in Postgres, search and embeddings over the result, source-specific evidence paths so that any answer could be traced back.

In the operator's own words: "It did a ton of work, and it left a pile of tools behind for the next run. It also took many, many hours, and none of it was efficient."

Give it full credit before criticising it. This is not a cautionary tale about a badly built system. It is the best available version of the previous architecture, and it worked.

What was right about it

What that run was doing has a name: Runtime Capability Synthesis. Encounter an unknown artefact, identify the format, manufacture the missing capability, execute it against the real thing, observe failure at a previously unknown boundary, re-engineer, continue the original mission.

The consequential property is that capability acquisition became a step inside the workflow rather than a wall the workflow ran into. Classic extract-transform-load dies the moment there is no connector. This one wrote the connector and kept going.

The agent-native version does not replace that. It relocates it.

What it cost

Now the archaeology beat, because this is where the tax is actually paid. The next turn opens on a directory containing a dozen scripts, a landing schema, a notes file and an evidence directory. It has to answer a question no file tree can answer: apparently past-me built seven organs — what are they for, which are current, and which one was abandoned halfway through?

Three things a file tree cannot tell you:

• • Why each tool exists — the obstruction that caused it, which is the only thing that makes its shape sensible.
• • What was tried and rejected — the approach that looked right and failed at hour four, and is therefore the approach the successor will now try again.
• • What is stale — which of these was superseded and left in place rather than deleted, because deleting things mid-run is how you lose an afternoon.

The cost is not the reading time. It is orientation latency: the time to re-form the working gestalt, plus every error made before it re-forms.

Beside the agent, or inside the cognition?

That last bullet is not a footnote. "Inside" is not free, and pretending otherwise is how teams lose a night's work. Hold it; it comes back at the end of this chapter as the sharpest objection to everything in it.

Two kinds of cognition

Ambient cognition. The information is resident in the inference field and silently conditions every next token. It is not fetched; it is already eligible to change what gets noticed.

Addressable cognition. The information is an object the operator can inspect, slice, transform, and pass into another act of inference. It costs nothing while it sits there, and it can be brought into the field selectively, at the moment it matters.

That second mode is what is new, and it is the whole chapter.

What the operator can now decide, per item, is the actual capability — and it is worth spelling out rather than listing, because each option has a different cost. Something can stay ambient in the field, paying attention rent for conditioning value. It can become a variable, costing nothing until addressed. It can become a function, which is a variable that also encodes a procedure. It can be written to a file, surviving the process at the cost of needing to be re-understood. It can be delegated into a child context, where the reasoning happens somewhere else and only the verdict returns. It can be distilled into a durable skill. Or it can simply die, which is the correct answer more often than teams expect.

That is closer to a semantic garbage collector than to a summarisation routine.

The published mechanism behind it is precise: the prompt is treated as part of an external environment, and the root model receives only constant-sized metadata about it — its length, a short preview — then writes code to examine, decompose and recursively call itself over selected pieces.⁹

Four tiers, four clocks

The interesting property of that table is what it looked like eighteen months ago. In practice, only rows one and four existed. Row two was a transcript pretending to be state. Row three was a prompt file that somebody edited occasionally and nobody versioned.

Row three is now where an entire research direction has landed independently. The Continual Harness work defines harness state as prompt, sub-agents, skills and memory, and has the agent alternate between acting and refining that state online, within a single run — where prompt-optimisation methods require episode resets, this adapts without them.¹⁰ Starting from a bare interface with no curated knowledge and no hand-crafted tools, the authors report that it "substantially reduces button-press cost relative to the minimalist baseline and recovers a majority of the gap to a hand-engineered expert harness."¹⁰ That is the shape the paper reports, and this book will not manufacture a percentage it did not give.

The claim underneath that row is one we have made before and will not re-argue: learning that lands in legible, editable, ownable scaffolding rather than in weights is a genuinely different class of learning.

What exactly is new here?

Our own published correction on long-context discipline was "Do not trim the history. Compile the state" — keep the full walk log, keep an explicit task-world state, and keep the active field as three distinct things, because a summary keeps the conclusions and throws away the reasoning that earned them.

That was right, and it is not what this chapter is claiming. In that formulation the compiler was the human architect, writing deterministic code ahead of time to decide what survives. Here, the compaction architecture is written at runtime, by the operator, in code, while it is thinking.

Why that is a category change rather than an optimisation: the policy can now be task-shaped. What deserves residence in hour nine of a reconciliation job is not what deserved it in hour one, and no policy written in advance can know that. A human architect writing a compaction rule is guessing about a run that has not happened yet. An operator writing one at hour nine is describing a run it is inside.

But state inside the agent evaporates

Now the objection that could sink the chapter, and it is one I published myself.

"State inside the agent evaporates. State outside it compounds."

A kernel heap is state inside. On its face, this chapter is arguing against a position I have argued in print, complete with three tests: can a fresh agent resume from it without the transcript (cold-successor), does it survive the process being killed at an arbitrary moment (kill), and can something that is not the producer read it (foreign-reader)?

The resolution is a tiering claim, not a reversal.

And the failure mode that follows, named now rather than discovered later: a team that treats the heap as durable and finds out at process death that nothing passed the foreign-reader test. Chapter 16 collects it with the others.

Three more objections

"This is just a bigger context window." It is the opposite. The point is that everything important stays addressable without everything staying token-resident — which is what makes it scale past the window rather than into it.

"So memory is solved." No. It relocates the hard problem from what to keep to what to keep addressable, at which tier. That is a better problem, not an absent one.

"Doesn't this move context rot into the heap?" A fair challenge. A wrong object carried confidently is a real failure, and it is more silent than a bloated context, because nothing degrades visibly — there is no gradual haze to notice. This is precisely why the boundary artefact in Chapter 12 has new state as one of its fields.

The summary was never the memory. We only made it carry memory because there was nowhere else to put it — and then spent two years improving the compaction prompt, which is a fix at the wrong layer and good evidence of how invisible the assumption was.

Everything in Part II is a design argument, and design arguments are free. The question a sceptic is entitled to ask at this point is simple: has anybody actually built the middle you are describing, and does its documentation say what you claim it says?

One answer is Prime Intellect's Prime Agent — open source under the MIT licence, with published architecture documentation. Everything in this chapter is quoted from material anyone can read.

Five documented facts, and what each one means

1. One model-facing tool. "Prime Agent is built around a recursive language model (RLM) runtime: the model works inside a persistent Python control environment and composes capabilities as code."⁵ The default runtime exposes exactly one built-in model tool: ipython. File operations, shell commands, skill use and delegation all begin there.

Architecturally: the catalogue is not shortened. It is gone, replaced by a language.

2. State that outlives the turn. "Python state survives across tool calls and compaction. Variables, imports, functions, parsed results, and task handles remain available on later turns."⁵

Architecturally: row two of the four-tier table in Chapter 8 exists in a shipped product rather than in a diagram.

3. Recursion as an ordinary call. rlm(...) spawns a real child session with an independent context and session directory. The call "returns immediately after task admission with a child handle; it never waits for or returns the child's answer" — results arrive through explicit messages or files. And the child registry "survives compaction, kernel restart, and parent restoration."⁵

Architecturally: this is a process tree, not a call stack. Children are independently addressable and outlive the turn that spawned them, which is a different thing from a sub-agent call that blocks and returns a string.

4. A parent that stays focused. "The parent keeps its own context focused while Python holds working state and child agents receive only the context needed for their subtasks."⁵

Architecturally: attention is allocated deliberately rather than accumulated by default. That single sentence is the difference between a context window and a memory hierarchy.

5. A hard boundary underneath. "Provider calls, session persistence, child lifecycles, scheduling, and safety policy remain in the TypeScript host; IPython is the model-facing programming surface."⁵ Python asks for authoritative operations through typed host requests, which keeps "credentials, provider execution, transcript writes, worker routing, and scheduling out of Python."

Architecturally: a syscall boundary in everything but name — and the setup for Chapter 13.

The syscall reading

Inside that space there is no strong conceptual boundary between "this is my data" and "this is an executable procedure for thinking about my data." A result becomes a variable. A thought causes a function to be written. The function launches another reasoning process. Its result becomes another object. That object changes the next thought.

Code and cognition have become mutually compilable.

And the correction the documentation itself supplies, before anyone else has to: the kernel "runs model-generated Python and project commands with the worker's operating-system permissions. It is a durable control environment, not a security sandbox."⁵ The architecture overview says the same about process separation: workers and kernels are separate "for lifecycle and failure containment, not security sandboxes."¹¹ Note it now; Chapter 13 resolves it.

The computer analogy — a metaphor, not an equivalence

Before the table, the caveat, because the table is seductive: what follows is offered as an architecture metaphor. It is there to relocate your intuitions, not to assert an isomorphism.

Four rows are worth pausing on. Heap changes what you think memory management means: not eviction from a window, but allocation across tiers. Process tree changes what delegation means: not a function that returns a string, but independent workers that outlive the call. CPU changes what a model release means: an upgrade to one component of a machine you designed. And program changes what a prompt is: not an instruction but the thing being executed, which is why its quality dominates everything downstream.

Then the row that matters most, because it is the row no ordinary computer needs. A CPU owes nobody an explanation. This runtime does, because a human still forms the intent and still owns the consequence. That row is Chapter 12, and its presence in this table is the single strongest argument that the analogy is a lens rather than a law.

Where the metaphor breaks, said plainly so it cannot be over-read: this CPU is probabilistic; this heap contains meaning rather than bytes; and this program can rewrite itself mid-execution in a way no ordinary program is permitted to. The mapping relocates intuitions. It does not license them.

Why did this slip past everyone?

Because the visible product category is entirely familiar: terminal UI, model selector, sessions, diffs, approvals, repo navigation, status displays. People compare it to other terminals, and terminals are a solved and boring problem.

And because a polished terminal shell is now cheap. There is a great deal of high-quality prior art, some of it permissively licensed, and code generation makes reconstructing the patterns you want extraordinarily cheap. So the scarce invention budget goes somewhere else.

Strip this chapter out

Now the altitude guard, and it belongs on the page rather than in a plan.

Delete this chapter and Part II still stands. The three-layer argument is a design claim about operators and affordances; it does not depend on any particular system existing. The specimen is here because a design argument with nothing shipped in it is a hypothesis, and this one has a documentation trail you can check.

The reverse also holds, and it is the more important half: nothing in the general claim depends on this system being good, surviving, or winning. If it were withdrawn tomorrow, the three-layer argument would be exactly as true, and the next specimen would arrive.

Nor is it alone. The next chapter's leaderboard shows a dozen independent teams building the same middle without coordinating — executable world models in code, addressable state across a run, hypotheses verified against recorded history. That convergence is worth more than any single system's documentation.

People are comparing the wrong layer. The interesting claim was never "a better coding agent." It is "a different machine-facing cognitive runtime" — and judging that class of system by its terminal is like judging a compiler by its progress bar.

The claim, as it travels: a new harness took roughly the same model from about 30% to about 95% on ARC-AGI-3.

It is a wonderful number and I am not going to use it, because it is three different numbers with three different provenances, and merging them would be precisely the sloppiness this book is arguing against.

A book claiming the harness is under-measured cannot afford a headline figure it has not checked. The discipline is the argument's collateral. And the honest origin of that discipline is worth stating: I once had this exact claim corrected out from under me by someone confidently citing the wrong benchmark. You know what I hate? When you correct me — and you're wrong. The cure for that on both sides is provenance, attached at the point of use.

The three numbers, separated

The verified row is straightforward: "As of July 24, 2026, Claude Opus 5 (High) is the highest-performing model on ARC-AGI-3, scoring 30.2%."¹²

The second row needs its governing caveat, quoted, because without it the row is meaningless:

"Scores are self-reported unless noted otherwise. Results on the ARC-AGI-1 and ARC-AGI-2 semi-private sets are run and verified by ARC Prize. Everything else is scored on a public set and self-reported."

Three distinct things differ across those rows, and "provenance" is doing a lot of work as a single word. Who ran it — ARC, or the submitter. Which set — verified evaluation, or public demo. And what the entry even is — a model evaluation, or a harness submission. Those are not degrees of confidence in one measurement. They are three different measurements.

Row two deserves a sentence of its own, because it is the easiest thing in this chapter to misread. The 95.3% entry is not a human score. It is ARC Prize's own harness, described in their words as maximum human intelligence built into an agent harness — which makes it simultaneously the most on-the-nose evidence in this chapter and the row most likely to be quoted wrongly.

Why the honest version is stronger

The dishonest version hands you one impressive delta that a sceptic can dismantle in a sentence: different sets, different protocols, not comparable. Done.

The honest version hands you a spread, which is much harder to explain away — and the spread is sitting in public, on one leaderboard, on one benchmark, on one set.

The leaderboard is the argument

Same benchmark. Same public demo set. Broadly comparable frontier model classes. Wildly different harnesses. Every description below is the leaderboard's own.¹³

Reported costs on those entries range from $115 to $18,000, which forecloses the lazy reading that the top of the board is simply whoever spent the most: the $332 entry outscores the $5,300 one by a factor of seven.¹³

Read the middle column, not the scores

This is why the table is worth the space. Read down the descriptions and the high scorers converge on three properties, arrived at independently by teams who were not coordinating and were trying to win a benchmark rather than prove an architecture thesis:

1. Build an executable model of the world in code, rather than reasoning about the world in prose.
2. Keep state addressable across the run — logs of every frame, persisted knowledge files, learning carried between levels.
3. Verify hypotheses against recorded history before spending live actions — retrodiction, adversarial testing, falsification.

That is the machine-native middle, described in a leaderboard's own words. Note what is not the differentiator: not one of those descriptions is about a better prompt, and not one is about a bigger model.

But isn't this just harness overfitting?

Concede it first, without hedging, because the suspicion is correct. A harness built against twenty-five known environments can encode assumptions that will not travel. ARC's own leaderboard rules require submissions to be "general purpose and reproducible" precisely because this is a live risk. If your reaction to the top of that table is suspicion, you are reading it correctly.

Then three answers.

One. Overfitting explains a peak. It does not explain a range from 5.2% to 100% on the same task family. The low entries were built by capable teams who were also trying to win.

Two. It does not explain a frontier lab finding roughly three times the score on its own model by enabling two settings it already ships in production. Nothing there was tuned to the benchmark; something was un-broken.

Three. The controlled results in the next chapter do not use this benchmark at all. If ARC-AGI-3 vanished tomorrow, this argument would be down one illustration and no evidence.

What this chapter will not do is mount a methodology defence. The leaderboard is directional evidence, offered as direction.

Why this benchmark, specifically

ARC-AGI-3 is "an interactive reasoning benchmark which challenges AI agents to explore novel environments, acquire goals on the fly, build adaptable world models, and learn continuously" — testing "intelligence across time, not just final answers — capturing planning horizons, memory compression, and the ability to update beliefs as new evidence appears."¹⁴

Now read that list as an architect rather than as a researcher. Every property in it is a property of a system over time — and every one of them is exactly what a harness supplies or destroys. Memory compression is the harness. Planning horizon is the harness. Belief updating across a run is the harness.

Which produces the consequence worth stating once and plainly: on a benchmark like this, "the model scored X" is close to a category error unless the harness is disclosed alongside it.

Reporting an agentic benchmark score without its harness is like reporting a lap time without saying which car.

Every number in this book is a cited public figure or it does not appear. Where a source lacked a number, the shape got written instead. That is not editorial fussiness — it is the only thing that makes the next chapter worth reading.

Almost everything in this field is confounded. A better score on a new leaderboard could be a better model, a different evaluation set, a different prompt, a different day. The only readings that survive scrutiny are the ones where somebody held the model and changed one thing.

There are three such readings in public, from three unrelated groups, on three different tasks. That is this chapter.

Control 1 — a lab, on its own model

Setup. ARC-AGI-3, public task set, GPT‑5.6 Sol. The official harness versus the same model run through the lab's own API with two settings enabled: retained reasoning, and compaction.

Result. 13.3% to 38.3%, with roughly six times fewer output tokens.¹

Why it is a strong control. Nothing was tuned for the benchmark. The two settings were already standard in the lab's shipped products; the harness was brought closer to production, not further from it. That is the opposite of the overfitting story.

What was actually being fixed is the interesting part, and it is the diagnosis from Chapter 1: private reasoning discarded after every action, so the model "was asked to figure out the game anew, unable to remember its past thinking"; and a rolling truncation window, so "it was losing memory of its past actions too."¹

What it does not establish. Transfer to other tasks. That 3× is a general magnitude. Or that ARC was wrong to use a generic harness — their stated reason is that a simple harness makes model shortcomings visible and comparisons fair, which is a coherent position honestly held.

Control 2 — the RLM paper

Setup. GPT-5 held as the underlying model. A recursive scaffold — the prompt treated as an external environment inside a persistent REPL — compared against common long-context and coding scaffolds, across four long-context tasks, at comparable cost.

Result. Median improvements across the evaluated benchmarks of 26% against compaction, 130% against CodeAct with sub-calls, and 13% against Claude Code.⁹ The same work also post-trains a small model around the scaffold: RLM-Qwen3-8B outperforms its own base model by 28.3% on average.⁹

Why it is a strong control. The model family is fixed and the comparison is against real scaffolds people actually use, not a strawman built to lose.

What it does not establish. That the gains hold outside long-context work. The paper's own frame is inference-time scaling for long prompts, and it should be read inside that frame.

Control 3 — Recursive Agent Harnesses

Setup. Researchers at PricewaterhouseCoopers, making the recursive unit a full agent harness — filesystem tools, code execution, planning — rather than a bare model call. GPT-5 held fixed specifically to match published baselines.

Result, in their own words:

"With the backbone held fixed at GPT-5 to match the published Codex and RLM baselines, RAH improves the Codex coding-agent baseline from 71.75% to 81.36% on Oolong-Synthetic (199 samples, 13 context-length buckets up to 4M tokens), a gain attributable to the harness rather than the model."

With a stronger backbone, the same design reaches 89.77%¹⁶ — which is the multiplicative claim showing up as data rather than assertion. Better model and better harness, both moving the product.

One mechanism note, because it is Chapter 6's rung-above arriving independently: the parent generates and runs a script that spawns subagent harnesses in parallel, and receives only the aggregated output. The children's intermediate reasoning never enters the parent's context at all.¹⁶

Reading the three together

Be precise about what that is. Three different tasks, three different metrics, three different teams. It is convergence, not replication. Nobody has run the same experiment twice.

What convergence buys you is strong evidence of a mechanism: that a substantial share of observed agentic capability is supplied by the harness. What it does not buy you is a magnitude you can quote for your own workload. Anyone offering you one is selling something.

One operator's comparison — labelled as anecdote

Same underlying model, same repository, same read-only task — review this code and give me ideas — run through two harnesses. It ran longer. The output was materially different: more thorough, better reasoned, better ideas.

Label it honestly. n=1, unblinded, no rubric, no repeats. It is not evidence of a magnitude and it is not offered as any.

Its value is different. It shows the effect is visible without a lab — which is what makes the protocol below worth running rather than admiring. And it produced a reframe worth keeping: the wrong question is how many tokens did it burn? The right one is what did the extra cognition buy? Burn is only waste if the apparatus cannot send the extra cognition somewhere meaningfully different.

Run the experiment yourself

This is the chapter's actual takeaway. It is cheap, it is specifiable, and it is the only number that will bind for your workload.

Three objections

"Three results is not a literature." Correct. This is a mechanism argument supported by convergent public evidence, and it is presented as one. It is also falsifiable in a week on your own data, which is worth more than a fourth citation.

"The harness gains will be absorbed into the models." Probably, partly. One of these papers post-trains a model around the scaffold; another states its explicit aim as teaching models to manage their own context end to end.⁶ That does not weaken the claim; it relocates it. If harness behaviour becomes model behaviour, the unit being measured is still model-plus-harness. The seam just moved.

"Our tasks are short." Then the long-context results may not transfer, and the honest answer is: run the protocol and find out. The memory failure mode in Chapter 8 requires a run long enough to have a seam. If your work never compacts, that whole chapter is somebody else's problem.

Stop asking how many tokens it burned. Ask what the extra cognition bought.

With that evidence in hand, here is the belief this book is now entitled to state: the harness share of observed capability is large enough that your next architecture decision is worth more than your next model upgrade — and nothing in the vendor conversation is telling you that, because nobody sells it.

Watch it run and I don't even know what it's doing. Normally you can follow along. This is pretty much gobbledygook. When it finishes and hands me something to read, that's fine — I understand that. But its inner workings, its logging, mean nothing to me.

The instinct is to read that as a regression. It is not. It is the predictable consequence of the three moves in Part II — and the fact that almost nobody predicted it tells you how heavily we were relying on an accident.

Why the old trace was readable

With a conventional harness, a trace reads like this: I'll inspect package.json. I'll search for references. I'll open this file. I found X. I'll run the test. A colleague narrating their investigation.

The reason is mechanical, not stylistic. The unit of computation was a semantic agent turn. The operational grain and the human explanatory grain were the same size, so the execution log and the explanation of the execution happened to coincide.

Nobody designed that. We inherited it from a slow, coarse architecture — and then built review processes, team trust and, in some organisations, compliance narratives on top of it.

Why it stopped

Move the grain down — create object, slice object, map function, invoke child, return child result, transform state, branch, loop, execute — and the trace stops resembling narration and starts resembling a program running.

The honest name for what you are now watching is cognitive assembly language. Trying to understand the run by reading every kernel operation is like trying to understand a browser by staring at a CPU instruction trace. Both traces are complete. Neither is an explanation.

And this is the part to be careful about, because it is easily mistaken for a complaint: the trace can be perfectly useful for debugging while being completely useless as the human explanation. Those are two different artefacts, and we have been getting away with one because of a coincidence that has now ended.

Four things we have been treating as one

Correctness — the result is right. Verification — someone or something can establish independently that it is right. Comprehension — a human can reconstruct why it is right, well enough to disagree with it. Insight — the result changes what humans understand about the problem class.

Four properties, and until recently they arrived as a bundle, which is why we never needed the vocabulary. Now they come apart, and each separation has a characteristic smell:

• • Correct but unverified: a conclusion nobody can reproduce because the intermediate objects were discarded when the process ended. Common, and almost always invisible until someone asks.
• • Correct and verified but not comprehended: a machine-checked derivation whose steps a competent reviewer cannot hold in their head. This is the case that is about to become routine.
• • Comprehended but not insightful: you can follow every step and have learned nothing transferable. Every well-written status report.
• • All four: the default we grew up with, because the grain was human-sized. It is now an outcome you engineer.

The case where it happened in public

In May 2026, an OpenAI model disproved a longstanding conjecture in discrete geometry. Correctness was accepted readily. Tim Gowers, writing in the companion paper: if a human had submitted it to a top journal "and I had been asked for a quick opinion, I would have recommended acceptance without any hesitation."¹⁸

Comprehension was assessed separately. Thomas Bloom, in the same companion note: "has this taught us something new about the problem? Do we understand discrete geometry better now? I think the answer is a moderated yes."¹⁸

And the effort side, from Jacob Tsimerman: "It is definitely an intimidating construction to see through even if you know what is going on, and even harder to go play for yourself."¹⁸

Take from that exactly what is there. Not that machine output is incomprehensible — these people comprehended it. That correctness and comprehension became separately assessed properties, in public, by the experts best placed to notice the difference. That separation is what arrives in ordinary systems next, without the courtesy of a companion paper.

The wrong fix

The obvious response is to make the middle narrate itself in pleasant English at every operation. It fails twice.

It fails on capability: you are taxing the thing that made it good, spending tokens on an audience that is not there, and constraining the operational grain back to human concept size — which is exactly the assumption Part II removed.

It fails on honesty, and this is the worse one. Narration produced alongside execution is not a record of reasoning. It is a plausible story about reasoning, generated by the same process that did the reasoning, and it will be at its most fluent exactly when it is least reliable. A system that narrates for an audience is performing, and performances are not evidence.

Debug symbols for cognition

Compiled binaries ship with debug symbols so that a human can reason about a machine artefact they would never read directly. Nobody proposes making the binary readable. We ship a separate layer whose only job is to make the artefact discussable.

Cognition needs the same thing, emitted at boundaries. Not a prettier log — a different object.

Dwell on rejected paths, because it is the field that justifies the whole artefact. It is what stops the next act of cognition walking back down a road already ruled out — and it is precisely what prose compression removes first, because a summariser optimising for readability keeps conclusions and drops the failures that earned them. A summary that says "we established the discrepancy is systemic" is strictly less useful than one that says "we established it is systemic; the sampling-artefact hypothesis was tested against last quarter's export and failed; do not re-test it."

When to emit. At meaningful boundaries: a goal slice completing, a compaction seam, a delegation returning, an exception, a handover, and the final answer. Not per operation — per-operation emission is how you get back to narration.

Who it is for. The human forming the next intent — and the next act of cognition, which is frequently the more demanding reader, because it has no memory of the room and will believe whatever the artefact says.

The law underneath

The governing rule is one I have argued elsewhere and will not re-derive: as dense as you like — provided every handle expands on demand. Density inside a language, with receipts, is legitimate at any level — a mathematics paper is denser than any model output you will ever read, and entirely legitimate, because every symbol is defined somewhere reachable. What is illegitimate is opaque density, where a handle points to nothing you can get to. Opaque density is where audit dies.

Worth one further note, since it cuts against the reflex: output getting harder to read is not automatically a failure. It can be the tell that a system has moved above your current resolution, which is a different problem with a different fix.

Dense is fine. Opaque is not. The limiting interface between machine cognition and human judgment is decompressibility.

"If the trace is unreadable, the system is unauditable"

This is the serious objection, and it deserves three answers rather than a reassurance.

One. The trace was never the audit surface. It was a convenient stand-in that worked while the grain was human-sized, and treating a convenience as a control is how organisations end up with oversight that evaporates on a version upgrade.

Two. Auditability is a property of what you can reopen, not what you can skim. That is why evidence is a field, and why it holds pointers rather than copies. A pointer that still resolves in six months is worth more than a page of pasted excerpts.

Three. The boundary artefact is now something you build. The uncomfortable part is that it used to be free and now has a cost — which is a budget question, not a philosophical one.

And the follow-up objection, which is sharper: won't the operator just write flattering debug symbols? It might. The fields that resist flattery are the ones with external referents — artifacts that either exist or do not, evidence that either reopens or does not, rejected paths that can be spot-checked against the execution trace. Design your schema so that at least three fields are falsifiable against the plane below. A field that cannot be checked is a field that will drift.

Demanding that the middle narrate itself is asking the machine to cosplay as a human developer, and paying for the costume in capability. Comprehension has stopped being a by-product and become a deliverable — and most teams have not yet noticed that they no longer have one.

I was thinking about protected memory in an operating system. Normally you have memory you can execute and memory you can read and write, and the OS stops you doing the wrong thing in the wrong place. This does away with that. Everything's up for grabs — reading, writing, executing.

From inside the cognitive middle, that is very nearly accurate. There is no strong conceptual boundary between "this is my data" and "this is an executable procedure for thinking about my data." A result becomes a variable. A thought causes a function to be written. The function launches another reasoning process. Its result becomes an object. That object changes the next thought.

And then the correction that turns a hazard into a design: protection was not abolished. It moved outward.

Two pictures

The operator gets a permissive user space. It does not get ring 0.

Why that beats fine-grained internal fences, and this is worth arguing rather than asserting: internal fences degrade the cognition, because every fence is a constraint on what can be composed — and they do not hold anyway, because a fence made of instructions is a suggestion to a thing whose entire function is reasoning about instructions. One real boundary at the edge beats twenty imaginary ones inside.

Two protection problems that get collapsed

This is the most commonly conflated distinction in the whole area, and collapsing it is how teams ship something dangerous while feeling architectural.

An elegant answer to the first is not an answer to the second. The specimen from Chapter 9 says so in its own documentation: worker and kernel separation exists "for lifecycle and failure containment, not security sandboxes," and the kernel "runs model-generated Python and project commands with the worker's operating-system permissions."¹¹

Note what is admirable there: it is stated in the project's own README rather than left for users to discover. A boundary you have documented honestly is worth considerably more than one you have implied. And the practical consequence is one line: if the material is untrusted, containment is a separate layer and it is not optional. Cognitive architecture and containment are complementary, never substitutes.

The principle this inherits

Our own doctrine states the rule and I am citing it rather than rebuilding it: allocate access by predictability, not by intelligence. Your smartest component should be your least trusted. Or, as the applicable form: discretion and privilege should move in opposite directions. The creed that follows — the sensor sees but does not decide, the model reasons but does not touch, the human authorises and owns the consequence, the code makes only the authorised transition real — distributes the four verbs so that no single actor both sees the raw world and changes it.

And the arrangement that positions the model: a grounded worldview above it, authority infrastructure below it. "It is a hypothesis engine. It proposes. It does not own the world, and it does not own the gate."

None of that is new. Saltzer and Schroeder set out the underlying principles in 1975: least privilege — "every program and every user of the system should operate using the least set of privileges necessary to complete the job"; separation of privilege — two keys beat one; and complete mediation — "every access to every object must be checked for authority."¹⁹

What changes in an agent-native system is not the principle. It is the price of ignoring it. Those principles were written for exactly this condition: a component whose value comes from breadth of capability and whose behaviour cannot be predicted. Agent-Native Computing does not suspend them. It makes them the price of admission.

The rule, made operational

Three ambiguous cases, worked, because a test is only useful if you have seen it applied to something that was not obvious.

A budget limit expressed in the prompt. Inside. It is a sentence, and sentences are negotiable to a thing that reasons — not through malice, but because reasoning about constraints is what it does. Move the limit to the layer that counts tokens and refuses.

A read-only database credential. Outside, and the read-only-ness is the entire point. The boundary is the grant, not the intention. Nothing the operator thinks can turn a read-only credential into a write.

A "do not deploy to production" instruction. Inside, and therefore not a control. The control is the absence of a deploy credential in that process. If your production safety depends on a sentence, then a sufficiently determined chain of reasoning — or a sufficiently unusual input — is your threat model.

If your authority boundary is a prompt, you do not have one.

What this costs

A boundary is not free and a chapter that pretends otherwise is selling something.

It has to be maintained, and every new capability arrives as a question about which side it goes on. That is ongoing engineering work with no visible output, which makes it the first thing cut under pressure.

Some legitimate operations get slower, because they now require a mediated request rather than a direct action. Developers will feel that, and they will be right that it is friction.

There will be pressure to move things inside for convenience, and that pressure will be strongest at the moment the system is most useful — when it is close to solving something and the only obstacle is a permission. Name it now so it is recognisable when it arrives wearing the costume of pragmatism.

And a permissive middle raises the value of the containment layer for untrusted input, which is cost, not free capability.

"Letting a model run arbitrary code is reckless"

It is reckless precisely when the boundary is soft — and "we prompt it not to" is what a soft boundary looks like when it is described optimistically.

The alternative most teams actually run is not safer; it is differently unsafe. A tool catalogue whose twenty entries each carry real privilege distributes authority across twenty surfaces instead of concentrating it at one you can inspect, review and test. Twenty small holes are harder to audit than one door.

The question is not whether the operator can execute. It is whether execution can reach consequence without passing a gate that cannot be reasoned with.

And where step-level approval is genuinely required by a regulator or a customer, the answer is not to soften this chapter — it is to put the machine-native middle on the exploratory end of the pipeline and keep it out of the consequential path. Chapter 16 states that rule properly.

Hoping the model behaves is not a control. It is a wish with a budget line.

The metaphor the operator reached for first was a Swiss Army knife: "The old harness was a knife and fork — specific, limited jobs. This is a Swiss Army knife whose tools mutate as you work the problem. You start with a Phillips screwdriver and it turns into a security hex driver because the job changed. Then there are two of them, in two sizes."

That is nearly right, and the upgrade is worth making, because a Swiss Army knife still has a manufacturer-defined inventory. What is actually happening is closer to a machine shop that manufactures whichever tool the current workpiece requires, uses it, modifies it when the fit is wrong, and melts it back down when the job is over.

Which raises the practical question this chapter answers: which of the things that machine shop makes should survive the job?

Two lifecycles, and the failure mode at each extreme

Ephemeral. A problem is encountered; the operator manufactures a tool; uses it; the tool dies with the task.

Promoted. A pattern proves strategically reusable; it is deliberately moved into the durable substrate; later cognition inherits it.

The compiler framing makes the relationship exact: runtime-generated code is speculative optimisation, and the durable layer is where successful optimisations get promoted into the standard library.

Both are necessary, and the argument for that is easier to make from the failure modes than from the virtues.

Ephemeral: a disposable counterfactual world

Here is a case that shows what "ephemeral" is actually worth.

The requirement handed to the operator was an invariant, not an implementation: test the proposed policy changes against historical cases, but do not contaminate production state, and do not actually send anything.

What it built was an in-memory database standing in for the production store, combined with virtual time, blocked networking and recording-only outputs. Production logic, plus synthetic state, plus historical evidence, plus a simulated clock, plus inert outputs.

That is a better answer than it first appears, and the reason is worth drawing out. It creates a cheap, disposable counterfactual world. The application logic runs as though it has state, transitions, queues and prior observations — and when the process ends, the experimental world disappears. Compare that with the usual approach: a flag inside the production system. A flag can leak. A different reality cannot, because the dangerous consequence is not wired up at all.

And it should not be promoted. It encodes this experiment's assumptions. Next month's question needs a different world, and a preserved one would be a subtly wrong world wearing the authority of something that worked once.

The doctrine underneath is tight intent, loose method, hard verification — pointed at cognition itself. Nobody specified an in-memory database. They specified the acceptance boundaries, and the implementation was the operator's business.

Promoted: a capability that earned durability

The counter-case, and it gets one appearance, at the attention boundary only.

An AI-news alerting system, whose job is to decide what deserves to interrupt a human. A new class of object was judged strategically live, and the system's durable watch sources were changed accordingly — not as a one-off lookup during an investigation, but as a standing change to what the system will notice in future without being asked.

That is promotion rather than a bookmark. The distinction is whether the change affects runs that have not been imagined yet. A worldview changed its own sensory apparatus, which is a genuinely interesting closed loop — and it belongs to a different book. One paragraph, then away.

The promotion test

The wrong test is was it useful? Everything the operator built was useful once. That is why it was built.

Two disqualifiers, each with a concrete shape:

It encodes a fact that will rot. A parser hard-wired to this quarter's export format is a time bomb with a helpful name. It will work until it silently doesn't, and the failure will surface as a wrong answer rather than an error.

It duplicates something the substrate already has. Promotion is not free. A near-duplicate costs the next operator a choice it should not have to make, and choices between two similar tools are where the wrong one gets picked.

Two more questions worth asking, because these are the ones people skip in the enthusiasm of a good run:

Who owns it now? A promoted tool with no owner is a liability with a plausible name. Somebody has to be responsible for it working next quarter.

What tells you it is stale? If nothing does, you have promoted a future wrong answer and scheduled it for delivery at an unknown date.

The default should be strongly biased toward letting things die. Ephemeral machinery has no maintenance cost; durable machinery always does. Most machinery should evaporate.

Where this sits against the memory tiers

Chapter 8's four tiers make the geography obvious without redrawing them. Ephemeral machinery lives in tier two, the kernel. Promoted machinery lives in tier three, the durable substrate. Promotion is the act of moving something across that boundary — and it is the only movement in that table that should require a decision.

The asymmetry is what makes this cheap to get right: dying is the default and costs nothing; surviving is a decision and costs forever. Set the default correctly and the review burden collapses to the handful of things somebody actually argued for.

The asset was never the tool. The asset is what the tool made legible — and in the ephemeral case, the tool's death is a feature, because it stops a temporary answer acquiring the authority of a permanent one.

A repository of half-maintained agent-generated utilities is not a capability library. It is a landfill with a README.

The position has been on the record for a while, and it is worth restating exactly rather than paraphrasing:

Outcome capability ≈ model × goal quality × harness persistence × reality access × tool surface × tool synthesis. A zero on any factor collapses the product.

It came with a diagnosis attached: someone ships new weights into the same thin harness on the same barren machine and is surprised when the business outcome barely twitches. Additive thinking says more model, more result. Multiplicative thinking says: find the zero.

At the time, that could be read as a systems engineer insisting that architecture matters too — true, unfalsifiable, easy to nod at and ignore.

What 2026 added is that a multiplicative theory makes a prediction an additive one does not: hold one factor fixed, move another, and you should see large non-additive swings. That is now the observed result, three times, from unrelated groups, on different tasks — and the sharpest of them says it in the authors' own words: a gain attributable to the harness rather than the model.

The relocation

The compression that carries it:

The model is becoming the ISA. The harness is becoming the computer.

Handle that carefully, because it is the most quotable line in the book and therefore the easiest to over-read. An instruction set is a contract: it defines what operations exist and how they behave. A computer is what you get when you decide the memory hierarchy, the addressing, the process model, the scheduler and the I/O around it. Two machines with the same instruction set can differ by an order of magnitude in delivered performance, and nobody in computing finds that surprising or scandalous.

Where the analogy breaks, said plainly so nobody builds a strategy on it: an instruction set is a fixed contract and a model is not. Model behaviour drifts between releases, and harness features get absorbed into models over time. The mapping is a lens, not an identity.

What this does to a benchmark

A model benchmark increasingly tells you which CPU you bought. It does not tell you what computer you built.

Two organisations renting identical frontier capability can produce radically different outcomes, and the difference is not the weights. It is the machine those weights are running inside.

That lands two ways at once, and both are worth sitting with.

The uncomfortable corollary: your system's ceiling is partly your own design decision, and has been all along. That is not an accusation — almost everyone inherited these assumptions rather than choosing them. But it does mean the ceiling is not somebody else's problem.

The liberating corollary, in the same breath: the model is the component you rent, and everyone else can rent the same one. The harness is the part you own. It is also the part nobody is selling you, because there is no line item for it and no vendor whose quarter depends on you having one.

Two organisations, one model, different machines

Make that concrete, because "different outcomes" is the kind of phrase that slides past.

Two teams rent the same frontier model at the same tier. Both run a long analytical workload — reconciling a large evidence base and producing a defensible recommendation. Neither has a model advantage of any kind, and neither can get one.

Team A runs a tool catalogue. Intermediate results pass through the model. The transcript is the memory, and at roughly the two-hour mark a summariser compresses it. The team's improvement lever is the prompt, which they iterate on weekly, and the model tier, which they upgrade when a new one ships. Their run produces a competent answer, and re-running it next month produces a different competent answer for reasons nobody can reconstruct, because the reasoning that earned the first one was compressed away.

Team B runs a programmable middle. Bulk evidence stays out of the field; the operator composes over it in code. Working state survives compaction, so the two-hour mark is a seam rather than a scar. Delegation is a real call with independent contexts, so three lines of enquiry can run without contaminating each other. At the boundaries, the team gets an artefact with a goal, a state delta, the load-bearing discoveries, the rejected paths and pointers to evidence — so a reviewer can disagree with a specific step rather than accept or reject the whole thing.

Now ask which of those differences a model upgrade fixes. None of them. Every one is an architecture decision that was made — usually by default, usually by inheritance — before the model was chosen. And every one of them is available to Team A this quarter, at engineering cost rather than vendor cost.

That is what "the harness is the computer" means in a budget meeting. Not a metaphor about instruction sets: two teams, one rented CPU, and a delivered capability gap that no procurement decision closes.

What this does to evaluation practice

You are frequently the person quoting the number, so make this concrete.

Where should the marginal dollar go?

The default allocation today is: pay for the best model, and treat the harness as plumbing to be minimised. That was a reasonable default when harnesses were thin and roughly identical.

What the evidence suggests instead is that the marginal dollar frequently buys more in harness properties — retained reasoning, persistent state, delegation, an execution surface — than in the next model tier. Note the shape rather than a ratio: none of the public results licenses a number, and inventing one would undo Chapter 10.

The asymmetry that should actually decide it is about who benefits. A model upgrade arrives on the vendor's schedule and accrues to every competitor simultaneously. A harness improvement arrives on yours and accrues to you. One is a rising tide; the other is a boat.

The fair counter-consideration, which belongs in the decision: harness work is engineering you must staff, maintain and eventually migrate. A model upgrade is a configuration change. That is a real difference in cost of ownership, and any honest comparison prices it.

The honest ceiling

Three caveats, so this chapter does not become a boast.

None of this says the model doesn't matter. A multiplicative theory says the opposite: every factor is load-bearing, a zero anywhere collapses the product, and on genuinely hard reasoning the model is frequently the binding constraint. A perfect harness around a weak model is a beautifully organised way to be wrong.

None of this says a harness gain transfers. Chapter 11's protocol exists because the only number that binds for your workload is the one you measured on it. Borrowed deltas are how people end up disappointed.

None of this says the boundary is stable. If labs train models into these harnesses — and at least two public research lines are explicitly aiming at exactly that — some of today's harness contribution becomes tomorrow's model contribution. The unit being measured is still the composite. The seam just moves.

What survives all three caveats is the reading instruction:

Stop reading a leaderboard as a statement about a mind. It is a statement about a mind and a machine — and only one of them is named on the chart.

Model horse-racing is the most expensive form of not paying attention currently available to a technical organisation. It occupies the exact attention that would otherwise go to the one multiplier you control.

Which brings the book back to the claim Chapter 1 made and Part III paid for: a surprising amount of what we have been calling model intelligence is model intelligence trapped behind last-generation, human-shaped harnesses. The capability is already bought. It is sitting in a room built for the wrong occupant.

The category claim stands, and it is worth stating before the correction: the first three kinds of agent loop are loops you designed — fixed structure, changing content — and a self-structuring one designs its own sub-loops at runtime. That is a change of category, not a change of degree.

And then the part I got wrong, in my own words, published:

"The line is right. The category is real. My implication — that this was where the durable value of loop design would land — was wrong."

Where the value actually landed was in two much duller places. First, a carryable invariant — a compressed statement of what kind of system should exist, short enough for a human to carry and precise enough for an agent to regenerate. Second, a boring external scheduler with a done-test, which is what actually made long jobs finish, repeatedly, across dozens of runs.

That correction belongs here specifically because an architecture that lets the operator build its own machinery is seductive in exactly the way it warns about. The machinery is the visible part. It is not the durable part.

Three costs, unhedged

One: non-determinism. "The generated orchestration is sometimes simply invalid, and you find out mid-run." Worse than the wasted cost is the shape of the failure: it surfaces late, after spend, and it is not always detectable by the operator. An invalid plan can complete and produce a confident wrong answer, which is the most expensive category of output there is.

Two: expense. It "scales with how far the agent decides to take the structure" — and the operator decides at runtime, which means your cost distribution has a tail you did not choose. Budget by run rather than by average, and instrument the tail specifically, or your first surprise will be an invoice.

Three: lost legibility. "You can no longer point at a fixed pipeline and say what will happen, which is a real loss and not a philosophical one." Chapter 12's boundary artefact buys some of that back — but only some. Debug symbols tell you what happened. They do not tell you in advance what will.

All three are acceptable for exploration. None is acceptable where a regulator, a customer or a rollback sits downstream.

The deterministic-middle rule

A self-structuring middle is fine at the ends of your pipeline and dangerous in the middle of it.

Three conditions force determinism, and each comes with a test you can apply today:

• • Two runs over the same inputs must agree. Test: can you re-run and diff?
• • Provenance must survive. Test: can you point at the exact input that produced this output?
• • A budget must not drift because the prose felt confident. Test: is the number computed, or asserted?

The shape that works is a pendulum: AI judgment → deterministic compilation → AI judgment. Variation at the ends, compilation in the middle. Put the model in the middle and provenance dissolves into prose — minority findings become tone, and budgets become whatever fitted the context window that day.

Posture, not maturity

This is the reframe that resolves the chapter, and it is the one most likely to be misread as hedging. So state it as a decision rule with inputs.

Agent-Native Computing is therefore not a maturity rung everyone should be climbing toward. It is a posture chosen by what the work is producing. A capstone that admits its own scope is worth more than one that doesn't.

Worth walking one case, because "choose by unit of production" is easy to agree with and hard to apply when a single system does both.

Take a monthly regulatory report assembled from a dozen internal sources. The reader's instinct is that the whole thing is a "specified change" and therefore belongs on the fixed-structure side. That is nearly right and expensively wrong at one point.

Split it. Discovering why two of the twelve sources disagree this month — that is a newly understood thing, nobody can specify the shape of the answer in advance, and it is exactly where a machine-native middle earns its cost: partition the data, dispatch children, keep the verdicts as objects, write a second probe at the disagreement. Producing the reconciled figure that goes into the report is a specified change with a regulator downstream, and it belongs in deterministic code that two runs will agree on.

The failure mode is not choosing the wrong posture for the system. It is choosing one posture for a pipeline that has both kinds of step in it — and the tell is always the same: somebody asks "why did this number change?" and the honest answer is "the reasoning was different this time."

The failure modes this architecture introduces

A book that only lists the failure modes of the architecture it is replacing has written advertising. Here are the new ones.

Two of those are worse than what they replace, and it would be dishonest not to say so. Bad state is more silent than a bloated context — there is no gradual haze to notice, no degradation you can feel; the system is simply confidently wrong from a point you cannot locate. And a ritual boundary artefact is worse than no artefact, because it manufactures the appearance of oversight while providing none, which is how organisations end up surprised by something they had a process for.

What would falsify this book

A capstone that cannot be wrong is not an argument. Five things would do it:

1. Fixed-model A/B deltas that sit inside within-arm variance across varied workloads.
2. Harness gains that vanish under adversarial or unseen task selection — the leaderboard spread turning out to be overfitting after all.
3. Boundary artefacts that readers demonstrably cannot act on: comprehension that does not survive the handoff to a person who was not in the room.
4. Machine-native middles that require so much boundary engineering that the total cost exceeds the capability released.
5. Models absorbing harness function so completely that harness variance collapses. That would not make the book wrong so much as retire it — and it should say so rather than pretend otherwise.

Keep the category. Lower the rank. The machine-native middle remains the most interesting thing in the field, and it is not the thing that makes most jobs finish.

Do the strip on the page rather than describing it. Delete the specimen. Delete the benchmark and the leaderboard. Delete the papers, the operator anecdote, and every vendor, product and model name in the preceding sixteen chapters.

Here is what is left.

Check it. Every load-bearing term in that paragraph — primary operator, representation, control structure, memory system, boundary, intent, judgment, authority — is defined in this book without reference to any product.

And the honest note: the specimens are how we know it is true. They are not what makes it true. If every system named in this book were withdrawn tomorrow, that paragraph would be unchanged, and the next specimen would arrive.

Four domains, and which layer moves first

A claims-processing pipeline. The documents are text wearing pixels, and the assessors' tooling is a human interface the operator drives by description. Representation moves first — serialise the evidence properly — and the authority boundary is already roughly where it should be, because payment runs through a separate system.

A research workflow over a large internal corpus. The pain is that every session re-reads the same material and loses its own conclusions at compaction. Long-running cognition moves first: make the intermediate structure addressable so the summary only has to restore orientation.

A compliance or assurance review. The middle can be fluid, but the output is consumed by someone who must be able to disagree with it. The boundary artefact moves first — build the comprehension surface before you touch the middle, or you will have made the middle better and the review impossible.

An archive or platform migration. Nobody knows the formats until contact with the data. Execution moves first: a programmable environment where the missing reader is a build step rather than a procurement decision.

The pattern across those four is worth stating once: the layer that moves first is the layer where the human shape is costing you most — and it is different in each case. That is why what follows is an audit and not a checklist.

The agent-native design audit

Sequencing

Move the layer where the human shape costs you most; the audit tells you which one that is. Beyond that, there is exactly one ordering constraint in this entire book, and it is not negotiable:

Two softer pieces of ordering advice. Do build the comprehension surface early if humans review the output — it is much easier to design the boundary artefact while the middle is still legible than to reconstruct it afterwards from a trace nobody can read. And do not promote anything in the first month; you do not yet know what recurs, and early promotions are the ones that become unowned.

The room and the occupant

Chapter 1 made a claim and Part III paid for it, so it can be restated now as a finding rather than a provocation: a surprising amount of what we have been calling model intelligence is model intelligence trapped behind last-generation, human-shaped harnesses.

That lands two ways, and both are true at once.

The uncomfortable half: your system's ceiling is partly your own design decision, and has been all along. Nobody chose those six assumptions from Chapter 1. Everybody inherited them. But inheritance is not innocence once you have read the audit.

The liberating half: the model is the component you rent, and everyone else can rent the same one. The machine around it is the part you own — and it is the only part where a quarter of good engineering produces an advantage that does not arrive in your competitor's inbox on the same day.

The capability is already paid for. It is sitting in a room built for the wrong occupant.

Design for the creature using the system.