The harness paradox

The harness paradox is AR Labs' name for an observation about AI agents (language models run in a loop with tools, so they can act, not only reply): the more precisely an agent's goals, context, output and boundaries are specified, the more useful its independent work becomes. Autonomy is commonly treated as the goal of agent design. In our experience, useful autonomy comes after a good harness, not instead of one, so anyone designing an agent should build the harness first.

A harness is everything around the model that shapes what an agent does: the agent program, its instructions, skills, hooks, tools and checks. The instructions include the format the output must take, and the hooks are scripts that can block an action. The model supplies capability. The harness decides where that capability goes; harness engineering is the practice of changing it.

Where the idea comes from

We ran two kinds of agent side by side, using frontier models of the same generation and serving the same goals.

One was a heavily harnessed system built on Claude Code: instruction files in every project folder stating outcomes and current approach, a fixed loading order for context, skills that package specific procedures, hooks that run at the start and end of sessions and on tool calls, rules files for communication and safety, and a required response structure.

The other was an always-on agent on an open-source runtime, configured in the loose style common in public demonstrations: a short personality file, daily memory logs, a handful of skills, and a memory plugin, storing facts as a knowledge graph, designed to work invisibly in the background.

The always-on agent produced a useful morning analysis once it was given explicit instructions to follow. Asked about its own memory, though, it described only its plain-text logs. It did not know the knowledge-graph plugin existed, because the plugin had been designed to be transparent, and in practice transparent meant invisible and unteachable: the agent could not query its memory deliberately or reason about what it remembered. The fix was not more autonomy. It was a document that explained the memory system to the agent, how to query it, what its scheduled jobs were for, and what its purpose was. That is context engineering.

Why constraint helps

We see three mechanisms.

A smaller decision space. An unconstrained agent must settle, at every turn, what format to use, how much detail to give, what the goal is and what counts as success. Each of those choices spends effort and adds variance. A harnessed agent starts with them answered, so its effort goes to the actual work.

A smaller error surface. Every choice an agent makes on its own is a chance to be wrong. When the harness fixes format, scope and priority, those errors cannot happen, and failures narrow to the task itself.

Context as cognitive architecture. Our documents load in layers (progressive disclosure), each narrowing what matters in the next. The agent does not process the whole repository; it processes a subset filtered by human design decisions. People work the same way, loading relevant context progressively rather than thinking about everything at once.

The paradox resolves once constraints are seen as information rather than limitation. Each one tells the agent something it would otherwise have to discover or guess. As we put it, the harness is the prompt, distributed across the filesystem. Our comparison is the sonnet: fourteen lines and a rhyme scheme force a precision that free verse never demands, and a good sonnet is enabled by its form rather than limited by it.

flowchart TD
  G["Goals and scoring criteria"] --> H["Harness"]
  C["Context loaded in layers"] --> H
  O["Output format"] --> H
  B["Boundaries and blocked actions"] --> H
  V["Checks the work must pass"] --> H
  H --> M["Model"]
  M --> W["Work focused on the task, not on orientation"]

How we apply it

Autonomy follows trust. We extend independence to agents a step at a time: a phase must succeed before the next begins, and a person merges code into the main branch.

Code owns the decisions that must not drift. In our coding pipeline, a stateless driver reads the recorded state of each task and does whatever that state says comes next; the model writes code, and the pipeline decides when a step is done. In Salesbot, the model holds the conversation while code decides when each stage is complete and when the call ends; we call this structured conversation.

Graph engineering. We design our work and agent systems as dependency graphs in which every node has a contract: one job, structured input and output, and a defined failure state. Routing between nodes is deterministic and inspectable, and verification sits on the edges between them. This is a harness at the scale of a whole workflow.

Layered instructions that cannot contradict. Our logical levels design for an autonomous agent rests on one rule: an inner frame of instructions cannot loosen the limits of the frame around it.

Memory needs a purpose. A memory store an agent does not know about, or has no framework for using, adds noise rather than intelligence. The decisions about what a memory system extracts and when it injects recalled material into context are context-engineering decisions, not infrastructure decisions.

What it does not claim

The harness paradox is not an argument against autonomous agents. The always-on agent in the comparison went on to produce a useful brief each morning once its harness was in place. The claim is about order: design the goals, context, boundaries and checks first, and let autonomy grow inside them.