The Eight Harness² Components

Harness² exposes eight editable components around a model whose weights stay fixed. The README lists the names and groups them by runtime role; it does not document a full schema for every component. This page separates what the official material actually says from the practical reading that helps you decide what to edit.

The project site gives a useful one-line summary of the group split: system prompt, guardrails, memory and skills construct context; tool guidance and scripts define the tool interface; subagents orchestrate delegated work; plugins control middleware. The README itself names the same eight components and describes them as controlling context construction, the tool interface, delegation and behavior inside the tool loop.

The eight at a glance

1. System prompt

What it controls. The agent's persona and top-level procedure: how the executor approaches a task before any individual tool is called. The project site describes it this way; the README only names the component and places it in context construction.

Runtime role. It is part of the context the executor receives at the start of a task. Because it precedes the tool loop, it shapes the first plan and the frame for later turns.

When to change it. Change it when the task needs a different working procedure, or when failures come from planning rather than from a missing tool. If the agent consistently misreads the deliverable, the system prompt is a better first edit than a new script.

What is not documented. The README does not specify the system prompt's file format, required fields, or default text.

2. Guardrails

What it controls. Constraints and checks on what the agent may do, and what it must verify before delivering. The README places guardrails in context construction; the exact enforcement mechanism is not described there.

Runtime role. Guardrails shape the instructions around risky actions and completion checks. They are part of the context rather than a separate policy engine in the documented model.

When to change it. Change guardrails when the agent skips verification, oversteps the requested scope, or produces a plausible deliverable that was never checked against the source. A guardrail is the right edit when the failure is "it should not have done that" rather than "it did not know how".

What is not documented. The README does not specify guardrail syntax, which guardrails are built in, or how enforcement is implemented.

3. Memory

What it controls. What the agent carries forward or retrieves across steps and tasks, as opposed to what it recomputes on every call.

Runtime role. Memory is part of context construction. It decides which prior evidence and state reach the next model call, which is why it can change behavior without changing the prompt's wording.

When to change it. Change memory when tasks are long, context is repeatedly lost, or the agent re-derives facts it already established. If the agent forgets a constraint between tool calls, memory or guardrails are more likely culprits than tool guidance.

What is not documented. The README does not specify the memory backend, retention policy, retrieval method, or persistence format.

4. Tool guidance

What it controls. How tools are described to the model, when each should be used, and what a good input looks like.

Runtime role. Tool guidance is part of the tool interface. It sits between the model and the executor's available actions, so it affects tool selection and argument quality.

When to change it. Change it when the agent picks the wrong tool, passes malformed arguments, or ignores a tool that would settle the task. This is the component to edit when the agent knows what it wants to do but does it with the wrong interface.

What is not documented. The README does not specify the tool schema format, the description length limits, or a required naming convention.

5. Subagents

What it controls. How work is split and delegated to specialized or parallel agents.

Runtime role. Subagents are the orchestration component. They decide what runs independently and what evidence returns to the main executor. The README places delegation here rather than in the context-construction group.

When to change it. Change it when a task has separable subtasks, needs a specialist, or benefits from parallel investigation. If a task is inherently sequential, adding subagents can add coordination cost without adding evidence.

What is not documented. The README does not specify how many subagents may run, how roles are defined, or how delegation is configured.

6. Skills

What it controls. Reusable procedures that the agent can load for a class of tasks instead of rebuilding the method each time.

Runtime role. Skills belong to context construction: a skill injects a proven procedure into the current context. That makes them a good fit for repeatable multi-step work, not one-off facts.

When to change it. Change or add a skill when the same workflow keeps recurring and you can capture it as a repeatable method. A skill is a better edit than a longer system prompt when the procedure is optional or task-specific.

What is not documented. The README does not specify the skill file format, loading order, or how skills are selected.

7. Scripts

What it controls. Executable helpers that make deterministic operations repeatable instead of asking the model to perform them by reasoning.

Runtime role. Scripts are part of the tool interface. They expose concrete operations the executor can run, which is useful when correctness depends on exact computation rather than plausible text.

When to change it. Change or add a script when a step is deterministic, error-prone by hand, or repeated often enough to deserve a script. If the model is doing arithmetic, file manipulation or format conversion by reasoning, a script is usually the higher-leverage edit.

What is not documented. The README does not specify the script runtime, language, packaging, or how scripts are registered as tools.

8. Plugins

What it controls. Middleware that runs inside the tool loop and changes behavior across tools rather than in one prompt.

Runtime role. Plugins are the middleware-control component. They can observe or transform what happens between calls, which is different from a one-off instruction in the system prompt.

When to change it. Change plugins when a policy, transformation or logging concern applies to many tools and should not be repeated in each prompt. If the behavior is specific to one tool, start with tool guidance or a script instead.

What is not documented. The README does not specify the plugin API, available hooks, or execution order.

A practical heuristic, not a documented rule

The table below is our reading of the component split. It is not a rule from the README. Use it to pick the cheapest edit that could explain the failure.

What stays fixed

The model weights stay fixed. Harness² is not a fine-tuning method; it edits the system around the model. That is why the eight components are the unit of change, and why the same model can produce different behavior under a different harness.

Continue with the tutorial for the recursion mechanics, or the benchmarks for what one step changed in the reported results.