What Is a Harness?

The Story

In early 2025, OpenAI released Codex -- their autonomous software engineering agent. Around the same time, Anthropic shipped Claude Code. Both used frontier language models. Both targeted developers. Both could read code, write code, and run tests. The products felt completely different.

Claude Code operated in the developer's terminal -- lightweight, transparent, integrated into existing workflows. When its context accumulated too much information, it spawned sub-agents with fresh context windows rather than compressing. It read a CLAUDE.md file from each project directory to learn project-specific conventions. It exposed every tool call in the terminal so the developer could see exactly what the AI was doing.

Codex operated in an isolated cloud sandbox -- each task ran in a containerized environment with its own file system. It designed for "fire and forget" workflows where the developer assigns a task and comes back for the result.

Same underlying technology. Different harnesses. Different products. Different user experiences. Different competitive positions.

The Core Idea

A harness is all the code between the user and the model that isn't the model itself. That sounds abstract until you list what it includes: the context assembly pipeline, the retrieval system that fetches documents, the memory system that maintains state, the tool router that selects and invokes APIs, the template engine that formats output, the permission system, the rate limiter, the logging system, the error handler, the caching layer, and the monitoring system.

In a production AI product, this infrastructure is typically 90% of the codebase. The model call is a single HTTP request inside a system of orchestration, retrieval, caching, logging, permission checking, rate limiting, and fallback handling.

This is why two companies using the exact same model build completely different products. Their harnesses are different. The model is the commodity ingredient. The harness is the recipe.

Three provider philosophies illustrate different approaches. Anthropic builds MCP as an open standard for tool integration and designs Claude Code's harness as a reference implementation. OpenAI ships the Agents SDK with 8 core primitives -- Agent, Runner, Handoff, Guardrail, Tool, Context, Tracing, Model. Google builds ADK with the insight that context isn't stored -- it's assembled fresh for each inference.

The PM must own the harness specification, not just the model prompt. The harness decisions ARE the product decisions. Handing them entirely to engineering means the PM is designing the surface while engineering designs the substance.

Where This Hits in Production

The harness IS the moat. Models are commoditizing. GPT-4o, Claude Sonnet, Gemini Pro -- the capability gap between frontier models narrows with each release. The harness -- retrieval quality, memory architecture, tool orchestration, failure handling, context economics -- is what differentiates products. A competitor can switch models in an afternoon. They can't replicate your harness in a year.

Multi-tenant harness architecture. In enterprise B2B, the harness must serve multiple customers from the same infrastructure with different constitutions, different knowledge bases, different tool permissions, and different compliance requirements. The harness must load the right configuration for the right tenant on every query -- without cross-contamination.

Harness complexity versus product complexity. A common failure: the harness is more complex than the product requires. A simple FAQ chatbot built on an orchestrator framework with multi-agent coordination and dynamic tool routing. The complexity adds latency, cost, and failure modes -- all for zero user benefit. The Harness Decision teaches the discipline directly: start with the simplest harness that could work, and only add complexity when measurable failure of the simpler version forces it.

Connecting the Dots

The harness is where the seven-letter CONTEXT framework transitions from design artefact to running system. Level 1 taught how each layer works individually. Level 2 teaches how to build the infrastructure that assembles, manages, and governs all seven layers together at production scale.

The PM's role evolves here. In Level 1, the PM was a Context Designer -- hand-crafting what goes into each layer. In Level 2, the PM becomes a System Architect -- designing the automated systems that assemble context dynamically. The PM no longer writes individual prompts for each query. They design pipelines, define lifecycle policies, set economic constraints, and specify observability requirements.

The eval connection sharpens. Model-output evals test answer quality. Harness evaluation tests whether the system assembled the right context -- did retrieval work? did memory load? did tool selection succeed? A model can give a perfect response to the context it received and still produce a terrible user experience because the harness fed it the wrong context. For the harness-aware eval discipline that fixes this, see Evaluating the Harness.

The thought that keeps coming back as I build this material: the biggest lie in AI product management is "we need a better model." In almost every case, what you need is a better harness. The model is already good enough. The infrastructure that feeds it is not.

In Practice: Three Harness Architectures

Here's what different harness designs look like for the same use case -- a customer support AI for a SaaS platform -- to show how harness decisions create different products from the same model.

Remember This

1. The harness is the 90% of your AI product that isn't the model -- context assembly, retrieval, memory, tool routing, permissions, caching, logging, error handling, and monitoring. Two companies using the identical model build different products because their harnesses are different.

2. Models are commoditizing. The harness is the moat. A competitor can switch models in an afternoon. They can't replicate your harness in a year.

3. The PM must own the harness specification -- not the code, the specification. What gets retrieved, how much memory loads, which tools for which intents, what happens on failure, what's the token budget. These are product decisions disguised as engineering decisions.