Agent-Native Computing: What Computer Would You Build for a Machine?

In July 2026, OpenAI published something quietly devastating about its own model. GPT‑5.6 Sol had scored 7.8% on ARC-AGI-3, a benchmark of interactive 2D puzzle games. The company went looking for the reason, expecting to find a weakness in the model. It found a weakness in the harness.

Two settings, both already standard in their own products, were switched on: retained reasoning and compaction. On the public task set, the model's score went from 13.3% to 38.3% — and it used six times fewer output tokens getting there.¹ Same weights. Same benchmark. Same games. The difference was entirely in the software wrapped around the model.

OpenAI drew the general conclusion itself, and it is the sentence this whole piece exists to unpack:

"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.

The two settings tell you what the old harness assumed

Look at what those two switches were actually fixing, because the diagnosis is more interesting than the delta.

The first: after each game action, all of the model's private reasoning was thrown away. As OpenAI describes it, the model "was asked to figure out the game anew, unable to remember its past thinking."¹ It could see a record of its past moves. 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 became invisible. "So not only was GPT‑5.6 Sol unable to remember its past thinking, it was losing memory of its past actions too."¹

Neither of those is a bug. Both are perfectly sensible decisions for a chat product being read by a human. Discard the private reasoning — the user doesn't need it, and it costs tokens. Truncate the oldest turns — the conversation has moved on. 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 over hundreds of actions.

That is the pattern, and it is much bigger than one benchmark. We have spent three years seating language models inside software that was designed, in every detail, for humans — and then reading the resulting performance as a property of the model.

The category: Agent-Native Computing

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

Not "software with AI features." Not even "agentic software," which usually means a human application with a model bolted to the front. The design question is blunter than either:

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

Ask that seriously and a stack of inherited assumptions falls out of the design in a single motion. Why should the main interface be a catalogue of English-described tools? Why should every intermediate result be serialised into a chat message? Why should each computational operation require another conversational turn? Why should a temporary function be promoted into a permanent "tool"? Why should context compaction destroy computational state? Why should the internal execution trace be pleasant for a human to read?

None of those came from studying how models work. All of them came from building AI inside human software.

The historical rhyme is exact. Early websites were paper documents rendered on a screen until somebody said: hang on, this isn't paper. Early mobile apps were desktop applications squeezed onto small screens until somebody said: 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 — and the sentence waiting to be said is hang on, this user isn't human.

One design move, three layers

The reason this is a category rather than an observation is that the same move has now been made three times, at three different altitudes, and each time it produced the same kind of gain.

Layer one — representation: pixels → structured text

This one is settled. When content is fundamentally text wearing pixels — a slide, a terminal recording, a rendered document — you stop forcing the model through a human visual interface and serialise it into the medium it reasons over best. Text is the model's home turf, and converting the image problem into a text problem gets you cheaper and more accurate at the same time.

Before: a screenshot in a vision model, competing on a task the training distribution barely covers. After: a structural text map the model reads perfectly. Same model, different affordance.

Layer two — execution: a human tool catalogue → a programmable environment

The traditional agent loop is anthropomorphic to the point of ceremony. The model says, in English, that it would like to call tool X with arguments Y. The harness parses that request, calls a fixed function, serialises the result back to text, feeds it into context, and waits for the model to express its next desire in English. Repeat.

That makes sense if you imagine the model as a person at a console. Machine-to-machine, it is absurd. You do not need please invoke the customer lookup tool with ID 123 when the operator can simply write:

customer = db.get_customer(123)
orders   = [o for o in db.orders(customer.id) if o.status == "pending"]

and keep operating over the objects. The natural language was there because we designed the interface to be inspectable and comfortable for ourselves.

Anthropic's own engineering work quantified one slice of the cost: presenting tools as code on a filesystem, loaded on demand, cut an illustrated context load from roughly 150,000 tokens to about 2,000 — a 98.7% saving in that example.² That number gets quoted a lot. The philosophy underneath it matters more: capability composed after contact with the problem beats a pre-declared ontology.

Before: a catalogue of named operations, chosen one per turn, with every intermediate result flowing through the model's attention. After: an execution environment where the model composes operations in code, keeps the bulk data out of context, and returns only what changes a decision.

Layer three — long-running cognition: chat transcript → persistent computational state

This is the new one, and it is the reason this piece exists.

The conventional long-run architecture is a transcript that grows until it must be compressed, at which point a summariser flattens the history and the agent continues from the summary. Prime Intellect describes the incumbent pattern precisely, and unkindly:

"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."³

A succession of agents joined by handover notes. That is what a long run actually is under transcript-and-summary architecture, and it explains a failure mode any operator of long agent runs has watched: the run compacts, and then you see the agent reorienting on its own project mid-flight. I know I was working on something — what was I doing again? What were the files? It recovers, reasonably. But it dropped the ball, and now it has to backtrack into what it was supposed to be doing. Ridiculous — and expensive.

This isn't a private complaint. There is an open feature request against Codex describing exactly the same shape: a goal iteration begins with the context nearly full, compaction fires mid-task, and "this can waste the work done in that iteration, because the agent may effectively have to start over after compaction."⁴

The alternative is the Recursive Language Model. Rather than pushing a huge prompt into the model's context, the RLM treats it as an external object inside a persistent Python REPL: the model receives only constant-sized metadata about the prompt — its length, a short preview — and then writes code to inspect, slice and transform it, recursively calling fresh model instances over selected pieces.⁵

Before: a transcript, compressed on a schedule, where the summary is the memory. After: an addressable computational state — variables, parsed structures, functions, child processes — where the summary only has to restore orientation, because the working state never went anywhere.

Three layers, one move: translate the world into the representation the acting intelligence has the highest affordance over, not the one humans happen to use.

The specimen, read from the outside

Architecture arguments are cheap until something ships. Prime Intellect's Prime Agent is a shipped, open-source specimen of all three layers at once, and its documentation is public, so it can be read outside-in without any claim of privileged access.

Its own docs state the shape plainly: "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, skills, delegation and context management all begin from that kernel rather than from a catalogue.

Three properties are worth naming, because each corresponds to one of the layers above.

• 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."⁶ Compaction summarises the prose; the computation survives.
• Recursion as an ordinary call. rlm(...) spawns a real child agent session with its own context and session directory; the call returns immediately with a handle and never blocks on the child's answer. The child registry itself "survives compaction, kernel restart, and parent restoration."⁶
• A hard boundary underneath. "Provider calls, session persistence, child lifecycles, scheduling, and safety policy remain in the TypeScript host."⁶ Python asks for authoritative operations through typed host requests — which is a syscall in everything but name.

And one warning, stated by the project itself, that matters more than any feature: 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."⁶

Hold that sentence. It is the hinge of the whole doctrine.

The doctrine: machine-native in the middle, human-legible at the boundaries

The instinctive objection to a fluid cognitive middle is that it sounds like abolishing protected memory. From the model's point of view it nearly is: a result becomes a variable, a thought causes a function to be written, the function launches another reasoning process, its result becomes another object, and that object changes the next thought. Data and executable procedure stop being different categories.

But protection was not abolished. It moved outward. That is a completely different architecture, and a much better one.

          HUMAN-LEGIBLE INTENT
                   │
   ────────────────┼────────────────
          MACHINE-NATIVE COGNITIVE RUNTIME
     persistent kernel · objects · generated
     functions · recursive children · ephemeral
     tools · programmable context
                   │
   ─────── HARD AUTHORITY BOUNDARY ───────
     credentials · provider execution · transcript
     writes · scheduling · policy · irreversible acts
                   │
                REAL WORLD
                   │
          HUMAN-LEGIBLE RECEIPT

Read top to bottom and the rule is: fluid cognition inside, hard authority outside. Let the middle be as weird as it needs to be — recurse, fork a disposable in-memory database, forge a tool and melt it down twenty minutes later. But do not let cognitive freedom mint causal authority.

This is not a new principle; it is a fifty-year-old one applied one layer down. Our own doctrine states it as a rule you can apply when somebody asks whether the model should have access to X: discretion and privilege should move in opposite directions. The more capable and less predictable a component is, the narrower its access should be. Saltzer and Schroeder wrote the underlying principles in 1975 — least privilege, separation of privilege, complete mediation.⁷ Agent-Native Computing does not suspend them. It makes them load-bearing, because the thing above the boundary just got far more capable and far less predictable.

The model becomes its own memory manager

Here is the step that I think is genuinely new, and it is a memory-management step.

We already argued that a context window is not RAM. In an ordinary program, a value 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 generating the next one. Material in context isn't waiting to be fetched, it is already eligible to change what the model notices, which analogy becomes available, and which proposal it never makes. We called that the Inference Field.

What the RLM shape adds is a second kind of memory sitting beside the first — and, more importantly, the ability for the model to allocate between them.

              DURABLE WORLD
        files · databases · the wiki
                   │
        ADDRESSABLE COGNITIVE HEAP
     persistent kernel: variables, parsed data,
     generated functions, child handles
                   │
          model writes the pager
                   │
      ┌────────────┴────────────┐
      ▼                         ▼
 INFERENCE FIELD          CHILD INFERENCE FIELDS
 ambient, conditioning    independent, bounded
      └────────────┬────────────┘
                   ▼
             parent synthesis

Two modes of cognition, not one. Ambient — information is resident in the field and silently conditions every next token. Addressable — information is an object the model can inspect, slice, transform and pass into another act of inference. The second one is the new capability, and it changes the job of summarisation entirely.

Our own published correction on long-context discipline was: do not trim the history, compile the state. Keep the walk log, keep an explicit task-world state, and keep the active field separate. That was right, and in that formulation the compiler was me — the architect, writing deterministic code ahead of time to decide what survives. The agent-native version is the step after: the compaction architecture becomes something the operator writes at runtime, in code, while thinking.

Four things now change on four different clocks, and confusing them is where most "AI memory" conversations go wrong.

The third row is where an entire research direction has arrived independently. The Continual Harness work defines a harness state of prompt, sub-agents, skills and memory, and has agents refine their own scaffolding online, within a single run, without episode resets — starting "from the same raw interface with no curated knowledge, no hand-crafted tools, and no domain scaffolding."⁸ Learning that lands in legible scaffolding around a frozen model, rather than in weights.

One honest caution, since it is my own doctrine being stretched: I have argued at length that state inside the agent evaporates and state outside it compounds — that durability beats coordination, and that anything worth keeping must pass a cold-successor test. A kernel heap is state inside. It is a tier, not a replacement. It is fast, addressable and mission-local — and it is emphatically not the system of record. Everything that must survive the process still has to be written somewhere a fresh worker can open.

The evidence, with its provenance kept straight

Now the part where it would be very easy to cheat, so let me not.

There is a widely repeated claim that a new harness took roughly the same model from about 30% to about 95% on ARC-AGI-3. That is three different numbers with three different provenances, and merging them would be exactly the sloppiness this argument cannot afford.

ARC Prize itself states the governing caveat about that second row: community submissions are "self-reported unless noted otherwise," only the ARC-AGI-1 and ARC-AGI-2 semi-private results are run and verified by ARC, and "everything else is scored on a public set and self-reported."¹⁰

So drop the headline delta. It is not needed — and the thing that replaces it is better, because it is a spread rather than a peak.

The leaderboard is the argument

Look at the ARC-AGI-3 community leaderboard not as a ranking but as an experiment nobody designed. Same benchmark. Same public demo set. Broadly comparable frontier model classes. Wildly different harnesses.¹⁰

Read down that "what it does differently" column. Almost every high scorer is doing the same three things: build an executable model of the world in code, keep state addressable across the run, and verify hypotheses against recorded history before acting. That is machine-native middle, described in the leaderboard's own words, by teams who arrived at it independently.

And the honest objection is right there in the spread: harnesses can overfit a benchmark. Of course they can. But overfitting explains a peak. It does not explain a range from 5.2% to 100% on the same task family — and it certainly does not explain OpenAI finding a 3× improvement on its own model by switching on two settings it already ships in production.

Two controlled results, model held fixed

The strongest evidence isn't leaderboard spread at all. It is the small number of experiments where the model was pinned and only the harness moved.

The RLM paper holds GPT-5 fixed and reports median improvements across its evaluated benchmarks of 26% against compaction, 130% against CodeAct with sub-calls, and 13% against Claude Code — on four long-context tasks, at comparable cost.⁵

The Recursive Agent Harness work, from researchers at PricewaterhouseCoopers, makes the recursive unit a full agent harness rather than a bare model call, and states the control explicitly: "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 … a gain attributable to the harness rather than the model."¹¹

Three independent groups, three methods, one direction. That is not proof of a magnitude. It is strong evidence of a mechanism.

The trace is no longer the explanation

There is a cost to all this, and it lands on the human.

Watch a conventional coding agent run and the trace is human-shaped: I'll inspect package.json. I'll search for references. I found X. I'll run the test. That legibility was never a design achievement. We got it by accident, because the unit of computation was a semantic agent turn — so the execution log and the explanation of the execution happened to look alike.

Move the operational grain down to create object, slice object, map function, invoke child, transform state, branch, recurse and the trace stops looking like a colleague narrating an investigation and starts looking like a program running. Of course it's gobbledygook. You are watching something closer to cognitive assembly language, and trying to understand the run by reading every kernel operation is like trying to understand a browser by staring at an instruction trace.

The trace can be perfectly useful for debugging while being completely useless as an explanation. Those are two different artefacts, and we have been getting away with conflating them.

This is not hypothetical. When an OpenAI model disproved a longstanding conjecture in discrete geometry, the mathematicians who checked it accepted the correctness readily — Tim Gowers said he would have recommended acceptance to a top journal "without any hesitation"¹² — and then, separately, asked the comprehension question. Thomas Bloom, in the 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."¹² Correct and comprehensible came apart, in public, and the experts noticed.

The wrong response is to force the middle to speak pleasant English at every operation. That taxes the exact thing that made it capable, and it produces narration rather than reasoning.

The right response is to stop asking one surface to do two jobs. Let the execution plane be as dense and machine-efficient as it needs to be. Then, at meaningful boundaries, emit a separate artefact for the human — not a prettier log, a different object.

The governing law underneath is one I have already argued elsewhere and won't 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. What is illegitimate is opaque density, where a handle points to nothing you can reach. Opaque density is where audit dies.

Dense is fine. Opaque is not. The limiting interface between machine cognition and human judgment is decompressibility — and in an agent-native system, that interface has to be built deliberately, because you are no longer getting it for free.

Two tool lifecycles

One consequence worth separating out, because teams get it wrong in both directions.

When a model can manufacture capability mid-task, most of what it makes should evaporate. A disposable SQL probe, an in-memory database standing in for a quarantined production world, a parsing function that exists because one file was malformed — these have a working life of twenty minutes and should die with the task. Runtime-generated code is speculative optimisation.

Occasionally something earns promotion. A pattern proves strategically reusable, and it graduates into the durable substrate — a skill, a standing sensor, a library function the next run inherits. That is where a successful speculative optimisation becomes part of the standard library.

The promotion test is not "was it useful?" — everything the agent built was useful once. It is: would a future run, on a different task, reach for this? If not, let it melt.

What this does not fix

I have published a correction on this exact axis before, and I am not going to quietly un-publish it. A loop that writes its own loops is a real category change — and it is not automatically where the value lands.

Three costs, stated flat:

1. Non-determinism. Generated orchestration is sometimes simply invalid, and you find out mid-run.
2. Cost. It scales with how far the operator decides to take the structure, and the operator decides at runtime.
3. Lost legibility. You can no longer point at a fixed pipeline and say what will happen. That is a real loss, not a philosophical one.

All three are acceptable for exploration. None is acceptable where a regulator, a customer or a rollback sits downstream. Which produces the boundary rule for the machine-native middle: a self-structuring middle is fine at the ends of your pipeline and dangerous in the middle of it. Where two runs over the same inputs must produce the same result, where provenance must survive, where a budget must not drift because the prose felt confident — that step is deterministic code, and no amount of architectural elegance changes it.

Agent-Native Computing is a posture, chosen by what the work is producing. When the output is a specified change, favour fixed structure and durable state. When the output is a newly understood thing — an edge, a constraint, a framework nobody had named — the machine-native middle earns its cost, because you cannot specify in advance what you are looking for.

The domain strip

Last test, and it is the one that decides whether this is architecture or fan mail.

Delete Prime Agent. Delete ARC-AGI-3. Delete every specimen and every benchmark. Does the claim still stand?

It does, in one paragraph: when the primary operator of a system is a machine intelligence, the representations, control structures and memory systems in the middle of that system should be chosen for the machine, while the boundaries — where humans form intent, exercise judgment and grant authority — remain legible and hard. Systems built the other way around, with human-shaped interfaces all the way down, leave capability on the table, and the amount left on the table is not small.

No product in that paragraph. No benchmark. It applies to a claims-processing pipeline, a research workflow, a security review, an ETL job over twenty years of archives. The specimens are how we know it is true; they are not what makes it true.

What to do on Monday

Six questions, in the order that finds the biggest gap fastest.

1. Who is the primary operator of each surface? If a surface's main consumer is a model and it still exposes a human-shaped interface, you have found a tax.
2. What happens to your working state at compaction? If the summary is the memory, you are running a succession of workers joined by handover notes and paying orientation latency at every seam.
3. Can the operator compose operations, or only select them? A catalogue of named tools is a pre-declared ontology; the question is whether it can build the verb it needs.
4. Where is your authority boundary, and can cognition redraw it? If the answer is "we prompt it not to," you don't have a boundary. Credentials, irreversible actions and policy live outside the thing that reasons.
5. What is your explanation artefact, and is it the trace? If your only human surface is the live log, you are one grain-size change away from having no explanation at all. Build the debug symbols before you need them.
6. Which generated machinery is earning promotion? Most should evaporate. Some should graduate. Nothing should linger unreviewed in between.

The benchmarkable unit has moved

Here is where all of it lands.

The multiplicative view of agent capability — that outcome is a product of model, goal quality, harness persistence, reality access, tool surface and tool synthesis, where any zero collapses the lot — has been our position for a while. At the time it could sound like a systems engineer insisting that architecture matters too. The 2026 evidence sharpens it into something with teeth:

Which means 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 should be uncomfortable and liberating in the same breath. Uncomfortable, because it means your system's ceiling is partly your own design decision and has been all along. Liberating, because the model is the one component you rent and everyone else can rent too — and the harness is the part you own.

If the reported results survive replication, then 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 paid for. It is sitting in a room built for the wrong occupant.

Design for the creature using the system.