The Harness

Part I ended with a formula: an agent is a model plus a harness. The model is rented; every team at the frontier has the same one. The harness is the execution environment wrapped around it (the working loop, the tool surface, the context machinery, the stop conditions), and it is where agent quality is actually built. Practitioners converged on this independently and almost simultaneously; the working shorthand that emerged is that apparent model quality is usually harness quality in disguise. When an agent misbehaves, audit the harness before blaming the model.

In Ikidna’s architecture the harness is the layer between orchestration intent and actual execution: the Orchestrator decides what work happens, and the harness is where it happens. The ACRI contract exists to keep that boundary crisp, so harnesses stay interchangeable from above while the Agent-Computer Interface governs the tool surface from below. Concrete candidates are catalogued in the harness stack reference.

What a harness contains

Six components recur in every serious harness, a decomposition due to Sebastian Raschka that matches what we find in practice:

1. Workspace context: what the agent sees of the repository and environment at start.
2. Prompt assembly: how the instruction is composed, including the split between stable content (cacheable) and volatile content (not). Cache economics are real; volatile content in a stable prefix silently multiplies cost.
3. Tool access: which actions exist and how they are described, per Giving an Agent Tools.
4. Context management: compaction, offloading, and retrieval during the run, per Runtime Context Management.
5. Session memory: what survives between sessions, and in what form.
6. Delegation: how subagents are spawned, scoped, and returned. The invariants that matter: minimal context in, synthesized summaries out, bounded depth.

A useful distinction cuts across all six: scaffolding is what is assembled before the run (system prompt, tool schemas, initial context); the harness proper is what operates during it (dispatch, context management, loop control). They fail differently, and fixes do not transfer: no prompt revision repairs a runtime permission failure, and no permission change repairs a bad system prompt.

The harness is a control system

The clearest way to reason about harness design is a two-by-two due to Martin Fowler. Every mechanism is either a guide (feedforward: shapes what the agent does before it acts) or a sensor (feedback: checks what it did), and each is either computational (deterministic code: permission checks, schema validation, failing tests) or inferential (model judgment: spec-alignment review, quality assessment).

Two design rules fall out of it:

• Implement both halves. Guides without sensors produce confident execution in the wrong direction; sensors without guides produce expensive action followed by backtracking.
• Prefer computational wherever a rule can express the constraint. Deterministic checks run in microseconds and cannot be argued with. Spend inferential capacity only on genuine judgment, and never chain inferential guides in series; throughput collapses. This is the same structural-over-textual principle that governs Security and Controls, and the highest-leverage sensor in practice is the one Verification is built on: a failing test the agent must turn green.

Place sensors early. A check after every action catches a wrong turn in one step; a check after the sequence catches it after the damage compounds, per the error arithmetic in Working With Models.

Harness engineering: the never-again loop

The discipline that separates teams whose agents improve from teams whose agents merely vary is a loop, named harness engineering by Mitchell Hashimoto: every observed agent mistake is engineered so it cannot recur, rather than prompted so it is less likely to. Structural prevention over probability reduction. The loop:

1. Observe the failure, from real runs, not hypotheticals.
2. Classify it: model, context, prompt, tool, or harness. The heuristics: consistent across models points to prompt or harness; disappears with more context, context; disappears with simpler tool output, tool; production-only, harness; irreproducible, the model being probabilistic.
3. Engineer the fix at the layer the classification names: a hook, a validator, a permission, a tool redesign. A prompt warning is the fix of last resort.
4. Verify against the original failure plus a regression suite, then generalise the fix across the pattern.

A thirty-minute structural fix beats a thirty-second prompt patch, because only one of them compounds. This is Agent Readiness applied to the runtime, and it is a live instance of the self-improvement loop that Minimal Bootstrap makes a standing goal of the factory.

One more property makes the harness the asset it is: it is where trajectories accumulate. Full traces of task, actions, observations, and outcomes are simultaneously debugging material, evaluation data for the Evaluation Harness, and the raw record the Execution Ledger is built on. Instrument from day one; the earliest failures are the most valuable.