Saneel SreeniBack [B]

Five Lines to Infinity

Harnesses have improved immensely the past few years. Today, we look at the history of harness engineering and where I think we’re headed. TL;DR Closed-model providers will absorb generic harness logic through co-training, but the last mile remains irreducible: the tools, state, permissions, verification, and recovery specific to an enterprise, domain, workflow, or person.

In July 2026, OpenAI was puzzled that GPT-5.6 Sol, a model that could prove mathematics and play Pokémon, looked helpless in ARC-AGI-3’s small 2D worlds. Under the official generic harness it scored 13.3 on the public set but when OpenAI changed two context settings. The same model scored 38.3 and emitted six times fewer output tokens.

The changes sound almost insultingly mundane: retain the model’s private reasoning between actions and when context fills, compact it instead of deleting the oldest turns. Without the first, every move asked the policy to rediscover the game. Without the second, it eventually forgot the evidence needed to learn it. The benchmark had not only measured abstract reasoning; it had measured a particular theory of conversation history.

Both of these were harness level changes.

FIGURE 1

Two settings changed the apparent frontier

Official generic harness13.3
Retained reasoning + compaction38.3
010203040 RHAE
Observed. GPT-5.6 Sol (max) on the ARC-AGI-3 public set. OpenAI’s Responses API harness retained reasoning and enabled compaction; output tokens fell 6×. This is a public-set harness comparison, not a replacement for ARC Prize’s verified leaderboard. Source.

ARC Prize had just named Claude Opus 5 its new verified leader at 30.2. OpenAI’s 38.3 was a public-set rerun under a different harness, so it does not directly replace that ranking but it does make the ranking’s hidden variable impossible to ignore. “Which model is smarter?” is underspecified until we say how each model is allowed to remember, act, and recover.


This article is my attempt to make that hidden variable, the harness, legible. I want to explain how the code around a model evolved, what each new layer was trying to fix, and why the harness now matters as much as many changes to the model itself. The most useful starting point is to stop treating “the agent” as one indivisible thing.

The relevant unit of comparison is the model and harness together, not the model alone:

result = f(model, harness, environment, budget, evaluator).

Here is the vocabulary I will use. The model proposes the next inference or action. The harness coordinates the work: it decides what the model sees, which actions it can express, when to retry, and where feedback goes. The environment is the world being changed. The evaluator judges the result independently. Add compute limits and human authority, and you have the complete agent system.

POLICY
proposes
HARNESS
coordinates
ENVIRONMENT
changes state
EVALUATOR
judges
AGENT SYSTEM
contains all four

The harness in my view is the control plane: the place where durable state becomes a model call, a model output becomes a constrained action, and evidence from that action becomes the next observation. Harness history broadly follows three veins: (a) interfaces turned calls into trajectories, (b) external state turned trajectories into long-running work and (c) independent evaluation made it possible to improve the controller without letting it grade its own homework.

From an answer to a trajectory

GPT-3 initially made the model look like a function: `answer = model(prompt + examples + question)`. There was no environment to inspect and no result to feed into the next decision. The unit of computation was one completion.

The first missing object was evidence. WebGPT placed GPT-3 behind a text browser with five basic actions: search, open, click, navigate, and quote. The final answer had to cite observations gathered through that browser. Its best configuration was preferred to its human demonstrators 56% of the time. Beyond search. the important part was that a claim could now be checked against a trace outside the model’s prose.

Evidence still did not grant authority. A model can propose an action that sounds useful but cannot work in the current world. SayCan made that distinction explicit in robotics: a language model scored whether a skill served the instruction, while an affordance model scored whether the robot could execute it now. Fluent language no longer had unilateral control over physical action:

score(skill) ≈ P(useful | instruction) × P(executable | world).

If you remember one thing about SayCan, make it this: usefulness and permission are separate scores. That multiplication is the ancestor of every later gate in this essay: a test decides whether to accept a patch, a policy decides whether a GUI action needs approval. A sealed evaluator decides whether an optimized skill may ship. The model proposes what ought to happen. A mechanism grounded in the world decides what may happen (this is the ancestor of some of the guardrails you’ll see/permissioning needed when using Codex/Claude code!)

The remaining step was to repeat this separation. Routing work to external modules in MRKL, and delegating exact computation to generated programs in PAL, moved operations the model should not simulate into machinery that could actually perform them.

ReAct, which is functionally the core of most agent loops, then compressed the general pattern into Thought → Action → Observation: plan locally, act through an interface, let the changed world correct the next inference.

history = []
while True:
    step = model(goal, history)
    if step.kind == "finish":
        return step.answer
    observation = tools[step.name](**step.args)
    history.append((step, observation))
FIGURE 2

Closing the loop

PROMPT-ONLY PROMPT STATIC STATE MODEL ONE CALL ANSWER NO FEEDBACK AGENT LOOP STATE GOAL + HISTORY POLICY NEXT ACTION ENVIRONMENT OBSERVATION
Derived conceptual synthesis from WebGPT, SayCan, and ReAct. Red marks the neural policy; the feedback loop around it is the first general harness.


With one or two demonstrations, ReAct reported absolute gains of 34 points on ALFWorld and 10 on WebShop over imitation and reinforcement-learning baselines. Its five-line structure still sits inside current agents.

The problem is that this tiny loop asks one transcript to do four jobs at once: hold the plan, store memory, record the trace, and represent the current world. It also asks the model to choose tools, interpret errors, verify results, and decide when to stop. One bad action changes every later observation and can be costly to context.

Training the policy to insert API calls, as Toolformer did, and later standardizing typed function calls made individual actions cleaner but did not solve the larger problem. A typed call gives the model a verb but does not give the system durable state, control flow, verification, or recovery. Once we knew how to let models run in loops cleanly, the next temptation was obvious: let it run for longer. That is where the simple loop started to break.

Externalizing state is the key to trust

The immediate response was simply to keep the loop running. BabyAGI gave ReAct an indefinite goal, retrieval memory, and a task queue that could add more tasks to itself. Its controller was almost comically small:

while tasks:
    task = tasks.pop(0)
    result = executor(task, memory)
    memory.store(task, result)
    tasks += creator(goal, task, result)
    tasks = prioritizer(tasks)

The queue moved intended work/tasks out of the model’s prose, but led to another problem: the planner could manufacture unlimited work and grade whether it mattered. Without an independent completion test, the quantity of activity looked exactly like progress even if it wasn’t.

This wasn’t strictly a memory problem because “more memory” is too vague to be useful. A lesson about a failed attempt, a fact needed later, and a reusable procedure (skills!) are different objects you’d want in memory with different ways of becoming true. There were a number of approaches meant to thus solve for these:

  1. Reflexion stored the first as a verbal hypothesis for another attempt.
  2. MemGPT addressed the second by treating context as a cache over external tiers. The prompt was no longer the canonical record but a temporary view assembled from a larger store.
  3. Voyager made the third object concrete. A generated Minecraft program entered its skill library only after execution and self-verification. It reported 3.3× more unique items and technology milestones reached as much as 15.3× faster. Experience had been compiled into a retrievable, testable procedure:
candidate = synthesize(goal, retrieve_skills(goal))
result = environment.run(candidate)

if verifier.accept(result):
    skill_library.add(
        procedure=candidate,
        description=describe(candidate),
        evidence=result
    )


Moving down the list of reflection, knowledge recovery, and skills list usually makes verification easier, but not permanent. A reflection should not become a permission, and a skill may fail when its preconditions change.

There was one more hidden object to externalize: the path not taken. Language Agent Tree Search could score and revisit alternate trajectories instead of committing to the first plausible one. But this only works when the world is cheap to copy and an evaluator can compare branches. You cannot abandon a branch after it sends an email or changes a reservation. Search needs a reversible state. As it turns out, software repositories happened to provide almost exactly the world the harness would want.

Coding turned the loop into a runtime

The early tool loop treated a computer as a menu of verbs but software work made that abstraction collapse. Editing a repository is a procedure: inspect, search, mutate, execute, interpret the failure, and try again against a changing world. A repository also supplied what earlier agents lacked: legible state, an oracle outside the policy, and reversible branches.

state       = files
actions     = shell + patches
feedback    = compiler + tests
checkpoint  = git commit
branch      = worktree
world       = sandbox

The first shift was from choosing tools to writing procedures:

  1. CodeAct made executable code the action language, letting one model step compose libraries, loops, and intermediate state. Orchestration moved below the token loop, where ordinary control flow was cheaper and exact.
  2. Once models could write procedures, failures moved to the interface around them. Terminal output and editors were built for humans, so SWE-agent treated computer use as a language-design problem. Bounded file views, explicit search, structured edits, and useful errors helped GPT-4 reach 12.5% on SWE-bench versus the cited 1.96% non-interactive result. Search, patch, test, and error had become a model-facing computer interface.

But longer jobs required a runtime. Modern coding agents like Claude Code and Codex represent actions and observations as typed events so the policy, sandbox, interface, and benchmark adapter could evolve independently. They also compile the repository state into each call, isolate execution, preserve progress outside one context window, and write and let tests decide whether code can ship. In this paradigm, because the durable object is no longer the core agent loop, we have agents that can cleanly improve AND be comfortably run in the cloud.

FIGURE 3

The modern coding control loop

EVENT LOG GOALS · HISTORY · APPROVALS CONTEXT COMPILER RULES · PLAN · RELEVANT STATE POLICY BROKER APPROVALS · SCOPED CREDENTIALS MODEL PROPOSE NEXT ACTION TYPED TOOL INTERFACE SEARCH · PATCH · SHELL SANDBOX EXECUTION · NETWORK POLICY REPOSITORY FILES · GIT · ARTIFACTS VERIFIER TEST · LINT · ARTIFACT REVIEW EXECUTION RESULT EVIDENCE APPENDED
Derived conceptual synthesis. Repository mutation occurs through the sandbox; the verifier reads resulting artifacts and returns evidence to durable history for the next compiled context.

It helps to read the diagram from the bottom up. Sandboxes perform the code mutations, the repository preserves the changed world, the verifier inspects the result, and the event log records the evidence. Given all of this, the harness then assembles a temporary context for the next call. A fresh model call can continue old work because it receives the information it needs to continue the work from structured data AND the durable artifacts to be modified live outside the agent.

Code made this architecture unusually forgiving. The world was legible, branches were cheap, and many outcomes could be tested cleanly. But, as we have found out, this is NOT the case for many other environments.

The web broke the illusion of a universal interface

Code’s conveniences did not transfer to the web. Browser tasks span pages, hidden state, authentication, and mutations whose success may be invisible. WebArena made those failures measurable; BrowserGym and AgentLab standardized observations, actions, and evaluation. They exposed the next problem: the same representation was not best for both perception and action.

Let’s look at why:

  1. Screenshots work everywhere but hide semantics.
  2. DOM and accessibility trees expose structure but can be enormous, stale, or incomplete.
  3. Program state is precise but application-specific.

Strong computer-use harnesses combine the best of all worlds: pixels for visual evidence, structured state for targeting, and narrow tools for operations that should not use a mouse.

Full desktop environments removed the last convenient fiction: that a failed trajectory can always be reset. In OSWorld-like settings, the world is partially visible and a sent message, item purchase, or changed reservation cannot be undone by restoring a screenshot. SayCan’s old distinction, that usefulness is NOT a permission, returns at higher stakes. The model may judge an action useful; the harness must still judge it admissible. Read-only inspection can run speculatively, while external mutation needs idempotency keys, approval boundaries, and semantic checkpoints recording both authority and effect.

This is how computer use turns into a personal agent. Start with the GUI agent’s partial view of the world and its irreversible actions. Then add a durable identity, accounts, schedules, communication channels, and memories that may affect a decision months later.

Personal agents make the control plane explicit

A personal agent inherits every earlier obligation: partial observation, persistent identity, distinct memory and procedure, and protection against an old intention becoming permanent authority. OpenClaw and Hermes Agent expose machinery that a chat window usually hides.

OpenClaw organizes a long-lived personal workspace around channels, sessions, gateways, and policy-bound plugins. Hermes centers a portable loop that assembles prompts, dispatches tools, retries failures, compresses context, and persists sessions across backends. But both share the core invariants: identity, memory, procedure, and authority must remain separate even when the interface makes them feel like one assistant.

FIGURE 4

Shared invariants, different emphasis

CONTROL-PLANE INVARIANT OPENCLAW EMPHASIS HERMES EMPHASIS
Identity + routingchannels, gateway, sessionsentry points, profiles, sessions
Context assemblyworkspace, memory, routestable, contextual, volatile tiers
Procedurescoped workspace skillsretrieved procedural skills
Authoritygateway policy + approvalstool policy + completion contracts
Extensionplugins + runtime adapterstools + local/remote backends
Derived comparison from current official OpenClaw and Hermes documentation. Both systems contain gateways and agent loops.


Both systems assemble context, preserve identity, load procedures, route capabilities, and decide when a person must approve an action. Once a controller can do that across months, a new question appears. How do you let every process die without losing the logical agent?

Long-running means recoverable, not continuously alive

A container that stays alive for twenty-four hours has solved a timeout, not long-running agency. It does not preserve the agent’s interpretation of the task, prevent a retry from repeating an external action, or prove that resumed work is still valid. There are at least four kinds of continuity to preserve: filesystem state, process state, workflow state, and semantic state.

Keeping one does not magically recover the others.

Anthropic’s Managed Agents architecture is a great case study here. An early design placed the session, harness, and sandbox in one container. The redesign stores the session in an external append-only event log, makes the model/tool loop restartable, and treats the execution environment as replaceable. A failed harness can replay events. A failed sandbox becomes a recoverable tool error. Credentials stay outside the boundary executing generated code.

# Illustrative pseudocode derived from published interfaces
events = session.get_events(run_id)
state = replay(events)
hand = sandbox.attach_or_provision(state.workspace)

while not verifier.complete(state):
    context = harness.compile_context(state)
    action = model.next_action(context)
    session.emit(run_id, Proposed(action.id, action))
    result = hand.execute(action, idempotency_key=action.id)
    session.emit(run_id, Observed(action.id, result))
    state = reduce(state, action, result)

The most important sentence in this section is that the durable object is the history of accepted facts and effects, not the process currently interpreting it. Once you make that distinction, compute can sleep, restart, or move while the logical agent survives.

This durable history is a combination of things like:

  • Persistent disks
  • Memory snapshotting
  • Durable timers
  • Addressable user identities
  • Workflow retries

Each preserves a different part of the system and are NOT interchangeable.

That begs the question: what actually deserves a checkpoint to save all of the above?

There’s a few approaches in the wild:

  • Crab checkpoints only turn out to create recovery-relevant operating-system state, reporting recovery correctness rising from 8% for conversation-only recovery to 100% while reducing checkpoint traffic by as much as 87%.
  • One company I’ve worked with (kept anonymous for privacy) stored every turn in a graph-based DB, which made recovering state/processes convenient especially for branched convos. While more expensive at the data layer, it provides an excellent detailed substrate for testing memory techniques like Lossless Context Management and constructing prod-derived datasets to test their efficacy.
  • DeltaBox attacks the complementary cost problem, reporting 14 ms checkpoints and 5 ms rollback through copy-on-write filesystem deltas and incremental process dumps. This enables alternate world states to support exploration or reinforcement learning without being confused with controller state.


The point is: separating state and execution made it useful to standardize the edge between them. The Model Context Protocol standardizes discovery and invocation of external capabilities while event graphs and agent protocols standardize parts of orchestration. These make tools and runtimes replaceable, but replacement is not correctness. Connectors let agents do more but the harness still decides which actions are admissible, what must be recorded, and what evidence closes the loop.

Co-adaptation with models.

So far I have held the model fixed and changed the controller around it. Modern model training closes the opposite loop. The harness defines the sequence the model experiences: observation, allowed action, tool result, state transition, and terminal condition. It records the resulting trajectory. This means the harness is not only an inference wrapper but also the model’s curriculum and data-generating environment.

This is different from training on isolated answers because changing the harness changes the data distribution. In one observed result, long-context, multi-turn software-engineering RL trained against a stateful repository that responded after each action and improved from a 20% rejection-fine-tuned baseline to 39% on SWE-bench Verified under the paper’s scaffolding.

The result is co-adaptation or simply, that models appear to be post-trained alongside their harnesses. A model trained behind one shell syntax, observation compressor, retry policy, or verifier learns the distribution created by that harness. Put it behind a different interface and apparent capability may fall (which explains why some users have complained that open-weight models that seem to forgo this process are far less effective in neutral harnesses like Pi).

The knowledge did not necessarily vanish, but the action grammar and feedback process changed. The reverse is also true: improving the harness changes the trajectories used to train the next model. Better interfaces produce cleaner experiences and thus more “relevant” data. Post-training internalizes recurring behavior letting the next model=harness operate at a higher level of abstraction.

I will take a second to recognize an interesting tidbit surfaced by Kevin Yang at Fleet: at least one model company/provider has made an attempt to posttrain their models to improve compatibility across harness providers AND general model capabilities of understanding what it means to be an “agent”. The recent release of Qwen3.8 shows that their post-training jointly varies task, workspace, harness, skills, verifier, etc with a shared reward system instead of post-training the model with a fixed harness over a task corpus. At a metalevel, this indicates a focus on having a model that generally learns how to work with different tools, skills, etc. to get tasks done versus how to work really well with one environment.

Cross-Harness Generalization Performance chart shared in Kevin Yang’s linked post

I imagine that for OSS model providers without strong harnesses/widely adopted harnesses of their own vis a vis OpenAI/Anthropic, this will become generally more important.

Nonetheless, this has led to two separate learning loops. One, which we just covered, is agentic post-training changes the model weights using trajectories produced by a harness.

The other is harness optimization which keeps the model fixed and changes the external controller using traces from that model. Both can learn from the same evidence, but they change different objects and need separate evaluation.

Autoharnesses

Engineers traditionally tuned the harness by hand. But if durable event histories give us a better signal and traces can tell you whether the controller failed (wrong policy retrieval, bad tool description, etc) then it stands to reason the external program becomes something we can optimize systematically. This is harness optimization.

The easiest object to change is text. GEPA samples a textual module from an instance-wise Pareto archive, studies its trajectories using natural-language feedback, proposes a mutation, and preserves changes that help particular examples. In plain English, it turns failed runs into a better instruction without changing model weights or runtime code. A held-out set still decides which version survives:

parent = pareto_archive.sample(dev_instances)
traces, feedback = execute(parent, dev_minibatch)
diagnosis = reflect(traces, feedback)
candidate = mutate_text(parent, diagnosis)

dev_scores = evaluate(candidate, development_set)
pareto_archive.update(candidate, per_instance=dev_scores)

selected = choose_on_held_out(pareto_archive, validation_set)

GEPA reports 6% on average over GRPO, with up to 35× fewer rollouts across the evaluated tasks. But text is also its boundary: rewriting an instruction cannot add a missing tool, encode a reusable multi-step contract, or repair brittle control flow.

Text can only take us so far, so the next object is the procedure itself. SkillOpt turns scored trajectories into edits to a bounded skill artifact. An evaluation gate accepts or rejects the patch, and accepted skills become versioned state. The procedure stays cheap to deploy because it is loaded only when relevant. More importantly, it acquires the things Voyager’s skill library pointed toward: tests, provenance, versions, and rollback. At this point optimization starts to look more like release engineering than gradient descent.

FIGURE 5

A gated skill update

OPTIMIZER BOUNDARY TRACES FAILURE EVIDENCE SKILL PATCH ADD · DELETE · REPLACE SEALED EVAL HELD-OUT ACCEPT / REJECT SKILL VERSION n+1 REJECTED HISTORY
Derived from SkillOpt. The held-out evaluator sits outside both the artifact and optimizer; rejection remains visible and accepted state is versioned.


The sequence is now `prompt text → skill artifact → workflow code`. Meta-Harness reaches the last step by giving an outer agent access to source, traces, and scores so it can change the code that constructs state for the inner model. In other words, the harness’ code itself becomes the object to train over. This is more powerful for exactly the reason it is more dangerous. The optimizer can change which evidence the model sees and even the rule used to declare success. As the target widens, held-out tasks, versioning, rollback, independent evaluation, and human review all need to get stronger.

OpenClaw and Hermes show this idea moving toward product systems. They also show why proposal and deployment must remain separate. OpenClaw’s Skill Workshop is explicitly a proposal for placing generated changes in a hash-bound, scanner-gated queue before an explicit apply step. Hermes Agent Self-Evolution is a separate experimental repository exploring GEPA-generated variants with tests, size limits, semantic checks, and pull-request review. They do not show that autonomous self-improvement is solved. If one system writes, executes, and grades its own change, it has built a very elaborate way to agree with itself. Yet the constraining factor in many cases (and certainly through my own experimentation) is largely still data/benchmark/evaluation constrained.

Recursive harnesses change the problem presented to the model

Taking a step back, there’s another relevant problem on the horizon: how can harnesses be helpful in dealing with difficult tasks that require large quantities of data to reason over that might otherwise blow up context windows? Alex Zhang and Omar Khattab describe the frontier as compositional generalization. A good harness does more than provide capabilities. It decomposes an unfamiliar global state into local observations resembling tasks the model already knows how to solve.

Recursive Language Models externalize a large prompt as a variable in a REPL. The root model writes programs that inspect, slice, and transform that variable. Only selected fragments enter recursive model calls, while intermediate results remain in program state. This is not ordinary chunking because the model decides what to inspect as computation unfolds:

long_prompt = ExternalVariable(source)   # outside context
notes = {}

schema = repl.inspect(long_prompt, keys_only=True)
for query in root_model.plan(schema):
    window = repl.slice(long_prompt, query.selector)
    notes[query.id] = subcall(query.task, window)

return root_model.synthesize(notes)

The RLM paper reports tasks with inputs up to 100× the model’s context window. Recursive Agent Harnesses extend recursion from model subcalls to complete agent instances with fresh contexts and tools. With GPT-5 as the backbone, RAH reported 81.36 on the 199-sample Oolong-Synthetic setting, compared with a previously published 71.75 Codex baseline. The matched backbone makes the harness a plausible source of the gain, but the baseline was imported rather than rerun as a paired per-instance experiment; the result should not be generalized beyond that long-context synthetic setting.

The intuition here is that two tasks can look completely different in their surface tokens while sharing the same procedure: filter, search, map, compare, synthesize. A harness can keep domain-specific state inside external variables or subagents and make the root trajectory look similar across both tasks. Training and prompting then operate over a smaller set of reusable strategies instead of every possible surface form.

unfamiliar global task ↓ control-plane decomposition sequence of locally familiar observations

This gives us a simple way to read the entire history. This also follows naturally:

WebGPT decomposed the web into a small action vocabulary → ReAct made arbitrary tools conform to one recurring transition → Skills compressed successful trajectories into callable procedures → Coding harnesses turned repositories into bounded inspection, mutation, and test operations → RLMs turn huge state into selective local programs.

At each step, the harness makes the next problem look more familiar to the model.

The emerging system is a loop of loops

So what is the best harness today? Unsurprisingly, it depends. Coding systems can rely on files, tests, and rollback. Browser and personal agents need hybrid perception and approvals that reflect real-world consequences. Research agents can parallelize read-only branches. A runtime tuned for one model may expose the wrong tools or reminders to another.

A common control-plane shape is nevertheless emerging across things like intent, policy, durable artifact graphs, independent verifiers, etc.

FIGURE 6

An agent system as nested control loops

INTENT · POLICY · BUDGET HARNESS / CONTROLLER SCHEDULER + CONTEXT COMPILER SELECT STATE · SKILLS · TOOLS · AUTHORITY ENVIRONMENT / EXECUTION CODE / API WORKER STRUCTURED MUTATION RESEARCH WORKERS PARALLEL EVIDENCE GUI / WORLD WORKER HYBRID PERCEPTION · APPROVALS DURABLE ARTIFACT GRAPH + EVENT HISTORY FILES · RESULTS · EFFECT IDS · PROVENANCE · CHECKPOINTS INDEPENDENT EVALUATOR VERIFIER ACCEPTANCE + AUTHORITY COMMIT · REPAIR · BRANCH · HUMAN NEXT COMPILED CONTEXT OPTIMIZATION + PROMOTION TRACE OPTIMIZER PROMPT · SKILL · CONTROLLER PATCH SEALED EVALUATOR HELD-OUT · VERSIONED · ROLLBACK PROMOTION ACCEPTED CONTROL-PLANE STATE PROMOTED CHANGES ENTER THE NEXT RUN · REJECTED CHANGES REMAIN IN HISTORY
Illustrative synthesis, not a product diagram. Red marks state construction, task acceptance, and promotion gates; environment, controller, and evaluator remain distinct.

The frontier is a moving boundary

With so much happening across the harness stack and the rise of co-adaptation, this leads to interesting questions: which harness primitives should eventually become part of the model product, and which must remain outside it?

Reasoning loops, compaction, recursive decomposition, and RLM-style interaction with external states may belong to the first group. The obvious experiment is to test each primitive across models, tasks, and environments while holding the rest of the system fixed. A primitive that transfers broadly, survives model upgrades, and improves post-training trajectories is a candidate to migrate behind the API. Providers can train models inside it until users experience the combined system as simply “the model”.

On the other hand, things scoped to a specific “world” i.e. an enterprise or a private codebase are unknowable at training time. Repository conventions, tool availability, organizational policy, current user state, and acceptance tests look more like irreducible last-mile specification. The problem here is diffusion. How can motivated teams get access, or extend current harnesses to adapt to a given “world”? This is likely not purely reducible to a R&D problem, but rather a function of having the right of access and trust to those worlds. A great example is Thrive and OpenAI’s work via Thrive Holdings on Self-Improving Tax Agents, which requires both applied AI engineering expertise and access to actual human tax practitioners to scope and improve harnesses to their “world”.

This gives harness engineering two concrete directions. One is to discover general cognitive primitives and measure when they should move inward. The other is to find the minimum sufficient harness for a particular world.

There is a second boundary moving at the same time: opacity. We have long accepted that the weights of a closed model are opaque. They are the lab’s artifact. A session is different, however It is jointly produced from the user’s instructions, the model’s decisions, retrieved evidence, tool effects, and sometimes days of accumulated work. Yet opacity is spreading outward from the model into that shared record.

The completion APIs of the GPT-3 era were limited but legible. Save the prompt and response and you hold most of the semantic session. New agent APIs increasingly return only a view into a larger provider-owned process. Encrypted reasoning, opaque compaction, hosted search context, server-side conversation IDs, and sealed subagent messages may improve privacy, continuity, and efficiency. The problem is not that these mechanisms exist but that opaque objects are trending to becoming the sole carrier of meaning. At that point the transcript is no longer a useful session to anyone but the model provider’s ability to reconstruct it. Earendil calls this provider-sealed state.

This creates two frontiers. The provider-native frontier optimizes capability: co-trained reasoning formats, private state, cache routing, and compaction that an external controller cannot reproduce.

The portable frontier optimizes custody: whether another system can inspect what happened, recover the evidence, and continue the work without asking the original provider to decrypt its past. The two need not be enemies. A strong API could return both a sealed continuation capsule for maximum same-provider performance and a readable handoff record for audit and migration. The relevant measurement is the portability tax: how much capability is lost when the session must remain intelligible outside the provider that ran it?

The future harness therefore has a narrower but harder job. It must hold the current state of the world, the permissions under which an agent acts, the evidence that work is done, and the provider-neutral record of what the system saw and changed. Harness evaluations should measure not only task success, but inspection, export, replay, audit, deletion, and recovery after the original provider disappears. General cognitive machinery will keep moving inward. The external harness may do less of the thinking, but it must retain custody of the work.

Special thanks to Maanav Khaitan, Kevin Yang, Samay Shamdasani and Akilesh Potti for reviewing and providing feedback on this article.

Sources and scope

Quantitative claims link directly to primary papers or official engineering sources. Product descriptions reflect public documentation available on August 3, 2026. “Observed” labels identify reported measurements; “Derived” labels mark cross-source synthesis; “Illustrative” labels mark proposed architecture.