# Why AI Agents Need a Harness, Not Just a Prompt Published 2026-07-28. Updated 2026-09-17. Canonical URL https://log.delaa.dev/blog/2026-07-28-what-is-harness-engineering > Prompt engineering, then context engineering. Harness Engineering is the next phase, the runtime environment that makes AI agents reliable in production. --- A glowing unstable core held in place by an industrial rigging harness In early 2026, [a team at LangChain](https://www.langchain.com/blog/evaluating-deepagents-cli-on-terminal-bench-2-0 "LangChain's own writeup on moving from Top 30 to Top 5 on Terminal Bench 2.0 without changing the model") improved their agent's Terminal Bench 2.0 ranking from 30th to 5th place **without changing the underlying model at all**. The only change was the system around the model, and how tools were called, how errors were recovered, how context was managed. Around the same time, [an independent experiment](https://blog.can.ac/2026/02/12/the-harness-problem/ "Can.ac's benchmark showing a coding-task score jump from switching edit-tool formats, with no model change") showed that the same model, with only a change to its file-editing interface format, went from a 6.7% coding benchmark score to 68.3%. Same intelligence. Different environment. These two results point to the same conclusion. The bottleneck in AI agent reliability is no longer the model. It is the operational environment surrounding it, the **harness**. This article is the first of a two-part series defining Harness Engineering, its layers, its maturity model, and why 2026 is the year it became the primary focus of AI engineering investment. ## The three phases of AI engineering AI engineering has progressed through three distinct phases. | Phase | Period | Focus | Question answered | |---|---|---|---| | **Prompt Engineering** | 2022-2023 | How to write instructions | "How do I make the model respond correctly?" | | **Context Engineering** | 2024-2025 | What information to provide | "What should the model see to answer well?" | | **Harness Engineering** | **2026-** | How to build the runtime | "How do I make the agent reliable over a long chain of actions?" | **Prompt engineering** optimized the input. System prompts, few-shot examples, output formatting. It was the right bottleneck when a single LLM call was the whole interaction. **Context engineering** added RAG, MCP servers, codebase indexing, and structured retrieval. The model needed the right information at the right time. This is where most production AI systems operated through 2025. **Harness engineering** addresses what neither of the earlier phases could. The agent executes multiple steps, uses tools, modifies state, and must recover from errors without human intervention at every step. The question shifts from "can the model generate correct code?" to "can the system produce a verifiable, attributable, maintainable result over 50 steps?" ## Agent = Model + Harness The core formula that defines the discipline is simple. > **Agent = Model + Harness** The model provides reasoning and generation. The harness provides everything else: what the agent can see, what tools it can use, how it receives feedback, how its output is validated, what happens when it makes a mistake, and how its actions are traced and audited. **Model is the CPU. Harness is the operating system.** A CPU alone does nothing useful. The OS gives it files, processes, memory management, and error handling. A model alone generates text. The harness transforms that into a reliable engineering tool. ## The five layers of a production harness Based on the [Faros AI framework](https://www.faros.ai/blog/harness-engineering "Faros AI's public writeup naming the five-layer harness structure") and cross-referenced against production implementations, a complete harness has five layers. ### 1. Tool Orchestration The control plane governing how agents select, chain, and execute tools. This layer handles dynamic error recovery for resilient workflows, what happens when an API call fails, when a tool returns an unexpected format, when a step times out. Without tool orchestration, an agent that hits an error is stuck. With it, the agent retries with backoff, picks an alternative tool, or escalates to a human without crashing the entire workflow. ### 2. Verification Loops Automated quality checks evaluated during execution, not just at the end. Unit tests, self-critique prompts, build validation, and type checking run while the agent works, catching errors before they compound. Here's the key insight. An agent that writes 50 files and only discovers a type error at the end has wasted all intermediate work. Verification loops catch the error after file 3, when the cost of correction is still low. ### 3. Context and Memory Systems that index codebases, persist session history, and maintain project knowledge so agents can follow established patterns without relearning them each time. This includes the following: - **Episodic memory**: what happened in the current and past sessions - **Semantic memory**: how the project is structured, what conventions apply - **Procedural memory**: how specific tasks are done, canonical code shapes - **Working memory**: what the agent is doing right now, what it has already tried ### 4. Guardrails Hard limits, security boundaries, budget ceilings, and human-in-the-loop controls. These are the non-negotiable constraints that prevent an agent from doing permanent damage, including from threats a rule alone can't catch, like [indirect prompt injection hidden in plain text](/blog/anatomy-indirect-prompt-injection-hidden-plain-text): - Permission boundaries (read-only vs. write access per scope) - Sandboxed execution environments - Cost caps per session or per action - Mandatory human approval before destructive operations (merge, publish, delete) - Blocked actions (no deployment from dev, no force-push to shared branches) ### 5. Observability Telemetry, execution tracing, and audit logs for debugging failures and proving system reliability. When an agent produces a wrong result, the observability layer answers: what did it see, what did it try, where did it go wrong, and what was the final output? ## Three failure modes that harness engineering prevents The Faros AI framework identifies three common patterns of agent failure that harness engineering directly addresses. Victory declaration bias is the agent marking a task complete without verifying the result actually works. The code compiles, so the feature is done, never mind that it doesn't handle the edge case the task specifically called out. Context anxiety shows up as the agent rushes when its context window approaches the limit, producing lower-quality output or silently dropping requirements near the end of a long session. And one-shotting overreach is the agent tackling an entire problem at once instead of breaking it into incremental steps, which produces large, tangled changes that are hard to review, hard to revert, and hard to attribute when something breaks. A harness counters these structurally. Verification loops catch victory bias. Context management reduces anxiety. Task specification and tool orchestration break problems into verifiable steps. ## The academic maturity model Early 2026 saw the first formalization of Harness Engineering as an academic discipline, [Zhong & Zhu's "AI Harness Engineering: A Runtime Substrate for Foundation-Model Software Agents"](https://arxiv.org/abs/2605.13357 "The 2026 paper that first formalized Harness Engineering, naming eleven component responsibilities and the maturity model below"), the paper that named eleven component responsibilities a harness must cover and proposed the maturity model below. | Level | Name | Property | |---|---|---| | **H0** | No harness | Raw model output, no guardrails | | **H1** | Reactive harness | Guards catch errors after they happen | | **H2** | Proactive harness | Structured context prevents errors | | **H3** | Adaptive harness | Harness learns from past failures automatically | Most production AI coding assistants in 2026 operate at H1-H2. They have guardrails and context management, but lack the systematic failure attribution and automated learning that define H3. ## Why 2026 is the year Three signals converged to make Harness Engineering the dominant concern in 2026. The first is that agent scope outgrew prompt engineering. Early AI coding tools suggested completions, then wrote functions, and by 2026 agents were writing entire features, refactoring codebases, managing deployments, and executing multi-step workflows. The failure mode shifted from "wrong output" to "wrong system modification", a much higher-cost failure. The second is that the model became a commodity. Multiple providers reached comparable reasoning capability, so the differentiating factor became the infrastructure around the model. Tool access, context management, verification, safety. Companies stopped asking "which model is best?" and started asking "how do we make any model reliable in our environment?" The third is AI code fatigue. AI-generated code looked polished and complete, which led to review fatigue. Defects slipped through not because they were hidden, but because the volume and quality of output exceeded human review capacity. Harness engineering shifted the verification burden from human reviewers to automated systems. I've watched this shift happen in my own agent work over the past year. The model choice stopped being the thing I debugged. The harness (the retry logic, the verification step, the guardrail that stops a destructive action) became the thing that actually determined whether a session succeeded. ## Strapi on harness engineering In [their IFTTD #364 interview](https://www.ifttd.io/episodes/strapi "Strapi CEO Pierre Burgy discussing harness engineering as Strapi's next technical bet, July 2026"), Pierre Burgy, CEO of Strapi, described harness engineering as Strapi's latest technical bet. It's about making AI agents built by developers accessible to marketing and communication teams through **Fimo**, their "website operating system." Burgy's framing is notable. He positions harness engineering not as a developer productivity tool, but as a **bridge between technical and non-technical teams**. Developers build agents locally (Claude Code, Codex). Fimo absorbs those agents so marketing teams can run them triggered manually or on a schedule. Some actions require human-in-the-loop (security-sensitive operations), while micro-optimizations (SEO, content suggestions) run autonomously. > "We've loosened up a bit. You have to take risks. In a world where > everything moves so fast, you have to dare." — Pierre Burgy, Strapi CEO (translated from French) The host, Bruno, draws the parallel. Strapi bet on TypeScript early, on GraphQL early, and now on Harness Engineering, "the paint isn't dry yet, the dust hasn't settled yet" (translated from French). The concept is still forming, and Strapi is already building products around it. --- Harness Engineering is not a replacement for prompt engineering or context engineering. It is the layer above them, the operational environment that makes both effective over long, complex, high-stakes tasks. [The second article in this series](/blog/built-harness-before-it-had-name) examines a concrete implementation of these principles. It follows a `.claude/wiki/` system that evolved across four generations of projects, and how it maps to (and in some ways exceeds) the formal Harness Engineering framework. --- — Delaa