What Is Harness Engineering? A Guide for Enterprise AI Delivery

TL;DR

• Harness engineering is the discipline of building everything around an AI model except the model itself: context, tools, specs, automated checks, and human review. Shorthand: Agent = Model + Harness.
• Mitchell Hashimoto named the term on 5 February 2026. OpenAI's Ryan Lopopolo put it in a post titled six days later, and it spread from there. Anthropic and Martin Fowler's site (Birgitta Böckeler) have both since published their own frameworks for it.
• Most public guidance covers one agent in one repository. Enterprise delivery needs the same guides-and-sensors discipline across the whole lifecycle, from idea to release, with compliance and multiple teams involved.
• Veracode's 2025 study found AI-generated code introduced security vulnerabilities in 45 percent of tasks tested. That's why the controls around the model carry so much weight.
• Opsera built Forge as exactly that kind of lifecycle-scale harness, and calls it exactly that: the AI harness for enterprise autonomy. This guide walks a legacy modernization project through it stage by stage.

Why Does Harness Engineering Matter Right Now?

Software teams have used test harnesses for decades: scripts and stubs that run a component under controlled conditions and check the result. AI coding agents call for the same discipline, for a different reason. A model shows up to a codebase with no memory of the project, no rules about what it may touch, and nobody reviewing its output by default.

Teams that get dependable results from agents build that surrounding system on purpose. Since February 2026, that practice has had a name and a fast-growing body of writing behind it, from the person who coined it, from OpenAI and Anthropic, and now from enterprise vendors applying it at scale. This guide covers what the term means, where it came from, how it differs from prompt and context engineering, and what it looks like when a platform (Opsera Forge) applies it across an entire enterprise delivery lifecycle rather than one repository.

Where Did the Term Harness Engineering Come From?

Mitchell Hashimoto, co-founder of HashiCorp and creator of Terraform and Vagrant, now builds the Ghostty terminal. On 5 February 2026 he published a post called "My AI Adoption Journey", describing a habit he'd built while working with coding agents: whenever an agent makes a mistake, don't just fix that one instance. Spend the time to engineer a solution so the agent never makes it again. He called this "engineering the harness," and noted he wasn't sure anyone had used the phrase before him.

Six Days Later, OpenAI Landed on the Same Idea

• Six days later, OpenAI's Ryan Lopopolo published "Harness engineering: leveraging Codex in an agent-first world". It told a separate story: an internal team that grew from three to seven engineers and shipped roughly a million lines of code and about 1,500 merged pull requests over five months, with no code written by hand. Hashimoto and the OpenAI team arrived at the idea independently, within days of each other. OpenAI's post carried the term into wider circulation, but Hashimoto coined it.
• Since then, Anthropic has published its own pattern for long-running agents, and Birgitta Böckeler's harness engineering articles on martinfowler.com sorted the same controls into a framework of guides and sensors. The shorthand across all of them: Agent = Model + Harness. The model reasons; the harness decides what it sees, what it may do, and when a person steps in.

Not everyone agrees the discipline deserves a new name. Some practitioners call it solid engineering practice in new packaging, nothing more. That debate doesn't change what the underlying work involves, only whether it needs a label. For enterprises adopting AI agents at scale, the label has turned out useful: it gives a shared vocabulary to controls that used to get scattered across "DevOps," "MLOps," and "AI governance" without ever being named as one practice.

How Does a Harness Work Inside an Agent Loop?

An agent works in a loop, and it reads its context, chooses an action, calls a tool, reads the result, and decides what's next. The harness owns everything in that loop except the reasoning step: what fills the context window, which tools exist, where code runs, what persists between sessions, and when the loop has to stop for a person.

Two useful ways to break that down:

• Databricks splits a production harness into eight building blocks: system prompt, tools, sandbox, filesystem, memory management, feedback loops, guardrails, and observability.
• Böckeler's framing on martinfowler.com sorts the same controls by timing. Guides act before the agent moves and steer it toward good output. Sensors act after it moves and help it correct itself. Each can be computational (deterministic and fast, like tests, linters, and type checkers) or inferential, where a second model reviews meaning at the cost of speed and predictability.

One more distinction is worth keeping straight. The coding harness is the runtime built into the agent itself: Claude Code, Codex, and similar tools handle tool use and orchestration out of the box. The user harness is what a team builds on top of that: convention files, MCP connections, custom review agents. A team doesn't control the first layer's release cycle. It fully controls the second.

A strong harness uses all four combinations of guide/sensor and computational/inferential, and a person steers by improving the harness over time, not by re-prompting the same failure away.

What Does Harness Engineering Look Like in Real Projects?

In OpenAI's account, most of the engineers' time went into the harness, not the feature code. Repository documentation the agent could navigate. Linters and structural tests that enforced architecture. Background tasks that cleaned up drift.

Anthropic published a different pattern in November 2025, for agents that run across many sessions, each starting with no memory of the last. Four artifacts carry the state between sessions:

• A feature list: a JSON file of requirements marked passing or failing, where the agent may only change the status field.
• A progress file: a log of what each session did.
• Git history: descriptive commits that let the next session revert bad work.
• An init script: one command that starts the app, so the agent never has to work that out.

The failure modes Anthropic names read like a checklist for any harness: building everything at once and running out of context, leaving undocumented half-finished work, declaring the project done too early, and marking features complete without end-to-end testing. Each one has a fix that lives in the harness, not in a better prompt.

How Is Harness Engineering Different From Prompt and Context Engineering?

Each term covers a wider area than the one before it. Prompt engineering shapes the wording of an instruction. Context engineering controls which information reaches the model at each step. Harness engineering includes both and adds everything else the agent runs inside.

A team can refine prompts for months and still see the same failure, because the gap sits outside the prompt. A missing approval step, or a missing test, can't be fixed with better phrasing.

Why Do Enterprises Need a Harness That Spans the Whole Lifecycle?

Public harness-engineering guidance (Hashimoto's, OpenAI's, Anthropic's) focuses on one agent working in one repository. Enterprise delivery covers a longer path: idea, requirements, design, stories, code, tests, release. Several teams, compliance rules, and systems of record touch that path, and each handoff is a place an agent can go wrong.

The risk has numbers behind it. Veracode's 2025 GenAI Code Security Report tested more than 100 language models on 80 curated coding tasks. AI-generated code introduced security vulnerabilities in 45 percent of cases, and Java had the highest failure rate, above 70 percent. The code was functional while still insecure, so functional tests alone don't catch it.

Four failure modes show up repeatedly once agents operate at enterprise scale:

• Guessing at vague requirements: an agent given an ambiguous ticket fills the gaps with plausible choices, and nobody sees which ones.
• Drifting from the approved design: without a stored, approved architecture to check against, generated code moves away from what the team agreed.
• Leaking context through tools: instruction files, tool definitions, and connected servers can expose project secrets to places they shouldn't reach.
• Producing more code than anyone can review: throughput rises faster than review capacity, so approvals turn into rubber stamps.

Böckeler's writing on martinfowler.com notes that confirming a feature does what the business wanted is the least-solved part of a harness today. A written spec that a person approved before any code existed gives that check something to measure against. It's also the one thing single-repo harness guidance has the least to say about, since a solo project rarely has a formal spec to check against in the first place.

How Does Opsera Forge Work as a Lifecycle-Scale Harness?

Forge is the AI harness for enterprise autonomy. AI can generate the code, and Forge gives agents the context, specifications, and governance to turn ideas into production. The posture: spec-first, agent-guarded, human-approved.

The gap is the opportunity: nearly all public harness-engineering writing stops at one agent, one repo. Forge is one of the few products built for the version of this problem that shows up once you add multiple teams, a compliance function, and a system of record: the enterprise lifecycle version almost nobody else is writing about.

The default new-build pipeline runs Intent, PRD-Spec, Architecture, an optional UI Design stage, User Stories, Testing, and Application Context. Modernization projects add an Assessment stage at the front. Each stage produces an artifact a person reviews before the next one begins:

Approval records the artifact version without locking it. Editing stays possible. Regenerating an upstream artifact clears every approval downstream, so a changed design can't ride along on stale sign-off.

What Does a Legacy Modernization Project Look Like Inside the Harness?

The clearest way to see a lifecycle harness is to follow a project through it. This scenario is illustrative, not a reported customer case. Forge's modernization journey runs four phases: Discover, Define, Plan, Deliver.

Picture a retailer with a fifteen-year-old order-management monolith on a Sybase ASE database. Several teams depend on it, an audit team wants every change traceable, and engineers want to use AI coding agents without losing control of the design.

Discover turns the legacy code into context an agent can use. The team connects a repo, folder, or ZIP. Forge indexes files and dependencies and prepares the Assessment. No approval is needed here; it only records what exists. The Knowledge Graph's impact radius then lists every caller, importer, and data consumer a change would touch across linked repos, so an engineer can ask in plain English what breaks if the pricing service changes, before any story is written.

Define turns findings into approved requirements. A person resolves each ambiguity before the model can guess. Forge can ask multiple-choice clarifying questions before a stage generates. Security Agents review Intent and PRD-Spec as they're generated, flagging vague requirements and compliance obligations to carry forward.

Plan fixes the design every later agent run is held to. On a modernization project, Architecture produces one artifact with a Migration and Transformation Plan; an architect approves it. User Stories then break the plan into Build, Migrate (verified against legacy behavior), and Decommission (only after its migrations succeed, with rollback stories) types.

Deliver starts when the team saves Application Context. First save creates v1.0.0, the checkpoint agents build against. The Coding Agent then clones the linked repo, writes code, and pushes a branch named forge/wo-{id}, opening a pull request when the provider allows it. Every run ties back to its story, so the change is traceable end to end.

How Do Security Agents Catch Agent Risks Before Code Exists?

Security checks in Forge run at generation time, not after. A Security Agent inspects every artifact as it's produced:

• On Intent and PRD, it looks for vague requirements and missing access-control, data-protection, and logging needs.
• On Architecture, it checks OWASP Top 10 mitigations, auth flows, secrets management, and least-privilege segmentation.
• On User Stories, it adds security stories, penetration-testing tasks, and dependency-scanning tasks.

It also runs Forge-specific checks for prompt injection, tool exfiltration through MCP tool definitions, and scope creep beyond the approved spec.

Findings show as amber or red callouts, and they're informational. They don't block the stage. The same holds for Council Review, an on-demand multi-persona AI deliberation. The gate that blocks is the human approval, not the Security Agent.

The Forge docs include an illustrative case study that shows the approach against an agent-specific threat. A developer clones a repository containing a malicious CLAUDE.md file that instructs the coding assistant to run a shell command before answering any request.

The command quietly posts .env files and keys to an attacker. Forge flags the shell commands in the instruction file, a bash tool with no path restrictions, curl calls in hooks, and secrets reachable from the working directory. It then generates stories to disallow shell instructions in instruction files, restrict the bash tool to the project directory, add a pre-commit scan for injection patterns, and move secrets to environment-level injection.

Through the harness lens: the content policy is a guide that steers the agent before it acts. The pre-commit scan is a sensor that checks the result afterward. It's the same guide/sensor split covered earlier, applied to a real agent-security threat rather than a generic coding mistake.

How Do ForgeScore and Insights Measure the Output?

A harness needs measurement, or nobody can tell whether it's improving. ForgeScore is Forge's engineering health scorecard: a composite 0 to 100 score across eight dimensions (Trust Boundaries, Logic Narrative, Code Excellence, Data Weight, Cognitive Load, System Gravity, Semantic Clarity, Future-Proofing). It also assigns a security grade A to F aligned to NIST CSF 2.0, explicitly described as a point-in-time snapshot, not a compliance certification. Each finding carries a severity, a velocity impact, and compliance references such as OWASP and CWE, and teams can re-score the same source after changes to compare versions.

When enabled, Insights adds delivery, quality, and developer-activity views filtered by team, user, and period, including a Coding Agent view with total runs, success rate, and average duration.

What Makes a Harness Enterprise-Ready?

An enterprise harness has to satisfy security, compliance, and operations teams as well as developers.

So Does the Harness Decide Whether AI Output Ships?

Harness engineering is the context, tools, specifications, checks, and approvals that surround an AI model. Hashimoto named it. OpenAI and Anthropic each published their own version of it independently. The Veracode data shows why the controls around the model carry so much weight. For one agent in one repository, a handful of files and checks can be enough.

Enterprise delivery asks for more: specs before code, approval gates between stages, changes traceable to a requirement and an owner, security checks while artifacts are generated, and a score and trend after delivery. That's the lifecycle harness Forge is built to provide. The gap between "harness engineering for one repo" and "harness engineering for a regulated enterprise" is where this guide and Forge are both aimed.