Foundations of Harness Engineering

Key takeaways

• Harness engineering is system design around what an agent can see, how it judges progress, where it must stop, and how its work is verified.
• The bottleneck shifts with work length: prompt for one response, context for multi-file work, harness for multi-hour work, and platform for team use.
• Most long-running failures come from thin repo context, vague done criteria, weak verification, stale docs, and undefined approval points, not weak models.
• In 2026 the harness became infrastructure for approval, isolation, tool access, audit logs, and provider setup via SDKs, MCP, sandboxes, hooks, and plugins.
• Stronger models simplify harness details but do not remove the need for work environments, evaluation criteria, approval structures, and operating loops.

Harness engineering is less about telling an agent what to do and more about designing what it can see, how it judges progress, where it must stop, and how its work is verified.

The Bottleneck Moves as Work Gets Longer

Why Prompting Is Not Enough

Prompt quality can matter a lot for short work. But as tasks become larger and repositories become more complex, failures come from other places.

• The repository does not contain enough current context.
• The definition of done is vague, so the agent declares victory early.
• Verification is weak, so the output only looks correct.
• Old docs and old rules pollute context.
• Approval points are not defined, so risky and safe work are treated alike.

The issue is often not that the model is weak. The issue is that the workbench around the model is poorly designed.

What Changed

Recent coding agents can run longer, use browsers and shells, inspect logs, and interact with deployment systems. That makes the question less about "how do I get one good answer?" and more about "how do I keep a multi-hour task aligned and auditable?"

OpenAI's 2026-02-11 harness engineering article emphasized agent-readable repositories, short AGENTS.md files, structured docs/, browser and observability access, and documentation gardening. Anthropic's 2026-03-24 harness article emphasized when planner and evaluator scaffolding is load-bearing and when stronger models let teams remove unneeded scaffolding.

Anthropic's 2026-03-25 auto mode article and 2026-04-08 Managed Agents article extend that view. Permission prompts become a policy and classification problem, not just a UI prompt. Sessions, harnesses, and sandboxes become separate failure, security, and scaling boundaries. The key question is not "how autonomous can the agent be?" It is what can be auto-approved, what needs a classifier, and which credentials must never be reachable from generated code.

In April and May 2026, the same ideas also moved into product primitives. OpenAI Agents SDK exposed model-native harnesses, native sandbox execution, MCP, skills, AGENTS.md, shell, apply_patch, memory, and compaction patterns. Codex added remote connections, hooks, programmatic access tokens, Secure MCP Tunnel, and the OpenAI Developers plugin. The harness is becoming infrastructure for approval, isolation, tool access, audit logs, and provider setup.

2026 Source Questions

What a Harness Produces

A good harness leaves concrete artifacts in the repository and runtime.

• A short and current AGENTS.md or equivalent entry document.
• Version-controlled architecture and domain rules.
• Plans, release gates, test routines, and QA checklists.
• Slash commands, skills, agent definitions, and plugins.
• Workflows showing who approves what and when.
• Sandbox, MCP, hooks, remote connections, and permission classifier policy.
• Provider plugins, domain templates, and connectors for repeated setup.
• A maintenance loop that removes stale rules.

Symptoms of a Team Without a Harness

Antipatterns

• Putting every rule into one giant file.
• Relying on implicit "you know what I mean" context.
• Managing docs and workflows separately.
• Generating more output without evaluation criteria.
• Copying an external harness without domain rules.

Sentence to Remember

Harness engineering is not a secret prompt technique. It is the system design around the places where models are most likely to fail.