---
title: "Harness engineering is becoming the real discipline behind reliable AI agents"
description: "Model quality alone doesn't determine agent reliability. The harness — instructions, tools, permissions, retrieval, verification — is the real engineering problem."
date: "2026-04-04"
author: "Mojar AI Team"
tags: ["AI agents", "harness engineering", "enterprise AI", "agentic AI", "knowledge management"]
keywords: ["harness engineering", "AI agents", "agent reliability", "enterprise AI", "knowledge governance"]
type: "explainer"
related:
  - title: "You can't stress-test an enterprise agent built on ungoverned knowledge"
    url: "/blog/industry-news/you-cant-stress-test-an-enterprise-agent-built-on-ungoverned-knowledge"
  - title: "Context engineering and enterprise AI"
    url: "/blog/industry-news/context-engineering-enterprise-ai"
---

## A new term is landing in the right rooms

Something shifted in San Francisco last week. The people actually shipping production agents — engineering leads, CTOs, early founders — weren't debating which model to run. They were comparing notes on everything else: instruction design, tool permission scoping, runtime isolation, verification loops, observability pipelines.

The word for all of that is starting to stabilize. It's called harness engineering.

OpenAI formalized the phrase in February with a post titled "Harness engineering: leveraging Codex in an agent-first world" ([OpenAI](https://openai.com/index/harness-engineering/)). Security Boulevard ran a field report from those San Francisco conversations on April 3, pairing the term explicitly with "AI factories" — the org-level systems turning intent into shipped work at scale ([Security Boulevard](https://securityboulevard.com/2026/04/everything-i-learned-about-harness-engineering-and-ai-factories-in-san-francisco-april-2026/)). On March 31, Hacker News surfaced an Ask HN post: "What are the best resources to learn about Harness Engineering?" By April 2, the term had been picked up by 36Kr — a Chinese tech publication — which means it's no longer circulating inside a narrow US devtools conversation.

This is how a discipline gets named. The shared vocabulary arrives, people start looking for curricula, and then the job descriptions follow.

## Why better models didn't solve the problem

The pattern from 2024 into 2025 was consistent: smarter model ships, enterprise teams upgrade, agent reliability ticks up marginally, then the same failure categories reappear.

The failures clustered around the same things. Agents retrieving outdated or contradictory information. Agents taking actions based on incomplete context. Results that nobody could audit. Tool permission errors mid-task.

None of those are model problems. A more capable model applied to a broken harness produces more confidently wrong outputs, faster.

OpenAI's account of building a full product with zero manually-written code makes this concrete. Three engineers directing Codex to produce roughly a million lines of code over five months. The bottleneck wasn't model capability. It was the environment: "The agent lacked the tools, abstractions, and internal structure required to make progress toward high-level goals. The primary job of our engineering team became enabling the agents to do useful work." ([OpenAI](https://openai.com/index/harness-engineering/))

That is a description of harness engineering, even when nobody called it that yet.

## What the harness actually contains

The Security Boulevard field report offers the clearest working definition circulating among practitioners right now:

> "Harness: Everything around the model: instructions, context, tools, runtime, permissions, review loops, verification."

Each component has its own failure mode and needs deliberate design.

### Instructions and system prompts

How the agent understands its role, constraints, and operating rules. Vague or contradictory instructions create unpredictable behavior regardless of what model sits underneath. Most teams underinvest here early and pay for it in production.

### Context and retrieval

What the agent can actually see when it runs. This covers what documents get retrieved, how retrieval is structured, and whether the underlying knowledge is accurate and current. It sounds like an infrastructure detail. It's one of the primary sources of production failures.

### Tool access and permissions

What the agent is allowed to do. Overly permissive agents expose organizations to real security risk. Overly constrained agents can't complete tasks and end up requiring more human intervention than they save.

### Runtime controls and isolation

How the agent runs, what it can access in the environment, and how to prevent one agent's state from contaminating another's. Multi-agent setups make this especially important — and especially easy to get wrong.

### Verification and review loops

How the agent checks its own work and how humans stay in the loop without becoming the bottleneck. This is the part most teams bolt on late, after discovering they can't trust the output at scale.

### Observability and telemetry

Whether you can actually see what the agent retrieved, what it decided, and why. An agent that produces wrong answers you can't explain is worse than one that just fails visibly — you can fix a visible failure.

## The knowledge layer is where harnesses quietly break

There's one component that gets less engineering attention than it deserves: the knowledge structure the agent reads from.

Permissions and runtime controls tend to get designed carefully because failures are visible. Agents take wrong actions, workflows break, outputs fail in ways that are hard to ignore. Knowledge failures are quieter. The agent sounds confident. The answer is wrong because the source document is outdated, contradicts another document, or was chunked in a way that retrieval can't parse cleanly. None of that appears in the error logs.

This is a harness failure. It happens upstream of the model.

An agent reading a policy document that was superseded six months ago doesn't know it's outdated. It retrieves it. It grounds its answer in wrong information. If the harness has no mechanism tied to document freshness, the failure is invisible until someone acts on it.

Contradictions are subtler still. Most enterprise knowledge bases contain documents that conflict — different versions of the same policy, inherited content from acquisitions, department SOPs that cut against central guidance. A well-engineered harness needs to account for this, either by resolving contradictions upstream or by building retrieval that surfaces the conflict rather than silently picking one source.

This is why document governance, retrieval quality, and knowledge accuracy belong in the same engineering conversation as permissions and observability — not delegated to a separate content team and forgotten. The knowledge layer is a harness component. [You can't stress-test an enterprise agent built on ungoverned knowledge](/blog/industry-news/you-cant-stress-test-an-enterprise-agent-built-on-ungoverned-knowledge) — and you can't claim a harness is reliable if the knowledge it reads from is stale, contradictory, or badly structured.

[Context engineering](/blog/industry-news/context-engineering-enterprise-ai) is the adjacent practice: structuring what the agent sees at runtime. Harness engineering is broader — it's the full system those runtime decisions sit inside. Both are maturing in parallel, and the boundary between them is mostly academic.

Governed knowledge platforms like [Mojar AI](/) exist specifically to address this layer — structured ingestion, contradiction detection, source attribution on every retrieval, and automated maintenance that keeps documents current. That's not a nice-to-have addition to the harness. It's one of the foundational requirements.

## What to watch

Harness engineering is on the same trajectory as DevOps and platform engineering. Both started as informal collections of practices shared between teams with shared problems. Both accumulated enough vocabulary and tooling to become recognized disciplines. Both eventually showed up in job titles and hiring criteria.

The same process is underway here. Ask HN threads on March 31 looking for curricula, Security Boulevard field reports from SF naming the practice, OpenAI writing it up from internal experience, international tech publications picking it up within days. That's the signal sequence.

The teams pulling ahead in 2026 won't be the ones with access to the best models. Those are largely commoditized. The teams ahead will be the ones that engineered the full harness — and treated the knowledge layer as part of the engineering problem, not an afterthought someone else was supposed to handle.