March 2026 · OpenSentience / [&] Ampersand Box Design
The agent model is not the bottleneck. The harness is.
Every major AI lab discovered this independently in 2025-2026. Anthropic found that a harness built for Claude Haiku outperformed raw Sonnet on long-running agentic tasks. OpenAI found that CI invariants — mechanical enforcement — beat prompt-based instructions for code generation. Factory.ai found that context degrades at 60% utilization, not at the limit.
The implication is architectural: spending engineering effort on the system around the model yields more than spending it on the model itself. This is not a temporary artifact of current model limitations. It is a structural property of agentic systems.
OS-008 is the [&] ecosystem's formalization of this insight. It defines the Agent Harness Protocol — the enforcement runtime that sits above agents and below humans, orchestrating pipelines, gating quality, and ensuring that no agent skips retrieval, fabricates provenance, or acts beyond its coverage.
This document argues that harness engineering is an emerging discipline, explains what it is, surveys how the industry converged on it, and positions OS-008 within the field.
Harness engineering is the discipline of designing systems that sit above agents, not below them. A harness controls the agent — it is not a tool the agent calls.
This distinction matters because it inverts the mental model most developers carry. The dominant framing treats the LLM as the center of the system: the agent decides what to do, calls tools, retrieves memory, and self-evaluates. The harness model says: no. The orchestrator decides what happens. The agent is a capability invoked by the harness at the appropriate time, with the appropriate constraints.
Three layers, top to bottom:
┌─────────────────────────────────────────────────────┐
│ HARNESS (above agent) │
│ Controls pipeline order, quality gates, │
│ sprint contracts, context management. │
│ Example: OS-008 │
├─────────────────────────────────────────────────────┤
│ AGENT (the LLM) │
│ Generates, reasons, plans, evaluates. │
│ Invoked BY the harness in a specific role │
│ (planner, generator, evaluator). │
├─────────────────────────────────────────────────────┤
│ TOOLS (below agent) │
│ Memory, deliberation, external APIs. │
│ Examples: Graphonomous, AgenTroMatic, │
│ filesystem, CI/CD, databases. │
└─────────────────────────────────────────────────────┘The harness layer is where reliability lives. Models will hallucinate, skip steps, over-praise their own output, and lose coherence as context grows. These are not bugs to be fixed — they are properties of stochastic generation. The harness compensates for them mechanically.
A harness engineer designs the system that compensates. This is a different skill from prompt engineering (which optimizes the agent layer) and from tool building (which optimizes the tool layer). It requires understanding orchestration patterns, cognitive architectures, quality assurance theory, and context management.
The convergence happened independently across labs, companies, and academia. Nobody coordinated. Everybody arrived at the same architecture. This is strong evidence that the architecture is correct — it was discovered, not invented.
Anthropic's harness research (2026) demonstrated the single most important finding in harness engineering: separating generation from evaluation transforms output quality from non-functional to working.
The key insight: self-evaluation consistently over-praises. When the same agent that generates code also evaluates it, the evaluator shares the generator's context, biases, and blind spots. An isolated evaluator — running in a separate context, grading against explicit acceptance criteria — produces honest assessments.
This is not a refinement. It is a phase transition. Anthropic reported that the three-agent harness pattern (planner/generator/evaluator) was the difference between code that did not work at all and code that passed tests.
OpenAI's Codex harness took a different path to the same conclusion. Instead of prompt instructions ("always run tests before committing"), Codex enforces invariants mechanically: CI must pass before the commit is accepted. The agent cannot bypass this. It is not a suggestion in the system prompt — it is a gate in the runtime.
The finding: mechanical enforcement outperforms prompt instructions by a wide margin. Prompts degrade as context grows. CI gates do not degrade. They are binary: pass or fail. The harness does not care how long the conversation has been running.
Factory.ai's Droids system introduced Sprint(task, success_criteria) as a first-class primitive and eval() as a mandatory step after each sprint. Their critical empirical finding: context quality degrades at 60% utilization, not at the model's stated maximum.
This means that a 200k-token model effectively has 120k tokens of useful context. Beyond that, the model loses track of earlier instructions, contradicts itself, and produces lower-quality output. The harness must manage this — compacting context, delegating to subagents, or resetting with injected retrieval — before the 60% threshold, not after.
LangChain's Deep Agents framework (2025-2026) introduced subagent isolation and filesystem-based memory as harness primitives. When a task exceeds the parent agent's context capacity, the harness delegates to a subagent with a clean context window and a focused task description. Results are written to the filesystem and summarized back to the parent.
The pattern: the harness manages a tree of agents, not a single agent. Each agent operates in a bounded context. The harness coordinates.
The NLAH paper (Natural Language Agent Harness, March 2026) provided the first formal academic treatment of the harness as a portable, language-independent artifact. The paper argues that harnesses should be specified declaratively and transported across runtimes — the same argument the [&] Protocol makes about agent declarations.
NLAH validates the central thesis: the harness is not an implementation detail. It is the primary engineering artifact.
These principles are not opinions. They are empirical findings, each validated by at least two independent sources.
The evaluator MUST run in an isolated context. If it shares the generator's context, it will over-praise. This is Anthropic's transformative insight, and it is non-negotiable.
In OS-008, this is enforced by the QualityGate component. The evaluator is a separate agent role with its own capability contract (&reason.evaluate). It receives the generator's output and the sprint's acceptance criteria. It does not receive the generator's reasoning trace.
Generator context: Evaluator context:
task + plan + prior output output artifact
+ retrieval + reasoning trace + acceptance criteria
(biased toward own work) (isolated judgment)"Retrieve before acting" is not a suggestion. It is a runtime constraint. The PipelineEnforcer in OS-008 blocks write-class tool calls until retrieval completes. The agent cannot bypass this. It does not matter what the prompt says. It does not matter how long the conversation has been running. The enforcer is a state machine, and the state machine does not have a "skip" transition.
This is the lesson from OpenAI's Codex: if you want a behavior to be reliable, make it a gate, not a guideline.
Context quality degrades at 60% utilization. This is Factory.ai's empirical finding, and it matches what every practitioner has observed: long conversations produce worse output than short ones.
The ContextManager in OS-008 monitors context utilization and triggers compaction before the threshold. Compaction strategies include: summarizing completed sprints, archiving intermediate reasoning, delegating to subagents with fresh contexts, and injecting Graphonomous retrieval results into new contexts.
The key insight: context management is a harness responsibility, not an agent responsibility. The agent does not know how much context it has consumed. The harness does.
Each sprint has testable acceptance criteria. The SprintController in OS-008 routes work through a plan-generate-evaluate loop:
Task
|> Planner: decompose into sprints with acceptance criteria
|> for each sprint:
| Generator: produce output
| Evaluator: grade against criteria
| if fail: iterate (with evaluator feedback)
| if pass: commit + next sprint
|> Complete
|> Learn (store outcomes in Graphonomous)Bounded sprints serve two purposes. First, they keep each generation step within the context quality threshold. Second, they make progress legible — each sprint either passes or fails, and the harness can report exactly where the task stands.
When the harness compacts context or delegates to a subagent, knowledge must survive the transition. This requires persistent memory — not just what's in the current context window.
OS-008 integrates with Graphonomous (OS-001) for this. Before compaction, the harness stores key decisions, intermediate results, and open questions as knowledge graph nodes. After compaction, the harness retrieves relevant context from Graphonomous and injects it into the fresh context.
This is the difference between a harness that manages context and one that merely truncates it.
Not every agent should act autonomously from day one. OS-008 inherits the three autonomy levels from OS-006 (the governance shim):
| Level | What the agent can do | Harness behavior |
|---|---|---|
| observe | Read-only. No state modifications. | Harness logs dispatch decisions but does not execute. |
| advise | Propose actions. Human approves. | Harness queues proposed actions for review. |
| act | Execute within policy bounds. | Harness executes and audits. |
Transitions between levels are policy-driven (defined in the [&] governance block) and audited. An agent earns autonomy through demonstrated reliability — tracked by Graphonomous confidence scores — not through configuration changes at deployment time.
Every harness in Section 2 implements some subset of the six principles. OS-008 implements all six plus six additional capabilities not found in any current harness.
Industry harnesses use the filesystem (LangChain Deep Agents) or ephemeral state (Anthropic, OpenAI Codex) for cross-sprint memory. OS-008 uses Graphonomous — a knowledge graph with typed nodes (semantic, procedural, episodic), weighted edges, confidence scores, and multi-timescale consolidation.
The difference is structural. A filesystem stores files. A knowledge graph stores relationships. When the harness needs to decide "what does this agent already know about authentication?", a graph query returns semantically connected nodes with confidence weights. A filesystem ls returns filenames.
OS-008 uses the kappa invariant (OS-002) to decide whether deliberation is needed. If a query's subgraph has no feedback loops (kappa = 0), it follows the fast DAG path: retrieve, act, store. If feedback loops exist (kappa > 0), deliberation is structurally required — the decision's outcome will propagate back to the nodes that informed it.
No other harness computes this. Industry harnesses either always deliberate (wasteful) or never deliberate (dangerous). kappa-routing makes the decision mathematically: either the topology warrants deliberation or it does not.
Before the harness dispatches an action, it queries the agent's epistemic state via Coverage.recommend/2. The coverage assessment determines routing:
Coverage decision kappa Autonomy Dispatch
----------------- ----- -------- --------
:escalate any any escalate (always)
:learn any any explore or deliberate
:act > 0 any deliberate (kappa-driven)
:act = 0 :act execute
:act = 0 :advise defer (needs approval)
:act = 0 :observe log onlyThis is epistemic self-modeling: the harness knows what the agent knows before deciding what the agent should do. No other harness has this capability.
OS-008 validates [&] governance blocks at both composition time and runtime. A governance block declares:
hard constraints (must be enforced, never overridable)
soft preferences (enforced by default, overridable with justification)
escalate_when conditions (triggers human review)
autonomy level and heartbeat cadence
The ContractValidator ensures these are satisfied throughout execution. If a hard constraint is violated, the harness halts the session. If a soft constraint is violated, the harness logs the justification and continues. If an escalation condition is met, the harness pauses and notifies.
These contracts are portable — they travel with the agent declaration, not with the runtime. An agent governed by OS-008 on one platform carries its governance rules to any other [&]-compatible platform.
Section 3, Principle 6 introduced the three autonomy levels. OS-008 adds the transition mechanism: agents move between levels based on policies defined in the governance block, not based on ad hoc configuration changes.
A policy might say: "After 50 successful sprints with zero quality gate failures, transition from advise to act for file modification operations." The harness tracks the metrics. The harness makes the transition. The harness audits it.
OS-008 is explicitly modeled on the Supervisory Attentional System (Norman & Shallice, 1986). The SAS distinguishes between:
Contention scheduling — automatic, routine behavior managed by learned schemas
Supervisory attention — a higher-order system that intervenes when routines are insufficient
OS-008 maps this directly:
| SAS concept | OS-008 component | Function |
|---|---|---|
| Learned schemas | Reactive pipeline | retrieve -> topology -> deliberate -> store |
| Contention scheduling | PipelineEnforcer | Sequences pipeline stages automatically |
| Supervisory attention | QualityGate + SprintController | Intervenes on failure, low confidence, novel situations |
| Schema inhibition | ContractValidator | Blocks actions that violate governance constraints |
This is not a metaphor. The SAS is a computational theory of executive control, and OS-008 implements it. The harness is the supervisory attentional system — it overrides automatic routines when novel or dangerous situations arise.
This claim requires defense, because it is counterintuitive. If the model is not the bottleneck, why does everyone care so much about model capabilities?
The answer: model capabilities are necessary but not sufficient. A more capable model inside a bad harness will produce worse results than a less capable model inside a good harness. The evidence:
Anthropic's finding: A harness designed for Claude Haiku outperformed raw Claude Sonnet on long-running agentic tasks. Haiku is a smaller, less capable model. But the harness — with its generator-evaluator separation, sprint decomposition, and quality gates — compensated for Haiku's limitations and prevented Sonnet's overconfidence from accumulating errors over long runs.
OpenAI's finding: Codex with CI invariants (mechanical enforcement) produced more reliable code than Codex with prompt-based instructions (behavioral suggestions). The model was the same. The harness was the variable.
Factory.ai's finding: Context management at 60% utilization preserved output quality that was lost at higher utilization, regardless of model capability. The model's stated context window is a ceiling, not a performance guarantee.
All three findings point to the same conclusion: the orchestration around the model matters more than the model's raw capability.
OS-008 formalizes this as a cognitive architecture principle: the harness is the Supervisory Attentional System. It does not generate — it governs generation. It does not reason — it ensures reasoning follows the correct pipeline. The quality of the supervisor determines the quality of the system, regardless of the quality of the supervised components.
This has a practical implication for system design: invest in the harness first. A well-engineered harness will extract maximum value from whatever model it wraps — today's model, tomorrow's model, or a local model running on constrained hardware (see OS-005, Model Tier Adaptation).
A task moves through the following lifecycle under OS-008:
Task
|
v
Plan ──────────── Planner decomposes into sprints
| (PipelineEnforcer: retrieve before planning)
v
Sprint [1..N] ─── For each sprint:
|
| Generate ── Generator produces output
| | (PipelineEnforcer: retrieve before acting)
| v
| Evaluate ── Evaluator grades against criteria
| | (QualityGate: isolated context)
| |
| |── fail → iterate with feedback (max 3 attempts)
| |── pass → commit
| v
| Commit ──── Store sprint outcome
| (ContractValidator: governance check)
| (ContextManager: compact if > 60%)
|
v
Complete ────────── All sprints passed
|
v
Learn ───────────── Store outcomes in Graphonomous
(learn_from_outcome for confidence updates)Each step maps to OS-008 components:
| Lifecycle step | Primary component | What it enforces |
|---|---|---|
| Plan | SprintController + PipelineEnforcer | Retrieve before planning. Max 10 sprints per task. |
| Generate | PipelineEnforcer | Retrieve before acting. Pipeline stage ordering. |
| Evaluate | QualityGate | Isolated evaluator context. Acceptance criteria grading. |
| Iterate | SprintController | Max iteration count. Evaluator feedback injection. |
| Commit | ContractValidator | Governance block hard constraints. Audit logging. |
| Compact | ContextManager | 60% threshold. Graphonomous storage before compaction. |
| Learn | PipelineEnforcer | Mandatory outcome storage. Causal provenance. |
The lifecycle is not optional. The harness enforces it. An agent cannot skip the evaluation step. An agent cannot commit without a governance check. An agent cannot complete without storing outcomes. These are not guidelines in a prompt — they are state machine transitions in the SprintController.
Consider a simple policy: "always retrieve relevant context before acting."
As a prompt instruction:
System: Before taking any action, retrieve relevant context
from Graphonomous. Do not proceed without retrieval.This works for the first few turns. Then context grows. The model starts to lose track of the instruction. By turn 30, the instruction is 28,000 tokens ago. The model has forgotten it, or it is competing with 50 other instructions for attention. The model acts without retrieving. Nobody notices until the output is wrong.
As a runtime constraint:
PipelineEnforcer.check(:write_tool_call, session_state)
# => {:error, :retrieval_not_completed}
# Tool call blocked. Agent cannot proceed.This works at turn 1. It works at turn 30. It works at turn 300. It does not degrade with context length. It does not compete with other instructions for attention. It is a state machine check, and the state machine has exactly two outcomes: the retrieval stage has been completed, or it has not.
The difference is not incremental. It is categorical.
| Property | Prompt instruction | Runtime constraint |
|---|---|---|
| Reliability at turn 1 | High | Absolute |
| Reliability at turn 30 | Degraded | Absolute |
| Reliability at turn 300 | Absent | Absolute |
| Bypassable by model | Yes | No |
| Affected by context length | Yes | No |
| Auditable | No (prompt is opaque) | Yes (state machine is inspectable) |
| Portable across models | Must be re-tuned | Model-agnostic |
Prompt engineering is necessary — the agent still needs well-crafted instructions to perform its role effectively. But prompt engineering is not sufficient for reliability. Reliability requires mechanical enforcement. The harness provides it.
This is why OS-008 exists as a protocol separate from OS-006 (governance). OS-006 enforces permissions — can this agent call this tool? OS-008 enforces pipelines — did this agent follow the correct sequence of steps? Both are mechanical. Both are necessary. Neither can be replaced by prompts.
Harness engineering is not a trend. It is the recognition of a structural property of agentic systems: the orchestration layer determines system quality more than the generation layer.
The industry discovered this empirically. Anthropic, OpenAI, Factory.ai, LangChain, and the academic community each found their own path to the same architecture. The convergence is complete.
OS-008 occupies a specific position within this emerging discipline. It is the only harness protocol that combines all six principles (separation, enforcement, context management, sprints, persistent memory, graduated autonomy) with topology-aware routing, epistemic self-modeling, governance contracts, and cognitive science grounding. It does not compete with other harnesses — it formalizes the architecture they all approximate.
The agent model is not the bottleneck. The harness is. Build the harness right, and the model becomes a replaceable component — swappable, upgradable, adaptable to hardware constraints. Build the harness wrong, and no model, however capable, will produce reliable agentic behavior.
OS-008 builds the harness right.
OpenSentience · opensentience.org · Apache 2.0 OS-008: Agent Harness Protocol · [&] Ampersand Box Design