Harness Engineering
If the design patterns describe what to build, harness engineering is about what the model runs inside. The harness is the runtime around an LLM — the loop that turns a stateless text completion into an agent that observes, acts, recovers, persists, and stays within bounds.
A model is a function: tokens in, tokens out. Everything that makes it feel like an agent — state across turns, tool calls, retries, checkpoints, concurrency limits, permission checks, context assembly, traces — lives in the harness, not the model. It's the most under-discussed and highest-leverage code in any agentic system.
Patterns tell you the shape of a solution. The harness is where that shape meets reality: token budgets, partial failures, malformed tool calls, runaway loops, crashed processes, and cost. Two teams can pick the identical patterns and ship wildly different systems based on harness quality alone.
The harness, layer by layer
Maintaining the harness keeps the whole thing healthy over time; observability wraps every run; orchestration runs many loops; each run moves through a task lifecycle and a core loop that assembles context — drawing on the durable grounding beneath it — dispatches tools through a safety layer, and calls a model through a gateway. The sections below build from the inside out.
The sections
| Group | What it covers |
|---|---|
| The Run Loop | The core execution cycle — turn structure, budgets, halting, error recovery, and streaming & steering |
| Context Management | Assembling the prompt each turn, compacting under a token budget, and persisting session state |
| Grounding | The durable knowledge agents can't infer — the context hierarchy from a file, to a repo's .agents/, to a system, to the org |
| Task Lifecycle | Bounding a task — scope and feature lists, verification and definition-of-done, initialization and clean handoff |
| Tools & Capabilities | Dispatching tool calls, and registry and discovery without flooding the window |
| Safety & Trust | Sandboxing, least-privilege permissions and approval gates, and prompt-injection defense |
| Orchestration | Sub-agents, concurrency limits, durable resume, and scheduled or triggered runs |
| Model Access | A gateway that abstracts providers, routes models, and exploits prompt caching |
| Observability | The metrics that matter, plus traces, telemetry, cost accounting, and replay-driven online evaluation |
And one cross-cutting page: Maintaining the Harness — auditing, ablating, and simplifying the harness as models improve, because it is software and rots like software.
How it relates to the catalog
Harness engineering is the runtime counterpart to the Design Patterns catalog. Where the catalog covers reasoning loops, tool integration, and memory as patterns, this section covers how to implement and operate the loop that runs them — and the failure modes, like the Infinite Loop and Amnesiac Agent, that a well-built harness prevents.
A good rule: the model decides, the harness controls. Anything that must be reliable — budgets, permissions, retries, persistence, limits — belongs in the harness, where it's deterministic and testable, not in a prompt where it's a suggestion.