The Question Stops One Step Short

A founder is asked, in the same meeting, whether a new agent should run on the company's own hardware or through an external model. The discussion that follows is about data residency, vendor terms, and which model is currently ahead. Those are real decisions. They are not the whole design.

The agent in question already behaves like many others. It reports that the job is done, and the tests never ran. It is sharp for twenty minutes, then a rule given at the start of the session is gone. Someone retypes the same three instructions the next morning. An approval sits waiting, and the work cannot be left alone.

Moving that model into the building does not write the missing rule. Sending the same work to a stronger external model does not write it either.

This is a hypothetical, but the pattern is familiar. The board is being asked to choose a location for a worker whose job has not been specified.

You Already Have a Harness

An agent is the model plus the program around it. Researchers call that program the harness: the executable layer that organizes model calls, tool use, and the flow of information [1]. It decides what the model sees, which tools it can call, and how a run proceeds.

Six decisions sit in that layer [2]:

• 1
  The loop

  What keeps the agent going, and where it stops.

• 2
  The tools

  What the agent can see and call.

• 3
  The memory

  What is allowed to remain in context, and what gets compressed away.

• 4
  The persistence

  What survives a crash or a new session.

• 5
  The permissions

  What the process is allowed to touch.

• 6
  The definition of done

  Who is permitted to say the job is finished.

Vendors build part of this. They own the default loop, the built-in tools, and much of the memory handling. The rest is yours whether or not anyone designed it: the instructions file, the tests, the permissions, and the definition of done. Every rule someone keeps pasting back into a chat is already part of the harness. It has simply never been treated as one.

The name is recent. Anthropic was publishing guidance on harnesses for long-running agents by late 2025 [3], and the vocabulary settled across the industry over the following months. The layer itself is older than the name, and while it had no shared name it went unmanaged. A company can have a model policy, a vendor review, and an AI committee, and still have an agent whose only definition of done is that the agent said so.

The Solver Can Stay Frozen

A paper published in September 2026 by Zhang and colleagues treats that split as something that can be improved on purpose [1]. A language-model agent, in their formulation, is jointly defined by its model and its harness. Different tasks need the harness organized differently, so they train a second model, a proposer, to revise the harness from execution feedback. The model that does the task, the solver, stays fixed. At test time both models stay frozen. What changes is the program.

The proposer reads the task, the current harness, and a short report of what failed. It writes several edits. Each edit is run. The one that scores best on held-out questions is kept. Feedback, scoring, and final evaluation use separate questions, so the number you report is not the number you tuned on.

Two results matter here. On reasoning tasks the proposer had never seen in training, the average quality of a single revision roughly doubled after training, from 0.32 to 0.62. The share of proposed edits that failed to run or scored zero fell from 38 percent to 15 percent. The trained proposer was a 4 billion parameter model, and on those same tasks its average revision outscored the larger teacher model it had learned from.

The limit belongs next to the result. The solver doing the reasoning tasks was itself a 4B model. The gain is in the quality of the edits to the wrapper. It is not a small solver replacing a frontier model on your workload.

In a second experiment the split is clearer. A 4B proposer revised the harness of an 8B solver on multi-hop questions, and a proposer trained on one benchmark kept improving harnesses on two benchmarks it had not seen. Two different models. One harness. The solver never had to change for the system to get better.

That is the result a board can use.

What You Actually Own

The research shows that a learned edit can transfer to tasks the editor has not seen. A company still has to decide which edits it is willing to run. The practical version is short, one item per decision. It comes from people who have had to leave an agent alone, not from a leaderboard [2][3].

• The loop: a stopping rule in one sentence

  Write it before the run starts. Make it a check a person can observe: the test suite passes and the application boots. The agent's own announcement is a status message, not that check.

• The tools: one short instructions file

  Keep it short enough to be read, pointing at the real documents rather than trying to contain them. When the same failure has happened twice, turn it into a check that fails the build. A paragraph that asks the model to be careful gets skipped. A failing check does not.

• The memory: rules that must not be summarized away

  Never touch production. Never commit a secret. This contract is fixed. Facts can be compressed when the context window fills. Those rules cannot. Put them in a file the agent re-reads after every reset, and repeat them where the session starts.

• The persistence: four files the next session can read

  One says what you are building, and the agent does not edit it. One lists the steps, each with an acceptance criterion a test can assert. One records what is finished, what is next, and what was already tried. One is append-only: decisions already made, and why. If it is not in a file, the next session will argue it again.

• The permissions: the narrowest tools, in a sandbox, with credentials that expire

  Production access is granted per task, not per agent. A model that can see your keys and your session will eventually use them in a way nobody asked for.

• The definition of done: an evaluation set built from failures you have already paid for

  Twenty real tasks from your own work is enough to start. Run each one more than once, and judge the worst run. A single green demonstration is a weak signal from a system that does not do the same thing twice. Separate the questions you learn from, the questions you use to keep or discard an edit, and the questions you report once. That split is the method in the paper [1]. It is also the only way a number shown to the board stays honest.

The sixth decision already has an owner. In the accountability review, every consequential AI use case gets one named business owner who decides what the system is allowed to do and when it has done it. The definition of done is that person's call. The harness is where it gets written down.

A designed harness costs more per run than an agent left to stop itself [2]. It earns that cost on work you could not otherwise hand off.

Local and External Are Both Solvers

The same harness can name either kind of solver.

The paper's frozen solver is the useful idea here. The harness names the model. It does not have to name the same model for every task, and that model does not have to live in the same place. Route by what the task is allowed to expose.

The instructions, the stopping rule, the tool gateway, the evaluation set, and the definition of done stay in the repository either way.

Changing vendor, or bringing a workflow back in house, is then a configuration change. Rebuilding the operating rules from a chat transcript is what you do when the harness was never written down.

One front door makes the split real. Put an interface both models can answer behind the harness, and keep the routing policy there rather than in whoever last edited a chat setting. A task declares its data class and receives the endpoint that class allows. The scoring set from the paper is how you justify the route. Run the task class on both endpoints. Keep the winner on development questions. Report once on questions neither side was tuned on. A local model that loses that comparison stays off that task. An external model that only wins by seeing data it is not allowed to see is not the winner.

Placement Changes Who Can Read the Prompt

Location answers one question. The other decisions remain, and they change shape with the placement.

Local model. You own the loop, including the cap on turns and the log of what happened. Tool descriptions can stay on disk until a task needs them. The transcript stays on your side, and it can still be summarized badly. A crash still destroys anything that lived only in the conversation. A sandbox and short-lived credentials still matter, because a model on your network can see your keys, your session, and your internal tools.

External model. The vendor owns the inner loop. You still own the cap, the rule for a bad ending, and a log of what you sent. Every tool description and tool result may be retained by the provider unless the contract says otherwise. The transcript also exists in someone else's logging pipeline. The files in the repository are still what survive a crash. Egress is the permission boundary: the provider should receive only what you are willing to send, and the retention terms should be in writing. The vendor's public benchmark is not your release gate. Your evaluation set is.

The risk moves with the placement. An external model creates a disclosure, residency, and continuity problem. The context is a copy of the work on infrastructure you do not operate, and a poisoned page inside that context can ride back out through the API. A local model creates a capability and a custody problem. A weaker model will improvise when the harness is thin. The host that serves the model becomes something you have to run, patch, and account for. "Nothing left the building" is easy to mistake for control.

A smaller local model is often where harness quality pays first. The paper's comparison fits that reading, inside the limit already stated. A 4B proposer, trained on execution feedback, produced better average revisions than the teacher it learned from. The teacher remained ahead when the best attempt could be picked after the fact. If the local model is the one you are willing to trust with the data, spend the next quarter on the harness and the evaluation set before you spend it on a larger model you cannot place there.

What Boards and CEOs Should Ask

Boards do not need to review harness code. They do need evidence that the wrapper was chosen, and that the model's location follows from the data.

For each material agent workflow, ask:

• What is the harness, and where does it live?

  If the answer is the chat product, it has not been designed.

• Which solver runs the work, and where does that solver run?

  Local and external are both acceptable answers. "Whichever the tool picked" is not.

• What data class may reach that solver?

  State what is forbidden to leave the building in the same sentence as what the agent is allowed to do.

• What sentence defines done, and whose name is on it?

  It has to be something other than the agent announcing that it is finished, and it has to be the business owner's sentence.

• Who can pause the run?

  And which file would a new session read after a crash?

• Which held-out tasks justify this model in this place?

  When were they last run against the other placement?

• What happens to the harness when the model, or the vendor, changes?

  The answer should be a configuration change, not a rewrite.

The board-level question is whether the company owns the program around the model. The model will move. The place it runs will move. The harness is the part that should still be there.

A Practical Starting Point

Do not begin by standing up a platform, or by relocating every workflow onto hardware you operate.

Start with the five most consequential agent workflows already in use or closest to it. It is the same short list as the accountability review for any workflow that can already act. For each one, write the stopping rule in a sentence. Name the solver and where it runs. Assign the data class and list what must not cross that boundary. Pin the rules that have to survive summarization. Put twenty failures you have already seen into an evaluation set, split into feedback, scoring, and a final check you touch once.

Run that set on the local endpoint and the external one before the next vendor conversation. Keep the harness files in the repository the work already lives in. A new session should be able to read them without inheriting the previous conversation.

This is an afternoon per workflow, not a transformation program. It will show which agents are a designed system and which are a model with a memory of old instructions.

Conclusion

In the opening meeting, the choice was presented as local or external. Residency, cost, and model quality all belong in that conversation. None of them specifies the job.

The company already has a harness. It is the accumulated one: rules retyped at the start of a session, approvals clicked through, a definition of done that means the agent has stopped talking. Those decisions were made. They were not made on purpose.

A local model and an external API are both solvers. Put the same instructions, the same tests, and the same permissions in front of either. Route by what the task is allowed to expose. Judge both on questions you did not tune on.

Sources and Further Reading