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 the outcome is predictable: it crowds out task context, makes every rule look equally important, rots fast, and leaves you no way to check whether a rule was followed 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
| Layer | Content | Maintenance |
|---|---|---|
| L0 public knowledge | General coding conventions, framework syntax, common sense | Keep it out of the harness |
| L1 platform capability | Execution loops, state management, subagent orchestration, tool dispatch | Prefer the platform; build only when missing, and mark it for replacement |
| L2 organization process | Internal toolchain, private metric definitions, private APIs, layout conventions, release flow | The team's core leverage — build this |
| L3 responsibility and value judgments | Acceptance criteria, authorization boundaries, approval thresholds, safety floors, trade-offs | Held by humans, enforced by machines |
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.
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.
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.
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.