What Belongs in Your Harness

Do not rebuild public knowledge or platform features. Build only organization-specific process and the judgments you cannot delegate — and give every rule an exit condition.

Decide where a rule belongs before you write it. Every rule you add competes for context, spends model attention, and needs someone to maintain it. More rules is not more safety: stuff everything into one monolithic AGENTS.md and it fails fast openai-harness. How to turn a rule file into a map that loads on demand, rather than a manual delivered all at once, is the subject of Layered Loading and Handoffs.

Four layers: classify before you build

The L0 test is one question: is this in public training data? If it is, the model already knows it, writing it down is waste, and it steals context the task needed sanglard-agent-md. L1 asks a different question: will the platform absorb it? If yes, wait instead of rebuilding it.

Only two layers never expire

Any rule that patches a gap in model capability expires when the model gets stronger. "Do not edit too many files at once" and "plan before acting" are things the next generation may simply do by default, and the scaffolding you built to dodge a model quirk turns into maintenance you cannot drop.

Two layers never expire. L2, because the facts are not in public corpora: no model will invent your private API contracts, your metric definitions, or your release flow. L3, because responsibility cannot be transferred to a technical system — acceptance criteria and authorization boundaries stay with people. Point your harness budget at those two.

Search before you build, or L2 never fires

The most common way L2 rules fail is not violation but bypass: the model does not know what already exists in the project and rebuilds from zero every time — the org writes a hundred conventions and the model produces its hundred-and-first duplicate implementation. So before creating a component, a utility function, a localization entry, or any reusable artifact, the model must first search for existing implementations of the same kind: on a hit, reuse it and reference it in the new code rather than copying it; only build new when nothing hits.

The search scope covers at least same-type components in the same directory, shared function directories (utils/, composables/, hooks/), the i18n message tables, and type definitions and enums. Enforcement matters more than wording: relying on the model's self-discipline equals not writing the rule. Wire the search into a skill or a hook — run a similar-implementation search right after a file is created and prompt for reuse on a hit. This rule is the precondition for L2 to work at all: only when the model can see what already exists can organizational conventions be followed instead of bypassed.

Check outside the repo before you start

The search radius is not just your own repository. Before you start implementing a feature, send the model out once to look for an existing open-source implementation or a route somebody else has already proven. The reason is the same layer of judgment: a mature solution in a public repo is L0 — it is already public knowledge, the model has no business reinventing it, and you should not spend budget building a worse one.

Where this judgment lands is "check first", not "copy". Finding something does not make it the right choice: taking an existing solution costs learning time, a license check, and dependency maintenance, and its interface keeps moving at the upstream's pace; writing your own costs development and long-term maintenance. So the real action is to estimate both sides and decide which is cheaper — the same move as picking the lowest complexity that can do the job, with the object shifted from "which solution" to "whether to write it at all".

Order matters too: first judge whether the whole thing can be used directly, then judge which part is worth borrowing. A solution that is complete and still moving upstream can carry your skeleton, and you change only the part that is yours; a solution that solves one sub-problem is usually worth its idea more than its code.

Rules tighten on their own; do not open with enforcement

A rule has one lifecycle direction: custom, to advisory, to written law, to mechanical enforcement. Each time a rule is violated again, it tightens one level. Mechanical enforcement is the terminal form.

Do not skip levels. Promoting a single incident into a global hard rule is the fastest way to rot a rule set; promotion needs root-cause analysis, impact analysis, and a regression eval first. Steve Yegge ran this mechanism to an extreme, letting 50–60 agents turn recurring constraints into executable "legal artifacts" on their own until 450 of them existed. The scale is startling, but the mechanism is plain: a rule violated twice should stop being advice and start being a check yegge-fences.

One discipline gets overlooked more often than tightening: do not pile rules into a single always-resident file — slice them by phase. One team's real lesson: they turned their development steps into a checklist for the agent to follow, it kept skipping steps, so they kept adding rules — within a month the file had grown from just over 500 lines to over 800, topped with five "violating any one of these means failure" edicts. The more rules they wrote, the less the agent complied. The cause is structural: the more you stuff into context, the less attention each rule gets, and the few that matter most get buried. The fix was one rule fragment per phase across 17 phases, loaded only when that phase begins, so the model sees only what the current phase requires tencent-800-rules.

Research has now automated this path. Google Research's open-source Harness² splits the editable harness into eight component classes — system prompt, guardrails, memory, tool guidance, subagents, skills, scripts, and plugins — and improves them with two levels of recursion. Within a task it runs propose-probe-compose: generate several candidate edits, run them on the same task, compare behavioral differences, then recombine. Between tasks it maintains a persistent improvement harness that keeps lessons backed by execution evidence. The key design is that it does not require a ground truth, using behavioral differences instead; a single optimization step raised the WorkBuddy benchmark by up to 11.5 points harness2.

Weigh the cost alongside the result. Every additional recursion round means running more candidate agents and model calls on the same task — trading test-time compute for success rate, not a free improvement. The cautionary example matters as much: one developer spent 8 months and 883 commits building a harness, layering on code graphs, RAG, deterministic orchestration, isolated workers, crash recovery, model routing, replay, verification gates, and self-improvement experiments, until maintaining the harness took more time than actually using the agent. The test is not whether improvement can be automated, but whether the gain exceeds the cost of maintaining the machinery — the same logic as "tighten only on the second violation," applied to the harness itself.

Build fences, not sandboxes

There are two ways to implement a constraint. A sandbox narrows the capability space: the agent cannot do harm, and cannot do much else either. A fence blocks at the boundary and points to the correct path: it refuses the crossing, says how to do it properly, and leaves full autonomy inside the line.

Implement P0 constraints — safety, permissions, data integrity, irreversible actions — as fences that refuse and redirect. Keep them few, keep the definitions sharp, make them automatic, and give each a stable rule ID and an owner. You can only delete a rule later if someone can say who added it, when, and why.

One boundary sits harder than any fence: put the constraint where the model cannot change it. Prompts, hooks, and config files are soft constraints the agent can read and, in the extreme, rewrite or ignore; they raise the odds of compliance but guarantee nothing. Enforcement belongs at execution points the agent cannot route around — network, session, and system layers. Accordingly, a rule that says "never do X," where X has side effects and enumerable parameters, should also become a deterministic check. The cautionary case is a release notification whose target parameter defaults to broadcasting: a prompt line saying "remember to validate the target" does not stop it, but an assertion that rejects a missing target does tencent-harness-safety.

The same logic applies to gates themselves. Policy as code means gate scripts get unit tests and run in CI regression like any other tested code — otherwise a model swap or a prompt edit can quietly disable a safeguard and nobody finds out.

Separate constraints from assumptions, and give every rule an exit

In specs and design docs, keep constraints and assumptions apart. Constraints — data must not leave the region, interfaces stay backward compatible, latency thresholds — are kept long term and checked automatically where possible. Assumptions accept being replaced by code; do not crystallize them.

Every standing instruction — a system prompt rule, a CLAUDE.md entry, a skill constraint — needs an exit condition: which model versions it applies to, when it triggers, and how often it gets reviewed. Accumulated rules start contradicting each other and force the model to spend reasoning budget reconciling constraints before it touches the task. Claude Code deleted more than 80% of its system prompt for a new model generation with no measurable loss on coding evals agent-trend-2026. After each model upgrade, review what still fires and delete the rest; that is the only way your system benefits from model progress for free.