Harness Engineering

Harness Engineering

Harness = the operating system for AI agents working on your project. Model is CPU, context window is RAM, harness is OS.

Core Principle

Start simple, add complexity only when needed. Every harness component encodes an assumption about what the model can't do alone. Pressure-test these assumptions — they expire as models improve. Build for deletion.

When This Skill Activates

Workflow

For New Projects

1. Assess — What's the project? Tech stack? Team size? How will agents be used? 2. Setup — Create foundational harness files → read references/01-project-setup.md 3. Context — Design information architecture → read references/02-context-engineering.md 4. Constraints — Add guardrails and linters → read references/03-constraints.md 5. Evaluate — Set up feedback loops → read references/05-eval-feedback.md 6. If project involves multi-agent or long tasks → read references/04-multi-agent.md, references/06-long-running.md

For Diagnosis (Agent Not Performing Well)

1. Read references/07-diagnosis.md immediately 2. Identify which harness layer is failing 3. Apply targeted fix from the relevant reference

For Incremental Improvement

Assess current harness maturity, identify weakest layer, improve one layer at a time.

Harness Layers (Quick Reference)

Self-Update Protocol

When you discover a new reusable harness pattern during a project:

1. Identify which reference file it belongs to (or if it needs a new one) 2. Add the pattern with: what it solves, when to use it, how to implement it 3. Keep it concise — no fluff, just the pattern

01 - Project Setup

How to set up a project's foundational harness files so agents can work effectively.

AGENTS.md (The Entry Point)

AGENTS.md is a table of contents, not an encyclopedia. It tells the agent where to find things, not everything it needs to know.

Structure

# Project Name

## Quick Start
<1-3 commands to get running>

## Architecture Overview
<2-3 sentences + pointer to docs/architecture.md>

## Directory Structure
<tree of key directories with 1-line descriptions>

## Key Conventions
<5-10 rules the agent MUST follow — only the most important ones>

## Documentation Map
<pointers to docs/ files by topic>

## Common Tasks
<task → relevant files/commands mapping>

Anti-patterns

• Dumping entire codebase knowledge into AGENTS.md (too long, agent skims)
• No AGENTS.md at all (agent guesses everything)
• Stale AGENTS.md that contradicts reality (worse than no file)

docs/ Directory (System of Record)

The docs/ directory is where detailed knowledge lives. AGENTS.md points here.

Recommended Structure

docs/
├── architecture.md      # System design, component relationships
├── conventions.md       # Coding standards, naming, patterns
├── api.md              # API contracts, endpoints
├── data-model.md       # Database schema, data flow
├── testing.md          # Test strategy, how to run, what to test
├── deployment.md       # Build, deploy, environments
└── decisions/          # Architecture Decision Records (ADRs)
    └── 001-chose-x.md

Writing Docs for Agents

• Be explicit about "why" — agents follow rules better when they understand the reasoning
• Include examples — show the pattern, not just describe it
• Keep files focused — one topic per file, <300 lines ideal
• Add a TOC for files >100 lines
• Date and version decisions — agents need to know what's current

Design Notes in Source Tree

Embed context where agents will encounter it — in the source tree itself.

src/
├── components/
│   ├── DESIGN_NOTES.md    # Why components are structured this way
│   └── Button/
├── api/
│   ├── DESIGN_NOTES.md    # API design principles
│   └── routes/

These files survive across sessions. They're the cross-session memory that prevents agents from re-making decisions or contradicting past choices.

init.sh Pattern (For Automated Setups)

For projects that need environment setup before agents can work:

#!/bin/bash
# init.sh - Run before agent starts working
set -e

# Install dependencies
npm install  # or pip install, cargo build, etc.

# Set up local config
cp .env.example .env.local

# Verify setup
npm run typecheck
npm test -- --run

echo "Environment ready for agent work"

Initial Commit Convention

After setting up harness files, make an initial commit:

git add -A && git commit -m "harness: initial project setup"

This gives agents a clean baseline to diff against and revert to if needed.

Quality Scoring (Optional)

For larger docs/, add quality metadata:

---
quality: 0.8
last_verified: 2025-01-15
owner: @username
---

This helps agents (and humans) know which docs to trust and which need updating.

02 - Context Engineering

What agents see determines what they do. Context engineering = designing the information environment for optimal agent performance.

Core Formula

Prompt Engineering = what you say to the agent Context Engineering = what you show the agent Harness Engineering = the whole system (context + constraints + feedback + architecture)

Progressive Disclosure

Don't dump everything into the system prompt. Layer information:

1. Always visible (~100 words): Project name, tech stack, critical rules 2. On-demand (AGENTS.md → docs/): Architecture, conventions, patterns 3. Just-in-time (Design Notes, inline comments): File-specific context

Implementation

AGENTS.md (always loaded)
  → "For architecture details, see docs/architecture.md"
  → "For API conventions, see docs/api.md"

docs/architecture.md (loaded when agent works on architecture)
  → "For the auth subsystem specifically, see src/auth/DESIGN_NOTES.md"

AGENTS.md as router: It doesn't contain knowledge — it routes to knowledge. Like a table of contents, not the book.

Instruction Bloat

AGENTS.md should stay 50–200 lines. Beyond that, signal-to-noise ratio drops and agents suffer from "lost in the middle" — instructions in the middle of a long document get less attention than those at the start or end.

Signs of instruction bloat:

• AGENTS.md exceeds 300 lines
• Same concept restated in different sections
• Rules that never triggered (model already knows them)

Fix: Move detailed content to docs/ files. Keep AGENTS.md as a routing index with only critical, always-needed rules inline.

Working State Management

Agents lose state between sessions. Design explicit state persistence:

Progress File Pattern

# progress.md

## Current State
- Feature X: 80% complete, auth flow done, UI pending
- Feature Y: Not started

## Completed
- [x] Database schema migration
- [x] API endpoints for /users

## Blocked
- Need API key for external service (asked user 2025-01-15)

## Next Steps
1. Complete Feature X UI components
2. Write integration tests for auth flow

Feature List JSON Pattern

{
  "features": [
    {
      "name": "User Authentication",
      "status": "complete",
      "files": ["src/auth/*", "src/middleware/auth.ts"],
      "tests": "passing"
    },
    {
      "name": "Dashboard",
      "status": "in_progress",
      "files": ["src/pages/dashboard/*"],
      "tests": "not_written"
    }
  ]
}

Give Maps, Not Manuals

Instead of step-by-step instructions, give agents orientation:

Bad (manual):

Step 1: Open src/auth/login.ts
Step 2: Find the handleLogin function
Step 3: Add rate limiting by...

Good (map):

Auth system lives in src/auth/. Login flow: login.ts → validate.ts → session.ts.
Rate limiting middleware is in src/middleware/rateLimit.ts — follow its pattern.
Tests in src/auth/__tests__/ — every auth change needs a test.

Maps let agents navigate autonomously. Manuals make them fragile to any deviation.

Cross-Session Context

What survives between agent sessions:

• Files on disk (AGENTS.md, docs/, DESIGN_NOTES.md, progress files)
• Git history (commit messages, diffs)
• Code comments and docstrings

What doesn't survive:

• Conversation history
• Agent's internal reasoning
• Verbal agreements ("we decided to use X approach")

Rule: If a decision matters, it must be written to a file. Verbal context is lost context.

Context Window as RAM

• Context window fills up → agent loses coherence
• Context anxiety: As agents approach their context limit, they exhibit "premature convergence" — rushing to finish, skipping verification steps, and producing lower-quality output. This is an observed behavior pattern, not a metaphor.
• Compaction (summarize old context): Maintains continuity but doesn't fully reset context anxiety
• Context reset (fresh agent + handoff artifact): Clean start, eliminates context anxiety, requires good handoff docs
• Choice depends on model: Some models handle long contexts well, others degrade

Handoff Artifact Structure

When resetting context, the handoff must contain: 1. What was accomplished 2. Current state of all files changed 3. What to do next 4. Any decisions made and why

03 - Constraints & Guardrails

Constraints increase agent autonomy by making incorrect paths fail fast. Paradox: more rules → more freedom.

The "Relocating Rigor" Principle

Traditional dev: humans enforce quality through code review, conventions, experience. Agent dev: encode that rigor into automated checks. Agents run freely within checked boundaries.

Architecture Enforcement via Linters

Custom linters that enforce dependency direction and layer boundaries.

Layer Architecture Example (OpenAI Pattern)

Types → Config → Repo → Service → Runtime → UI

Each layer can only import from layers to its left. A custom lint rule rejects violations automatically.

Implementation

// .eslintrc.js or custom lint script
// Rule: UI files cannot import from Repo directly
// Rule: Service files cannot import from UI
// Rule: Types files cannot import from anything except other Types

module.exports = {
  rules: {
    'no-restricted-imports': ['error', {
      patterns: [
        { group: ['../repo/*'], message: 'UI cannot import repo directly. Use service layer.' }
      ]
    }]
  }
}

One Rule Per Mistake

When an agent makes a mistake, don't just fix it — add a lint rule or check that prevents it forever. This is how the harness learns.

## .agents/rules.md (or in AGENTS.md)

### Rule: No direct DB queries in route handlers
Added: 2025-01-15
Reason: Agent put raw SQL in an Express handler, bypassing the service layer
Fix: All DB access goes through src/services/. Lint rule enforces this.

Type Systems as Guardrails

Strong types prevent entire categories of agent errors:

• TypeScript strict mode: strict: true in tsconfig catches type mismatches at build time
• Zod/Valibot schemas: Runtime validation of API boundaries
• Database schemas: Typed ORM (Prisma, Drizzle) prevents schema drift

Never suppress types: No as any, @ts-ignore, @ts-expect-error. If the agent can't make types work, the design is wrong.

Structured Tests as Contracts

Tests serve as executable specification that agents can verify against:

// This test IS the spec. Agent reads it to understand expected behavior.
describe('UserService', () => {
  it('should hash password before storing', async () => {
    const user = await UserService.create({ email: 'test@test.com', password: 'plain' });
    expect(user.password).not.toBe('plain');
    expect(user.password).toMatch(/^\$2[aby]\$/); // bcrypt format
  });
});

Upstream Test Suite Bridging

If building on top of an existing framework/library, bridge their test suite:

# Run upstream tests to verify compatibility
npm run test:upstream  # Ensures our changes don't break framework contracts
npm run test:ours      # Our own tests

This gives agents a feedback loop: "my change broke upstream compatibility."

Safe Autonomy Boundaries

Define what agents CAN and CANNOT do:

## Agent Permissions

### Allowed
- Create/modify files in src/
- Run tests
- Install dev dependencies
- Create git branches

### Forbidden
- Modify CI/CD config without approval
- Delete test files
- Push to main/master
- Modify .env with real credentials
- Install production dependencies without approval

Git as Safety Net

## Git Conventions for Agents

- Commit after each logical unit of work (not at the end)
- Commit message format: `type(scope): description`
- Never force push
- Branch per feature: `agent/feature-name`

Small, frequent commits let humans (and other agents) review incrementally and revert surgically.

Pre-commit Hooks

# .husky/pre-commit or similar
npm run typecheck
npm run lint
npm run test -- --changed

Agent gets immediate feedback if a commit violates constraints. Fail fast, fix fast.

04 - Multi-Agent Architecture

When to use multiple agents, how to coordinate them, and communication protocols.

When to Use Multi-Agent

Single agent when: Task fits in one context window, one domain, straightforward. Multi-agent when: Task spans domains, exceeds context limits, benefits from separation of concerns, or needs independent evaluation.

Start single, split when you hit walls. Don't prematurely architect multi-agent.

Foundational Patterns

1. Prompt Chaining

Sequential pipeline: Agent A output → Agent B input → Agent C input. Use when tasks have clear stages. Each stage can be optimized independently.

2. Routing

Classifier sends input to specialized agent. Like a dispatcher. Use when inputs vary widely and different expertise is needed.

3. Parallelization

Multiple agents work on independent subtasks simultaneously. Use when tasks are decomposable and don't share state.

4. Orchestrator-Workers

Central coordinator delegates to specialized workers. Use when task decomposition requires judgment (not predetermined).

5. Generator-Evaluator (GAN-Inspired)

One agent creates, another judges. Iterate until quality threshold met. Use when quality assessment is possible but self-assessment is unreliable.

Coordinator Design

The coordinator (lead agent) is the most critical piece. Key lessons:

Teach Detail in Delegation

Bad: "Build the auth system" Good: "Build JWT auth with: refresh tokens (7d expiry), httpOnly cookies, /auth/login and /auth/refresh endpoints. Use bcrypt for passwords. Follow patterns in src/auth/existing.ts"

Scale effort to query complexity — simple questions get simple delegation, complex ones get detailed plans.

Communication Protocols

File-Based Communication

Agents communicate through files on disk. Reliable, auditable, survives crashes.

.harness/
├── plan.md          # Planner writes, others read
├── sprint-contract.md  # Generator + Evaluator negotiate
├── eval-report.md   # Evaluator writes, Generator reads
└── handoff.md       # Current agent writes for next agent

Intent Marker Protocol (Structured Tags)

For supervisor-worker patterns, use explicit tags:

Max 3 messages per exchange — prevents infinite loops between agents.

Sprint Contract Pattern

Before work begins, generator and evaluator agree on: 1. What will be built 2. How to verify it's done (testable criteria) 3. Quality thresholds

This bridges the gap between high-level specs and implementation verification.

Separation of Concerns

Why Separate Generator and Evaluator

• Self-evaluation bias: Agents rate their own work too highly
• Easier calibration: Tuning an evaluator for skepticism is easier than making a generator self-critical
• Focused context: Each agent has optimized context for its role

When Evaluator Adds Value

The evaluator earns its cost when tasks are at the edge of model capability. As models improve, the boundary moves — tasks that needed evaluation before may not anymore. Re-assess periodically.

Sub-Agent Delegation

## Delegation Template
1. TASK: Specific, atomic goal
2. CONTEXT: Relevant files, patterns, constraints
3. DELIVERABLE: What to produce
4. CONSTRAINTS: What NOT to do
5. VERIFICATION: How to know it's done

Let Agents Self-Improve

Allow sub-agents to update their own tools and patterns. An agent that discovers a better approach should be able to encode it for future runs.

Broad-Then-Narrow Search

For research/exploration agents: 1. Cast a wide net first (explore many possibilities) 2. Then narrow to promising paths 3. Don't commit to the first solution found

05 - Eval & Feedback

How to evaluate agent output and create feedback loops that drive improvement. "What you can't measure, you can't improve."

Eval-Driven Development

Build evals BEFORE building features. Like TDD but for agent behavior.

Eval Structure

Every eval has three parts: 1. Task: What the agent must accomplish (input + instructions) 2. Trial: One attempt at the task (may run multiple trials per task) 3. Grader: How to judge the output

Grader Types

Metrics

• pass@k: Probability of at least 1 success in k attempts. Use when agent needs to succeed at least once.
• pass^k: Probability of success on ALL of k attempts. Use when reliability matters.

Starting Point

Start with 20-50 tasks derived from real failures. Don't invent abstract test cases — capture actual problems agents hit in your project.

"Let AI Check AI" Pattern

Use a separate agent to verify the first agent's work. More reliable than self-checking.

Garbage Collection Agents

Periodic agents that scan the codebase for:

• Inconsistencies between code and docs
• Dead code or unused imports
• Convention violations
• Stale TODOs or fixmes

How to run: Schedule a periodic agent task (weekly or after major changes) with a prompt like:

"Scan this codebase for inconsistencies between docs/ and actual code. Report discrepancies."

Run this via your agent's headless/non-interactive mode (e.g. CLI one-shot, CI pipeline task, or scheduled automation). The exact invocation depends on your toolchain — what matters is the pattern: automated, periodic, agent-driven codebase audit.

This is the codebase equivalent of a garbage collector — finds drift before it becomes debt.

Agent-Readable Observability

Agents need to see their own telemetry:

Structured Logging

// Logs that agents can parse and reason about
logger.info('auth.login', {
  userId: user.id,
  duration_ms: 145,
  success: true,
  method: 'jwt'
});

Error Reports

When an error occurs, generate agent-readable reports:

## Error Report
- **What failed**: POST /api/users returned 500
- **Stack trace**: src/services/user.ts:42 → src/db/queries.ts:18
- **Recent changes**: Modified user.ts (commit abc123)
- **Likely cause**: Missing null check on user.email

Feedback Loop Design

Test-on-Save

// package.json
{
  "scripts": {
    "dev": "concurrently 'vite' 'vitest --watch'",
    "check": "tsc --noEmit && eslint . && vitest --run"
  }
}

Agent gets instant feedback on every change.

Browser Automation Verification

For frontend work, use Playwright/Puppeteer MCP to: 1. Navigate the running app 2. Take screenshots 3. Interact with UI elements 4. Verify visual and functional correctness

The evaluator agent doesn't just look at code — it uses the app like a human would.

Differential Evaluation

Compare agent output against known-good reference:

• Run upstream test suite against agent's changes
• Diff screenshots before/after
• Compare performance metrics

Scoring Rubrics (For Subjective Quality)

When quality is subjective, create explicit rubrics:

## Design Quality Rubric
- **5**: Cohesive whole with distinct identity. Custom creative choices evident.
- **4**: Solid design with some unique elements. Minor template-ness.
- **3**: Competent but generic. Could be any template.
- **2**: Functional but visually flat. Default component library feel.
- **1**: Broken layout, inconsistent spacing, clashing colors.

Rubrics convert "is it good?" into "does it meet criteria X, Y, Z?" — which agents (and evaluator agents) can actually answer.

Execution Plans as Artifacts

When an agent plans its work, capture that plan as a file:

# execution-plan.md
## Goal: Add user settings page
## Steps:
1. Create SettingsPage component in src/pages/
2. Add route in src/router.ts
3. Create settings API endpoints
4. Add settings to user model
5. Write tests
## Dependencies: User model (exists), Router (exists)
## Estimated complexity: Medium

Plans are auditable, reviewable, and can be evaluated before execution begins.

06 - Long-Running Tasks

Patterns for agents working on tasks that span hours, multiple sessions, or exceed context windows.

The Two Core Problems

1. Context degradation: As context fills, agent loses coherence and may "rush to finish" 2. State loss: Between sessions, everything not on disk is forgotten

Initializer + Worker Pattern

Split long tasks into setup and execution:

Initializer Agent

Runs once at the start. Creates:

• init.sh — environment setup script
• progress.md — tracks what's done and what's next
• features.json — structured feature list with status
• Initial git commit — clean baseline

Bootstrap Contract: The initializer is done when a new agent can: 1. Start — environment runs with one command (init.sh) 2. Test — test suite passes on the baseline 3. See progress — progress file shows what's done and what's next 4. Pick up — next steps are unambiguous enough to begin immediately

Worker Agent

Runs iteratively. For each cycle: 1. Read progress file 2. Pick next incomplete feature 3. Implement it 4. Run tests 5. Git commit 6. Update progress file 7. Repeat or handoff

Progress Tracking

File-Based Progress (Critical)

# progress.md
Updated: 2025-01-15T14:30:00Z

## Completed Features
- [x] User authentication (commit: abc123)
- [x] Database schema (commit: def456)

## In Progress
- [ ] Dashboard UI — layout done, charts pending

## Remaining
- [ ] Settings page
- [ ] Export functionality

## Known Issues
- Auth token refresh has edge case with expired sessions
- Dashboard chart library version conflict (pinned to 2.x for now)

## Decisions Made
- Using SQLite for MVP, will migrate to PostgreSQL later (see docs/decisions/001.md)

Update after every commit. This is the cross-session memory.

Structured Feature Tracking

{
  "features": [
    {
      "id": 1,
      "name": "User Auth",
      "status": "complete",
      "sprint": 1,
      "commits": ["abc123"],
      "tests": "passing",
      "notes": "JWT + refresh tokens"
    }
  ],
  "current_sprint": 3,
  "total_sprints": 8
}

Context Reset vs Compaction

Context Reset (Full Swap)

• Kill current agent, start fresh agent
• Pass handoff artifact with full state
• Pros: Clean context, no "anxiety", fresh reasoning
• Cons: Higher latency, must encode all state in artifact

Compaction (In-Place Summary)

• Summarize early conversation, continue in same session
• Pros: Preserves continuity, lower latency
• Cons: May not fully reset "context anxiety", residual confusion

Decision Guide

• Model shows degraded performance with long context → Context Reset
• Model handles long context well → Compaction is fine
• Task requires fresh perspective → Context Reset
• Task benefits from continuity → Compaction

Handoff Artifacts

When one agent passes work to another:

# handoff.md

## What Was Done
<list of completed items with commit references>

## Current State
<what the codebase looks like now, running services, env state>

## What To Do Next
<ordered list of remaining tasks>

## Critical Context
<decisions, constraints, gotchas the next agent MUST know>

## Files Modified
<list of changed files and what changed in each>

The handoff must contain enough state for a new agent to continue without reading the full conversation history.

Git as Checkpoint System

# Commit after every feature/logical unit
git add -A && git commit -m "feat(auth): implement login flow"

# Tag milestones
git tag -a sprint-1-complete -m "Sprint 1: Auth + DB schema"

If something goes wrong, agent (or human) can revert to last known good state.

Incremental Verification

Don't wait until the end to test. After each feature:

# Verify as you go
npm run typecheck      # Types still correct?
npm run test           # Tests still pass?
npm run dev            # App still runs?

Catching errors early prevents compound failures that are hard to debug.

Anti-Patterns

• Premature completion: Agent declares "done" when it's not. Fix: explicit feature checklist + verification step.
• Scope drift: Agent adds unrequested features. Fix: structured feature list, agent checks against it.
• WIP > 1: Agent works on multiple features simultaneously, finishing none completely. Fix: enforce WIP=1 — complete and verify one feature before starting the next. Overreach and under-finish are co-occurring problems.
• Undocumented state: Agent makes changes without recording them. Fix: mandatory progress updates.
• Big bang testing: Testing only at the end. Fix: test after each feature.

Session Exit Checklist

Before ending a session, verify all five dimensions are clean:

1. Build: Project compiles / passes typecheck 2. Tests: All tests pass (no new failures) 3. Progress: Progress file updated with current state 4. Artifacts: No uncommitted changes, no temp files left behind 5. Startup: A new agent can resume using only on-disk artifacts (bootstrap contract holds)

Session exit is a completion requirement, not a courtesy. An unclean exit transfers debugging cost to the next session.

07 - Diagnosis: When Agents Underperform

When the user is frustrated with agent output, the problem is almost always in the harness, not the model. This guide helps identify and fix the root cause.

Symptom → Root Cause Map

Diagnosis Process

Step 1: Identify the Layer

Ask: Where in the harness stack is the failure?

1. Context: Agent doesn't have the right information 2. Constraints: Agent isn't prevented from making errors 3. Feedback: Agent doesn't know it's failing 4. Architecture: Single-agent can't handle the task's complexity 5. Scope: Task is too big or ambiguous

Step 2: Minimal Fix

Apply the smallest change that addresses the root cause:

• Missing context → Add one doc file or DESIGN_NOTES.md
• Missing constraint → Add one lint rule or test
• Missing feedback → Add one verification step
• Architecture problem → Split into two agents (but only if single agent truly can't handle it)
• Scope problem → Break task into smaller pieces

Don't over-engineer the fix. One rule per mistake. Iterate.

Step 3: Verify

After applying the fix: 1. Reproduce the original problem scenario 2. Confirm the fix prevents it 3. Confirm the fix doesn't break other things

Common Harness Improvements (Ordered by Impact)

High Impact, Low Effort

1. Add AGENTS.md if missing — immediate orientation improvement 2. Add one lint rule for recurring mistake — prevents whole category of errors 3. Add test for broken behavior — catches regression instantly 4. Document the convention agent keeps violating — eliminates guessing

High Impact, Medium Effort

5. Create docs/ with architecture overview — reduces architectural mistakes 6. Add pre-commit hooks — catches issues before they compound 7. Set up progress tracking — prevents premature completion and scope drift 8. Add DESIGN_NOTES.md in key directories — provides just-in-time context

High Impact, High Effort

9. Implement evaluator agent — for quality-critical or subjective tasks 10. Build custom linters — for project-specific architectural constraints 11. Create eval suite — systematic quality measurement and regression detection 12. Set up GC agent — periodic consistency checking

The "One Rule Per Mistake" Discipline

Every time an agent makes a mistake:

1. Fix the immediate issue 2. Ask: "Could a rule prevent this forever?" 3. If yes → add the rule (lint, test, type, or documented convention) 4. If no → add context (docs, examples, DESIGN_NOTES.md)

Over time, the harness accumulates rules that prevent every mistake the agent has ever made. The error rate converges toward zero for known failure modes.

When to Simplify

Signs the harness is over-engineered:

• Agent spends more time on harness compliance than actual work
• Multiple redundant checks for the same thing
• Harness rules that never trigger (the model learned past them)
• Cost/time significantly higher without proportional quality gain

How to Simplify

1. Disable one component (lint rule, constraint, doc file) and benchmark: did output quality drop? 2. If no measurable drop → remove it permanently 3. If quality dropped → keep it, document why it's needed 4. Repeat for each suspect component

Harness entropy grows over time (Lehman's Law applied to agent infrastructure). Without active cleanup, rules accumulate and slow agents down. Schedule periodic simplification — treat it as maintenance, not optimization.

Remove harness components when the model no longer needs them. Models improve — yesterday's scaffolding is today's dead weight.

Harness as Dataset

Every agent interaction is a training signal. The harness captures traces:

• What the agent tried
• What worked
• What failed
• What the fix was

These traces are your competitive advantage. They're the data that makes your harness better over time.