Harness Engineering

Design environments, feedback loops, and control systems that enable AI coding agents to produce reliable software at scale. A harness is everything around the code that keeps agents effective: structured knowledge, mechanical constraints, application legibility, and entropy management.

Core insight: When agents struggle, the fix is almost never "try harder." Ask: what capability is missing, and how do we make it both legible and enforceable for the agent?

Variant: harness-engineering-copilot — strategies and patterns specialized for GitHub Copilot agent customization.

Sources: OpenAI — Harness Engineering | Martin Fowler — Harness Engineering

Three Harness Components

Component	What it does	Deterministic?
Context Engineering	Curated, structured knowledge base in the repo + dynamic context (observability, browser)	Mixed
Architectural Constraints	Layered architecture enforced by custom linters and structural tests	Deterministic
Garbage Collection	Periodic agents that detect drift, stale docs, and constraint violations	LLM-based

Assess Current Harness

Before building, audit what exists. Run through this checklist with the user:

Repository knowledge — Is there an AGENTS.md or equivalent entry point? Is it a concise map (~100 lines) or a bloated monolith?
Documentation structure — Is there a docs/ directory with architecture, design docs, product specs, and plans? Are they versioned and cross-linked?
Architectural constraints — Are module boundaries defined? Are dependency directions enforced mechanically (linters, structural tests)?
Application legibility — Can an agent boot, drive, and observe the application (logs, metrics, traces, browser)?
Feedback loops — When the agent produces drift, is there a process to detect and correct it?
CI/CD gates — Do linters and tests catch constraint violations before merge?

Rate each 0–2 (absent / partial / enforced). Total ≤ 5 = early stage; 6–8 = developing; 9–12 = mature.

1. Context Engineering

The repository is the agent's only world. Anything not accessible in-context effectively does not exist.

Repository Knowledge as System of Record

Anti-pattern: One giant AGENTS.md with everything. It crowds out task context, rots instantly, and is unverifiable.

Pattern: AGENTS.md as table of contents (~100 lines), pointing to structured docs/:

AGENTS.md              ← map, not manual
ARCHITECTURE.md        ← top-level domain + layer map
docs/
├── design-docs/       ← indexed, with verification status
│   ├── index.md
│   └── core-beliefs.md
├── exec-plans/        ← active, completed, tech-debt
│   ├── active/
│   └── completed/
├── product-specs/     ← requirements + acceptance criteria
├── references/        ← external docs, llms.txt files
├── DESIGN.md
├── FRONTEND.md
├── QUALITY_SCORE.md
├── RELIABILITY.md
└── SECURITY.md

Key principles:

Progressive disclosure: agents start with a small stable entry point and are taught where to look next
Plans as first-class artifacts: execution plans with progress logs checked into the repo
Mechanical freshness: CI jobs validate the knowledge base is up-to-date, cross-linked, and correctly structured
Doc-gardening agent: periodic background task scans for stale docs and opens fix-up PRs

Dynamic Context Providers

Extend what agents can observe beyond static files:

Browser automation: Wire Chrome DevTools Protocol (CDP) into agent runtime. Agents take DOM snapshots, screenshots, and navigate UI to reproduce bugs and validate fixes.
Observability stack: Ephemeral per-worktree observability (logs via LogQL, metrics via PromQL, traces via TraceQL). Agents query: "ensure startup < 800ms" or "no span in critical journeys exceeds 2s."
App bootability: Make the application bootable per git worktree so agents can launch isolated instances per task.

2. Architectural Constraints

Agents replicate patterns that exist in the repository — including bad ones. Mechanical enforcement prevents drift.

Layered Domain Architecture

Divide each business domain into fixed layers with strictly validated dependency directions:

Types → Config → Repo → Service → Runtime → UI
                         ↑
                    Providers (auth, connectors, telemetry, feature flags)

Code may only depend "forward" through the layers
Cross-cutting concerns enter through a single explicit interface: Providers
Enforced by custom linters and structural tests (not just conventions)

Mechanical Enforcement

Mechanism	Purpose	Examples
Custom linters	Catch violations with remediation instructions in error messages	Dependency direction, structured logging, naming conventions, file size limits
Structural tests	Validate architecture invariants	ArchUnit-style tests, import graph validation
Pre-commit hooks	Block violations before they enter the repo	Schema validation, boundary checks
CI validation	Catch what slips through locally	Full lint + test suite, doc freshness checks

Critical detail: Write custom lint error messages that include remediation instructions. These messages become agent context when violations occur, teaching the agent how to fix issues.

Enforce Invariants, Not Implementations

Be prescriptive about boundaries (e.g., "parse data shapes at the boundary"), but not about specific tools. Specify what, let agents decide how within boundaries.

3. Garbage Collection

Full agent autonomy introduces entropy. Without active management, drift compounds.

Golden Principles

Define opinionated, mechanical rules that keep the codebase legible:

Prefer shared utility packages over hand-rolled helpers (centralized invariants)
Validate data at boundaries — don't probe data "YOLO-style"
Enforce consistency in naming, logging, and error handling

Periodic Cleanup Agents

Schedule recurring background tasks that:

Scan for deviations from golden principles
Update quality grades per domain and layer
Open targeted refactoring PRs (most reviewable in under a minute)

Cadence: Daily or per-sprint. Treat like garbage collection — continuous small increments, not painful bursts.

Quality Scoring

Maintain a quality document that grades each product domain and architectural layer, tracking gaps over time. This gives both humans and agents a map of where debt lives.

Agent-First Workflow

When adopting harness engineering, the development loop changes:

Human: Define task → Write acceptance criteria
  ↓
Agent: Validate codebase state → Implement → Self-review → Request agent reviews
  ↓
Agent: Respond to feedback → Iterate until reviewers satisfied
  ↓
Agent: Detect/remediate build failures → Escalate only when judgment required
  ↓
Merge (minimal blocking gates — corrections are cheap, waiting is expensive)

Humans work at a different abstraction layer: prioritize work, translate user feedback into acceptance criteria, validate outcomes. When agents struggle, identify what's missing and feed it back into the repo.

Applying to Existing Codebases

Not every technique applies to brownfield code. Assess feasibility:

Technique	Retrofit difficulty	Start here
AGENTS.md + docs/ structure	Low	Create entry point, incrementally document
Custom linters	Medium	Start with 2–3 high-value rules
Structural tests	Medium	Enforce module boundaries first
App legibility (CDP, observability)	High	Requires infra investment
Full garbage collection agents	High	Start with doc-gardening only

Pragmatic approach: Start with context engineering (cheapest, highest ROI), add architectural constraints incrementally, garbage collection last.

Harness as Service Template

For organizations with 2–3 main tech stacks, consider packaging harnesses as reusable templates:

Pre-configured linters and structural tests for the stack
Knowledge base skeleton (AGENTS.md, docs/ structure)
CI pipeline with doc-freshness and constraint-validation jobs
Starter golden principles for the technology

This parallels "golden path" service templates, but optimized for agent-driven development.