Harness Engineering

Harness engineering is the practice of building the extra-model infrastructure — environment, toolchains, safety constraints, and verification systems — that channels an AI agent's capability, defines its boundaries, and verifies its work. It represents the third generation of AI interaction design: prompt engineering (2022–2023) taught us how to talk to models, context engineering (2024–2025) taught us what to show them, and harness engineering (2026–) teaches us how to contain and direct them as autonomous systems.

The shift is structural. When models were stateless question-answerers, the prompt was the entire interface. When models gained tool use and retrieval, context became the bottleneck. Now that agents run for hours, spawn sub-agents, modify filesystems, and make purchases, the harness — the system that governs how the agent operates — determines whether the result is useful or catastrophic. Organizations leading in AI product quality in 2026 are those with the most mature harness engineering practices: teams that treat the harness as the product and the model as a replaceable component inside it.

Core Disciplines

Context engineering remains a foundation, but harness engineering extends far beyond it. Practitioners must design verification loops — mechanisms that check agent output against specifications, run test suites, and loop failures back to the model with diagnostic context. They must build state management systems that preserve agent progress across interruptions, context window resets, and sub-agent handoffs. Tool orchestration determines which capabilities are exposed under what conditions — and critically, which are withheld, since reducing available tools often improves performance.

Human-in-the-loop design gates irreversible actions without creating bottlenecks that defeat the purpose of automation. Observability provides real-time visibility into what agents are doing, why, and where they fail — essential for debugging systems where the decision-making is opaque by nature. And multi-session coordination handles the reality that production agent tasks often span hours or days, requiring checkpoint, resume, and handoff capabilities.

The Maturity Curve

Harness engineering maturity separates compelling demos from reliable production systems. At the low end, a thin wrapper sends prompts to a model and returns responses. At the high end, a production harness manages human approvals, filesystem sandboxing, sub-agent lifecycles, prompt libraries, compaction strategies, and failure recovery — intervening minimally but preventing catastrophic outcomes. Building production-ready harnesses requires months to years of investment, which is precisely why harness quality creates durable competitive advantage.

The discipline draws on agentic engineering principles but is more infrastructure-focused. Where agentic engineering addresses the design of agent behavior and capabilities, harness engineering addresses the systems that make that behavior safe, reliable, and observable at scale. It intersects with agent orchestration (managing multi-agent workflows), agentic memory (persistent context), and the broader agentic web infrastructure stack.

Harness Changes Are Quality Changes

The clearest public evidence that the harness can degrade an agent on its own is Anthropic's postmortem of April 23, 2026. Anthropic traced a month of reports that Claude's responses had worsened to three separate changes in Claude Code, the Claude Agent SDK and Claude Cowork, and stated that the API was not impacted. None was a model change. On March 4 the default reasoning effort in Claude Code was lowered from high to medium to reduce latency; it was reverted on April 7. On March 26 a caching optimization meant to clear old reasoning from sessions idle for over an hour shipped with a bug that discarded earlier reasoning on every subsequent turn, which made the agent seem forgetful and repetitive; it was fixed on April 10. On April 16 a system-prompt instruction to reduce verbosity was added; broader ablations later showed a 3% drop on one evaluation for both Opus 4.6 and 4.7, and it was reverted on April 20.

Two details matter for practice. First, Anthropic notes that neither its internal usage nor its evals initially reproduced the problems users described, and that because each change hit a different slice of traffic on a different schedule, the aggregate looked like broad, inconsistent degradation that was hard to distinguish from normal variation in feedback. Second, the remedies are process controls, not model work: per-model evals for every system prompt change, ablations to understand the effect of individual prompt lines, tooling to review and audit prompt changes, soak periods, broader eval suites, gradual rollouts, and having more staff use the exact public build. The postmortem gives one quantified figure (the 3% drop) and does not compare the regressions to a model swap; the stronger claim that harness changes matter as much as model changes is practitioner inference, not something the document states.

The working rule that follows is eval-gating: system prompts, tool descriptions, effort defaults, caching behavior and context compaction policy are versioned artifacts, and a change to any of them passes the same agent evals a model upgrade would before rollout. It is a core part of agent reliability, since users experience the model and harness as one system and cannot tell which of the two regressed.

Implications

The emergence of harness engineering as a named discipline signals something important about where AI value creation is heading. If models are commoditizing — and the evidence from interchangeable foundation model usage in products like Manus suggests they are — then the differentiator is the system around the model. The best harness engineers will be the AI equivalents of the infrastructure engineers who built AWS, Kubernetes, and the modern cloud stack: the people who make raw capability into reliable service.