Harness Engineering: The Maturity Layer After Prompt and Context Engineering

Teams spend weeks refining prompts and assembling context packets, then blame the model when the agent stalls halfway through a task. The model is rarely the problem. The reliability gap lives in the harness: the software around the model that decides what it sees, what it can do, and what happens when it fails. We have just published a cluster of new glossary terms and resources that name this layer and the practice of building it.

What a Harness Actually Is

An Agent Harness is the non-model software that turns a language model into a working agent. It is the loop, the tools, the context management, the memory, the recovery logic, and the guardrails. The model supplies reasoning. The harness supplies everything that makes that reasoning operational against a real codebase.

At the center sits the Agent Loop: the model-tool-observation control cycle that runs until the task is done or stopped. The model proposes an action, the harness executes a tool, the result returns as an observation, and the cycle repeats. Plan-and-execute (Wang et al., 2023, implemented in LangChain as Plan-and-Execute) and ReAct (Yao et al., 2023) are specific shapes of this loop, not alternatives to it.

Three design choices inside the harness determine whether that loop produces reliable work:

• Tool Design: how tools are named, how granular they are, what their error messages say, and when their documentation is loaded. A tool that returns a vague error teaches the agent nothing. A tool that returns a precise, actionable error lets the agent correct itself.
• Context Compaction: reducing the agent's accumulated context mid-run through summarization or full resets, so a long task stays inside the window without losing the state it needs to finish.
• Progressive Disclosure: layering information by relevance and loading only what the agent needs at each stage, rather than front-loading everything and drowning the model in noise.

None of these are model settings. They are engineering decisions, and they are where most of the reliability comes from.

From Claude Code to Open-Source Harnesses

The harness concept is not abstract. It is the category to which the most common agentic coding tools belong.

The two clearest examples are Claude Code and Codex Cli. Claude Code is Anthropic's command-line agent: a terminal-native loop with file editing, command execution, and codebase-wide context. Codex Cli is OpenAI's command-line agent that occupies the same role for its models. Both are harnesses in the precise sense used here. They wrap a model in a loop, a tool set, and a context strategy, and the differences between them are differences of harness design, not of raw model capability.

Other widely used harnesses take the same idea into different surfaces: Cursor and Windsurf embed the loop in an editor, Github Copilot runs an agent mode inside the existing developer workflow, and Aider and Opencode are open-source command-line agents. The model underneath is often the same across several of these tools. What distinguishes them is the harness: how they manage context, design their tools, and recover from failure.

This is the practical takeaway. When two teams using the same model get different results, the harness is usually the variable.

Harness Engineering as an Emerging Discipline

Harness Engineering is the discipline of designing and iterating the harness so the agent works reliably. It is the maturity layer that comes after prompt engineering and context engineering. Prompt engineering improves a single instruction. Context engineering improves what the agent knows. Harness engineering improves the system that runs the agent across many steps, and it is measured by whether the agent finishes the correct work without supervision.

What does harness engineering actually involve? It is less a checklist than a set of design principles, and a popular harness is the clearest place to see them. Consider the principles inside Claude Code:

• A tight agent loop over real tools. The model acts, observes the result, and corrects, instead of producing one large answer in isolation.
• Deliberate context management. Persistent project memory, retrieval, and compaction keep the right information in the window rather than everything (context engineering).
• Tools designed for the agent. Clear names and actionable error messages let the model recover on its own (tool design).
• Guardrails and human-in-the-loop. Permissions and approvals gate sensitive actions instead of trusting the agent blindly.
• Verification before completion. The agent checks its work against ground truth, such as tests and builds, before claiming a task is done.
• Stable interfaces over a changing core. The surface a developer uses stays steady while the internals are tuned (building effective agents).

These principles, not the underlying model, are what make a harness reliable. Anthropic documents how they hold up at scale in harnesses for long-running agents.

This is also why most companies should not build their own harness. The frontier labs and a handful of specialized startups iterate on these systems full time, against private benchmarks, with far more signal than any single engineering organization can gather. For most teams, the better move is to adopt a mature harness and invest the saved effort one layer up. Building the harness is where labs and startups are best positioned. Building on top of it is where everyone else creates an advantage.

The agent loop sits inside the harness: the model acts, tools return observations, and the harness manages context, guardrails, and recovery around the cycle.

From Harness to Productivity

A harness is still an open canvas. It works like a CI tool: it provides the execution substrate, but the value comes from what you layer on top. Design patterns, curated or custom skills, review processes, and gates are what turn a generic harness into the way a specific team builds software.

This is the role of the Meta Harness: the abstraction that makes a harness part of a company's or a developer's ways of working. In practice, this can mean coordinating more than one harness, but not necessarily. The essential function is integration: encoding the patterns, skills, and guardrails onto the harness so they travel with the work rather than living in one person's head.

The stack: the model layer is a shared commodity, the harness makes it operational, and the meta-harness integrates it into a team's ways of working. Leverage increases as you move up.

Formally, a Meta Harness is a substrate or control plane that hosts multiple pluggable, swappable agent harnesses on a shared runtime. The new Omnigent resource is a concrete example: an open-source meta-harness from Databricks that sits above existing coding agents, including Claude Code and Codex Cli, and makes them composable, controllable, and shareable through a single interface under Apache 2.0. The multi-harness case is the most visible, but the same integration layer still matters even when a team standardizes on a single harness.

A Self Improving Harness goes further. It observes its own runs, edits its own scaffolding, and keeps a change only when that change passes a held-out benchmark. This is harness engineering applied recursively, with a hard guardrail: deterministic validation against a benchmark decides what survives, not the agent's own judgment of its work.

Takeaways

• The harness is the variable, not the model. When agents underperform on the same model, audit the Agent Loop, Tool Design, and context strategy first.
• Do not build your own harness. Adopt a mature one. Labs and specialized startups are best positioned to build harnesses; your time is better spent elsewhere.
• Invest one layer up. Differentiation lives in your ways of working: patterns, curated or custom skills, review processes, and gates, integrated through the Meta Harness layer.
• Treat the model as a commodity. The same models are available to everyone, so advantage rises up the stack.

The new glossary terms give this layer a shared vocabulary. The practice of building it well is Harness Engineering, and it is what decides whether agents become a liability or a force multiplier.