Definition
The loop a decision model needs
System One Harness is open-sourced by HarnessRouter, under Apache 2.0. This page explains what a System One harness is, what the loop has to do, and why it comes out differently from a harness built for a model that writes.
Start with the general word. A harness is the loop around a model that turns single answers into finished work: it holds the state, decides what to ask, runs what the model chose, recovers from failure, and knows when to stop. That much is true whatever the model is, and what is an agent harness covers it.
A System One harness is that loop built for a model that answers typed questions rather than writing text. Because the model cannot describe what it wants to do, the harness has to enumerate what is possible first, ask about it in a form the model can answer, and then judge the probability that comes back before doing anything in the world.
The model side of this is covered in what is a System One model. In one line: you define the permitted options, levels or proposition in advance, and the model returns a typed value with probabilities.
What changes
The harness lists what is possible; the model picks
In a text harness the model proposes. It writes something shaped like a tool call, and the harness parses, validates and sometimes asks again. Schema enforcement has narrowed that gap where providers offer it, but the direction of travel is the same: structure is recovered from what the model produced.
With a decision model the direction reverses. The harness sends the structure first. Each step it works out which actions are currently possible, turns the choice between them into one question, turns every parameter of every possible action into its own question, and asks whether the goal is already met. The model answers all of it at once, and the harness reads the answers belonging to the action that was chosen.
The practical consequence is that feasibility stops being an instruction. An action that cannot be taken right now is simply not offered, rather than offered with a rule saying not to take it. There is no prompt asking the model to please not do the thing, because the thing is not on the menu. Judgment still lives in language: what each action means and when it applies is written into the questions, and that copy is where the accuracy comes from. What remains true is that the menu is only as accurate as the state the environment reports, which moves the hard problem from prompt design to environment design.
- A parameter has to be answerable: a fixed set of choices, a set the environment enumerates fresh each step, a yes or no, or a score over named levels.
- A free-text parameter cannot be answered by this kind of model at all, so a well-built harness rejects it when it first reads the action definitions, rather than discovering it halfway through a run.
- An optional parameter needs a second question asking whether to supply the value at all, and is left out when the answer is no, or filled with a default where the action space defines one.
The loop
What one step does
The set of actions available, with their parameters and how risky each one is, is the action space, and the loop rereads it every step because what is possible changes as the world does. Each step then does the same six things in the same order.
| Step | What happens |
|---|---|
| Observe | The environment reports its state as text and structured fields, and enumerates any lists the actions draw on |
| Compile | The action space becomes questions, with infeasible actions left out rather than forbidden |
| Encode | Goal, instructions, observation and bounded history become the state, trimmed in a recorded order to fit the model's limits. Jev has two at once: 64k tokens for the whole request, and 32k for the state plus the longest question |
| Decide | One request. Every question is answered in parallel |
| Gate | Every answer the step depends on has to clear a threshold set by the action's risk level, measured with the statistic you chose deliberately: an option's probability, a yes-or-no probability, the concentration of the distribution, or something else derived from it |
| Execute | The environment runs the chosen action and reports what happened |
These models have a bounded state and lose accuracy when that state carries material irrelevant to the question, so what the harness leaves out of the encoding step matters as much as what it puts in. A harness that silently truncates is hiding the variable that most affects the answer; one that records every cut lets you find it later.
The gate
Deciding whether the answer is good enough to act on
This is the part that a text model's API does not usually give you directly. Every answer arrives with a probability, so the harness can set a bar and refuse to act below it, and the bar does not have to be the same for every action. Reading something costs little if it is wrong. An action that cannot be undone is worth more caution.
A refused step is not a failure to be retried quietly. It executes nothing, and it should be recorded with the whole distribution the model returned, because that record is the evidence for whether the bar is set correctly. A run that stops this way is a handover point: a person, or a larger model, can pick it up knowing exactly where and why it stopped.
Two design notes that are easy to get wrong. First, gate on the statistic you mean: for a choice, the probability of the selected option and the confidence of the whole distribution are different numbers, and they disagree in exactly the cases you care about. Second, when refusals repeat, look at the state before you look at the bar. A question can come back uncertain because the options overlap, because it is really two questions at once, or because the state never mentions what the goal asks about. Only the last of those is fixed by making the environment state its own facts, including the ones that are currently false, but it is common enough to check first, and lowering the bar would have hidden any of the three.
Environments
What the loop can be pointed at
An environment is anything that can report a state and execute an action. In practice three shapes cover almost everything.
The first is a process with a narrow interface: reset, observe, execute, close. Any simulator or internal system can be wrapped this way, and the narrowness is the point, because it keeps the harness from depending on anything specific to one system.
The second is a Model Context Protocol server, which many teams already run. Its tools become actions, and the annotations that mark a tool read-only or destructive can seed the risk levels. Worth knowing: the protocol tells clients to treat those annotations as untrusted unless the server is, so on a server you do not control they are a starting point for review rather than a safety boundary. A server also has to expose some way of observing state, since a list of tools alone tells the loop what it can do but never what is true.
The third is a web page, read into an indexed representation where every control is numbered. Numbered controls become the lists the model chooses from, and text a form needs is supplied as named values the model selects by name rather than composing. The boundary here is honest and worth stating: a page that draws itself on a canvas gives a reader of the document almost nothing, and no general adapter can invent the state such a page never exposes.
In practice
An implementation you can read
System One Harness is built and open-sourced by HarnessRouter, under Apache 2.0, and the source is at github.com/HarnessRouter/SystemOneHarness. It compiles an action space into questions, gates by risk level, drives a process, a Model Context Protocol server or a web page, and serves itself over the Unified Harness Protocol so a host can run it without knowing what is inside. The announcement, with the measured runs behind it, is in System One Harness is open source.
The reason we care about this shape is not the model. It is that a contract above harnesses is only worth having if something genuinely different can arrive underneath it without the product above changing. HarnessRouter is the world's first unified interface for agent harnesses. That interface is the full product-backend contract: task execution, sessions, files, streaming and returned results, across complete harnesses from different vendors. A loop driving a model that writes nothing is a fair test of whether that contract was drawn in the right place.
FAQ
Common questions
How is a System One harness different from an agent harness for a text model?
The loop has the same job, and two parts of it change. The action space is compiled into questions and sent to the model rather than recovered from what the model wrote, so infeasible actions are omitted instead of forbidden. And every answer carries a probability, so the loop can require a threshold before acting and record a refusal when it is not met, which a text harness has no direct equivalent for.
Is a System One harness just a wrapper around a classifier?
Classifying is one call. This loop carries state from one step to the next, recomputes what is possible as the world changes, decides whether an answer is good enough to act on, runs it against something real, and works out when to stop. The model call is the smallest part of it.
Do I need a special model for System One Harness?
Yes, in the sense that the loop assumes typed answers with probabilities and refuses free-text parameters. A text model can be asked to imitate the shape, but you would be paying generation cost and latency for a structure the loop already knows, and you would not get calibrated probabilities to gate on.
What happens when a System One model is not confident enough?
The step executes nothing and is recorded with the distribution behind it. After repeated refusals a well-built loop stops and names the reason rather than carrying on. An environment whose world keeps moving on its own is the exception: there a refusal means the last action stands for another tick, not that the run should end.
Can System One Harness drive any MCP server?
Only one that also exposes state. A tool list tells the loop what it can do, not what is currently true, so the server needs an observation the loop can call each step. The parameters also have to be answerable: enums, booleans and small bounded numbers compile cleanly, while free strings, arrays and nested objects do not and should be reported as unsupported rather than quietly dropped.
Put a harness behind your product
Run complete agent harnesses through one contract for tasks, sessions, streaming and artifacts, and keep the harness a request parameter rather than an architectural commitment.
Start building free