Definition
A decision model inside a loop built for it
A System One agent is a model that picks the next action, plus the loop that keeps asking it until the job is done. In the names this ecosystem uses: a System One model running inside a System One harness, pointed at something it can watch and act on, and given a goal. The model does one thing, which is to pick what to do next and say how sure it is. The loop does everything else.
Neither half is an agent on its own. A System One model answers questions about one state and stops. It remembers nothing from the last step and cannot touch anything in the world. A harness with no model is a loop with nothing to ask. Put the two together against something that can report its state and carry out an action, and you have a thing that pursues a goal.
The two names are not from the same place. TypeSafe named the model. HarnessRouter named the loop and the pair, and defines a System One agent as exactly this: one model, one harness, one environment, one goal. The open-source implementation below is what that definition is built against.
The halves have pages of their own: what is a System One model for what the model returns, and what is a System One harness for what the loop has to do. What follows is the two of them running.
The other half
The model picks from a list; the loop has to write it
The model can only pick from a list. It cannot suggest anything of its own, because suggesting would mean writing it out, and this model writes nothing. So someone else has to work out what is on the list, ask about it in a form the model can answer, and decide what to do with the answer. That someone is the loop.
- Work out which actions are possible right now, and offer only those. An action that cannot be taken is left off the menu rather than forbidden in an instruction.
- Turn each possible action, and every value each one needs, into a question whose answers are all written out in advance.
- Decide whether the answer that comes back is good enough to act on, using a bar that depends on how much the action costs if it is wrong.
- Run the chosen action against the environment and feed the result into the next step.
- Carry enough of the earlier steps forward to stay on track, without sending more than the model can read, and record anything dropped.
- Know when to stop, and be able to say why.
Finishing and asking for help are items on the list too, because the model has no other way to say either one. Stopping is therefore something the loop chose and wrote down, like any other step, so a run ends with a reason instead of a closing paragraph.
In practice
One run, step by step
This is the example that ships with System One Harness, run against the live model. The goal goes in as a sentence: order B-220 is a gift, so note it, then ship it by the fastest carrier. The command names a built-in environment and that goal; the available actions, their risk levels and the thresholds all come from the example.
| Step | Action taken | Weakest required probability | Model round trip |
|---|---|---|---|
| 0 | add_note(note='gift') | 0.96 | 241 ms |
| 1 | pick_item(item='scarf') | 1.00 | 269 ms |
| 2 | pack() | 0.99 | 166 ms |
| 3 | choose_carrier(carrier='express') | 0.98 | 151 ms |
| 4 | ship() | 0.93 | 152 ms |
The run ended as completed, because the environment reported itself terminal, after five steps, 0.98 seconds of wall time and $0.000208.
The probability column is not one number the model returned. It is the weakest of the judgments the step depended on, and those are two different statistics: the confidence on the choice of action, which describes how concentrated that whole distribution was, and the probability of each parameter value the action needed. The gate takes the lowest of them rather than multiplying them, which is TypeSafe's own rule, and the question it answers is whether any single judgment in the step was shaky.
Every action carries a risk level, and every level carries its own bar. The declaration that sets them, called the action space, ships with the example. In this environment, attaching a note counts as read and clears at 0.5; picking, packing and choosing a carrier count as write and clear at 0.6; shipping cannot be undone, so it counts as destructive and has to reach 0.8. The harness ships stricter defaults, 0.5, 0.7 and 0.9, and any action space can set its own.
Shipping does not always clear that bar. On 2026-09-19 this same environment described an order as packed and named its carrier, but never said in so many words that it had not yet shipped. The model reads literally, so it put a tenth of its belief on finishing and came back on the ship action between 0.73 and 0.84, against a bar of 0.8. Two runs in five ended there, recorded as no_confident_action. The fix was to make the observation state the goal's own predicates outright, including the ones that were false, after which ship came back between 0.86 and 0.93 and five runs in five completed. The gate was never touched.
A run that stops is telling you something about the state, and lowering the bar would have hidden it.
The starter kit
The kit gives you the loop; you supply the environment
System One Harness is HarnessRouter's implementation of that loop, open-sourced under Apache 2.0 at github.com/HarnessRouter/SystemOneHarness, version 0.3.1 at the time of writing. The loop is the open half. The model is proprietary and hosted, so what the kit supplies is the harness plus everything needed to drive Jev with it: install it, set a provider key, and run s1 run --env order:ship_fastest_gift. The run above is what comes back, before you have written anything of your own.
| What ships with it | Why it is there |
|---|---|
| An order fulfilment environment | A small deterministic system to watch the loop work against before you connect one of your own |
| An action space format | YAML, or the same structure in Python. Every parameter has to be enumerable, and a free-text parameter is rejected when the file is read rather than discovered halfway through a run |
| Confidence gates | Read, write and destructive actions carry separate thresholds, 0.5, 0.7 and 0.9 by default, and any action space can set its own; the shipped order example runs at 0.5, 0.6 and 0.8 |
| Four ways to connect a system | A Python class, a program over stdio, a Model Context Protocol server whose tools become actions, or a web page in Chrome |
| Real-time mode | An environment whose world moves on its own can declare itself real-time, and a refused or repeated decision is then treated as a clock tick rather than a stall |
| A protocol server | One command exposes the whole loop over the Unified Harness Protocol, with streaming, continuation and cancellation |
| A trace for every run | State, questions, distributions, gate verdicts, results, latency and usage, recorded step by step |
Your own agent is the same loop with a different environment underneath it. The three things you supply are what your system can do, how much each of those things costs if it is done wrongly, and how to observe the current state. The loop itself does not change.
The hard part moves too. With a text agent the work is prompt design; here it is environment design, in the specific sense the refused runs above demonstrate: the menu is only ever as good as the state the environment reports, and an observation that leaves the goal's own predicates unstated will stall the loop no matter how the thresholds are set.
Side by side
Where this differs from a text agent
Both kinds of agent do the same job. What changes is how much of it the model does and how much the loop does.
| System One agent | Text agent | |
|---|---|---|
| How an action is chosen | The harness lists what is possible and the model picks from that list | The model produces something shaped like a tool call, which the harness parses and validates |
| An action that is not possible right now | Left off the menu, so it cannot be chosen | Usually still available, with an instruction saying not to take it |
| A free-text parameter | Rejected when the action space is read, because the model writes nothing | Filled by the model, which is frequently the whole point |
| What sure enough means | A number compared against a threshold set by the action's risk | A judgment written into the prompt, or inferred from the wording that comes back |
| Why a run stopped | A recorded outcome, completed, incomplete, failed or cancelled, with a structured reason | Usually the model's closing message, read back as a summary |
| What one step costs | One request that reads the state and answers every question at once, priced on what it read | One or more completions, priced on what was written as well as what was read |
A text agent is the right shape whenever the work needs language coming out, or whenever the next action cannot be written down in advance, which is true of a great deal of what agents are built for. The rows are how you tell which shape a given job wants.
They also compose. A System One agent that stops below its confidence bar hands over a recorded distribution and a known stopping point, which is exactly the input a larger model needs to take the task the rest of the way.
Where it fits
What to point it at, and what not to
This suits work that happens often, has few possible answers, and matters little one at a time, against a system whose actions you can list and whose state you can describe in words. Moving an order through fulfilment, routing a ticket, deciding whether a step is done, choosing which tool to call next: decisions your software makes constantly and would rather not wake a person for.
The repository publishes what it measured, in a benchmark report dated 2026-09-19, and the release those runs accompanied is written up in System One Harness is open source. Five runs each across three order fulfilment scenarios on that date all reached their goal, at mean model latency between 197 and 241 milliseconds a step and between $0.000044 and $0.000265 a run. Fifteen completed runs is evidence that the controller, the compiler, the gate and the model finish small deterministic tasks end to end. It says nothing about ambiguous state, arithmetic, dates or long irrelevant context, which are the model's documented weak spots and which the benchmark deliberately leaves out.
The limit worth knowing about sits in the environment, not in the model. The loop can only choose from what the environment reports, so a system that never states its own state cannot be driven by a general adapter. A web page that draws itself on a canvas is the clearest case: the document says almost nothing, and no general adapter can invent what the page never exposes. Driving something like that needs an adapter written for it, which is a real cost to weigh rather than a detail to discover later.
Serving it
Anything that speaks the protocol can drive it
One command serves a configured loop over the Unified Harness Protocol, and the included conformance report passes all 40 checks in the protocol's core class, the baseline set every server has to clear. Goals arrive as input, the selected action and the environment's result stream back as the run proceeds, and the distribution and the gate's verdict travel with them, so a client watching the stream sees the same evidence the trace records.
Serving itself that way is what lets it sit under the same contract as harnesses it has nothing else in common with. 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 product already driving a text harness can drive this one without changing anything above the contract. That is the test such a contract exists to pass, and a harness whose model writes nothing is a fair way to run it.
FAQ
Common questions
What is the difference between a System One agent and a System One model?
The model answers questions about one state and stops. It has no memory of the previous step and no way to act on anything. The agent is the model plus the loop that holds state, works out what is possible now, decides whether the answer is confident enough to act on, executes it against a real system and knows when to stop. The model call is the smallest part of the agent.
Do I need to build a System One harness to build a System One agent?
No. HarnessRouter has open-sourced one, System One Harness, under Apache 2.0, so the loop is already written. Building your own would mean writing the action compiler, the confidence gate, the state encoder that fits inside the model's budget, the terminal-reason bookkeeping and the trace. Those are all in the repository, tested and measured against live runs. The part you do supply either way is the environment: what your system can do, how much each action costs if it is done wrongly, and how to observe the current state.
Can a System One agent use tools?
Yes, and a Model Context Protocol server is one way in: its tools become the actions, and its annotations can seed whether each one counts as read, write or destructive. Two things have to be true of that server. It needs some way to observe state, because a list of tools says what can be done and never what is currently true. And its parameters have to be enumerable, so enums, booleans and small bounded numbers compile cleanly while free strings and nested objects do not and should be reported as unsupported rather than quietly dropped.
What happens when a System One agent is not confident enough?
The step executes nothing and is recorded with the whole distribution the model returned. Repeated refusals stop the run with a named reason rather than letting it grind on. The exception is an environment whose world keeps moving on its own, where a refusal means the last action stands for another tick rather than that the run should end.
Is a System One agent cheaper than an LLM agent?
Per step it is cheaper for a structural reason rather than a tuning one: a single request reads the state and answers every question at once, and nothing is generated, so there are no output tokens to pay for. The order fulfilment runs measured on 2026-09-19 cost between $0.000044 and $0.000265 for a complete run. No comparable text-agent run is published beside them, so read those as absolute figures rather than as a multiplier. And the comparison only arises for work this shape can do at all: if the task needs language out, or its actions cannot be enumerated, the cheaper step is not available at any price.
Can a System One agent and a text agent work together?
That is the arrangement the confidence gate is built for. The fast agent takes the frequent bounded decisions and stops the moment one comes back below its bar, leaving a recorded distribution and an exact stopping point. A larger model or a person continues from there. Running both behind one interface is what makes the handover a routing decision rather than a rebuild.
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