What even is the harness in AI?

I recently saw OpenClaw referred to as a harness. I thought, “That’s interesting. OpenClaw isn’t a harness. It’s an agent runtime—it drives the agent loop.” So, what does the word "harness" even mean?

The conversation so far

The structural baseline for the concept comes from Birgitta Böckeler's April 2026 article, which elegantly defines an agent as model + harness = agent. She bifurcated the stack into a builder harness (the inner runtime shipped with the tool) and a user harness (the developer's custom context). This definition built on a wave of discussion from February 2026, which included Mitchell Hashimoto's pragmatic approach to engineering AGENTS.mdcontexts, OpenAI's overview of internal harness engineering for automated deployment, and Böckeler's original summary memo.

5 layers, outside-in

I think there’s more to an agent than model + harness. For me, this starts with the observation that we just can’t trust the agent runtime. In order to get some certainty about the software supply chain security of code produced by an agent factory, we need a distinct sandbox layer that we can use to capture provenance information and limit the possible impact of an agent off the rails.

I think of this secure agent runtime architecture as a matryoshka doll, outside-in:

Infrastructure → sandbox → harness → runtime → model

Each layer has a different owner, a different failure mode, and a different design principle. Let's walk through them.

Layer 1: Infrastructure

The infrastructure is where agents physically run. It could be GitHub Actions runners, Kubernetes pods, or virtual machines (VMs). This layer is about compute, networking, and resource management, and it matters more than people think.

Consider what happens when you scale from one agent to dozens running in parallel. Roy Belio got Andrej Karpathy's autoresearch system running 198 autonomous experiments on OpenShift AI—including GPU scheduling and job orchestration with zero human intervention. That isn't a harness problem. It isn't a sandbox problem. It is an infrastructure problem. Can your platform manage competing resource claims, keep concurrent agents from starving each other, and schedule GPU workloads?

GPU scheduling itself is becoming a first-class infrastructure discipline. Red Hat OpenShift 4.21 shipped dynamic resource allocation—a Kubernetes API that lets workloads request GPUs by attributes (model, memory, compute capability) rather than raw counts. It also enables GPU sharing across containers, so lightweight inference sidecars don't waste an entire device. This is pure infrastructure—no sandbox policy, no AGENTS.md entry, no model choice. Just the platform doing its job.

Layer 2: Sandbox

The sandbox constrains what the agent can do and limits potential impact if something goes wrong. It’s about isolation. My colleague, Marta Anon Ruiz, described this layer as, “shaping the intentionality of the agent.” Projects like NVIDIA’s OpenShell operate on this layer. From a software supply chain security perspective, this is your primary trust boundary, the difference between an agent that can rm -rf /and one that can't, or the difference between an agent that can gh issue delete all of your GitHub issues and one that can't (or, one that can write and execute its own script to do the same).

If the infrastructure asks, "Where does the agent run?" the sandbox asks, "What is the agent allowed to touch?" These are different questions with different answers.

Red Hat published a detailed guide on building resilient guardrails for AI agents on Kubernetes, including restricted-v2 security context constraints (SCC), default-deny egress NetworkPolicies, and per-agent role-based access control (RBAC). Each of these is a subtractive control where you start with everything the agent can do and remove capabilities until only the necessary ones remain.

The sandbox layer goes deeper than network policies. Red Hat OpenShift sandboxed containers—based on Kata Containers and peer-pods—is a key technology at this layer, taking extra steps to isolate an agent process from its host. Also, check out the article on agent skills and security threats, which explores threats and solutions, including cryptographic signing of agent skills so you can verify provenance before execution. An unsigned skill injected into an agent's toolchain is a software supply chain attack. The sandbox layer can help account for that.

Projects like NVIDIA's OpenShell are relevant at this layer, as are the security primitives baked into general container runtimes. None of these are "harnesses" in the Hashimoto sense—you aren't teaching the agent to do better work, you're preventing it from doing dangerous or unexpected work.

Layer 3: Agent harness

This is the layer Hashimoto wrote about, and is what Birgitta Böckeler calls the user harness. This is the enablement layer, which includes AGENTS.md files, skills, custom tools, hand-crafted linters, system prompts, and a good test suite. These are the things you engineer iteratively to increase the chances the agent gets things right.

Marco Rizzi’s article on harness engineering with structured workflows crystallizes the principle, "structure in, structure out." The article describes scanning project structure with LSP and MCP to generate context-aware prompts—not just telling the agent what to do, but giving it the structural information it needs to do it well. This is feedforward control in Birgitta's terminology.

Tool-use is a critical part of the harness that enables what Birgitta Böckeler calls computational guides. The advent of tool use, and the standard stepping stone of MCP, has made meaningful agents possible, giving the agent runtime a better chance at achieving its goals. Building effective AI agents with MCP goes into depth on MCP, showing how you can enable agents by giving their harness a way to access your enterprise’s resources dynamically.

How do you know your harness works? You evaluate it. Michael Dawson writes about eval-driven development, laying out an 8-stage evaluation framework using DeepEval and LLM-as-judge patterns. Evals are the feedback loop that tells you whether your harness changes made the agent better or worse. Without them, harness engineering is guesswork. Tools like evaluation hub help manage that at scale.

Harness artifacts have a management problem. As your AGENTS.md grows, as your custom tools multiply, as your system prompts evolve,how do you version them? How do you share them across projects? The article on Lola, an AI context package manager, treats AI context as versioned packages. That framing makes sense. If your harness artifacts are engineering artifacts, manage them like engineering artifacts.

Layer 4: Agent runtime

The agent runtime is the engine driving the agent loop. Claude Code, OpenCode, Goose, or something custom-built. It handles tool dispatch, context windows, and conversation management.

This is what Anthropic called a "harness" in that email. I think that's incorrect—or at least imprecise. The runtime isn’t something you can engineer and improve unless you build your own. It executes the loop: send prompt, receive response, dispatch tool calls, feed results back. I can’t minimize the importance of this layer. Runtimes are getting better and better and we’re all benefitting.

But some organizations will build their own. If you have sovereignty requirements, need capabilities that no off-the-shelf runtime provides, or if your use case calls for an especially high degree of control of the runtime’s behavior, then you need to build your own, and you need APIs upon which to build. This is where projects like Llama Stack matter, exposing open APIs for responses, file handling, search, and someday memory. A sovereign runtime built on open APIs is a different proposition from one locked to a proprietary service. Red Hat's platforms support both paths: teams that adopt an existing runtime and engineer the user harness around it, and teams that build their own runtime against open APIs because their context demands it.

Layer 5: Model and inference endpoint

On the serving side, Red Hat's guide to integrating Claude Code with Red Hat AI Inference Server on OpenShift puts vLLM on Red Hat AI for on-prem inference. Your model, your cluster, your data. Running inference on your own hardware has a big impact on the trust model of your entire agent stack.

On the provenance side, Red Hat's work on modern software supply chain security, specifically Red Hat Trusted Artifact Signer and cryptographic model signing, matters here. If you cannot verify and manage the provenance of the model you are running, your entire stack above it is built on an unverified foundation. Model signing is to the model layer what skill signing is to the harness layer, a cryptographic guarantee that you are running what you think you are running.

Subtractive versus additive

The sandbox and the harness have opposite design philosophies. The sandbox is subtractive—you’re taking away capabilities to reduce risk. The harness is additive—you’re layering on knowledge and tools to increase competence. If we conflate them, we’ll muddy the design principles that should guide each one.

They also have different failure modes. A sandbox failure means the agent did something it shouldn’t have been able to do. A harness failure means the agent did something poorly that it should have done well. These are different problems requiring different responses.

The sandbox has an opportunity to play a secondary role as a recorder—a neutral observer of the agent’s activities—that can attest to what it did in a way that’s more worthy of trust than the agent runtime self-attesting.

The sandbox constrains and observes. The harness enables and you can improve it. The runtime executes and you shouldn’t build your own unless you must. Agents are only as safe and reliable as the stack underneath them and Red Hat is building that stack—open source, at every layer, from GPU scheduling to cryptographic model signing. If you're deploying agents in production and want a foundation you can verify, not just hope for, that's where we’re headed.