The Harness is the agent: what's inside?

No 1 driver of agent performance and adoption, the harness.

Intro

The market has recently converged on a new trendy term: the harness. The intuition is clear, cf Langchain formalization the harness is everything that is not the model so that Agent = Model + Harness. Yet the precise definition of what a harness is always very blurry. Here is our definition, otherwise it remains words and impossible to build.

First, a harness is the result of a process, it is a group of objects. To fit an agent to a specific situation or environment, one can use services -e.g. the famous Forward Deployment Engineers- , agent frameworks, custom infrastructure, or any other tooling. The harness is the result of this work, it is the assembled set of objects that surrounds the model and allows it to operate effectively in a given environment.

A useful mental model is to think of the harness as the fitted version of an agent on a goal. The process of building an agent adapts it to a particular environment; the harness is the artifact produced by this adaptation.

To illustrate, in top AI labs you usually have two different teams slightly different: the FDEs that will build the harness for the customer, usually inside his codebase. Or you have some applied AI teams that will write down some architecture, and let the customer build his own harness. Two different processes but in the end you both have an object called harness, an agent fitted on a goal.

The agentic stack to run agents at scale

As the model capabilities continuously evolve, instead of taking agent = model + harness, let's start pragmatically from what's needed to run agents at scale.

From this schema, we see the harness can be characterized into two parts: extending the agent capabilities through infrastructure (websearch, MCPs, plugins etc) and improving the agent performance (i.e. the agent does what it is intended to do) by fitting the agent on the goal.

So in fact the harness is a group of some of those components. As your aim is to develop an agent, I believe the part that falls into a harness are those that fit the agent on an objective. I acknowledge that this definition means for example that what is presented as the codex harness is only part of it as it is then completed to fit with every new company that adopts codex. It is individual for a specific deployment.

OpenCode: a coding harness example

OpenCode provides a useful example of a coding harness because many of its components are explicitly exposed to users.

The harness starts with an agent system composed of Build, Plan, and specialized subagents. These agents can delegate work to one another, forming an orchestration layer that decomposes complex tasks into smaller ones.

OpenCode also includes runtime enforcement through its permission system. Different agents have different levels of access to tools and actions. The harness therefore defines not only what the agent can do, but also what it is allowed to do.

The capability layer is composed of tools such as file editing, shell commands, search, and MCP integrations. The context layer consists of prompts, instructions, and agent-specific configurations. Finally, dedicated compaction and summarization agents manage memory and long-running sessions.

Ramp's Inspect can be viewed as a business-specific implementation of a similar coding harness. In addition to source code and development tools, the harness is connected to systems such as Linear, Slack, Sentry, Datadog, LaunchDarkly, and Buildkite.

This illustrates a key property of harnesses: the model may stay the same, while the harness evolves to fit a specific environment.

This is also a way to let the configurations outside of prompts suited to a specific model, when switching models the whole configuration remains suited to the agent.

Case Study: long running research agent at Openai hackathon in SF (winners!)

The easiest way to understand a harness is to look at a concrete deployment.

During the OpenAI San Francisco Hackathon, we built a research agent iterating on research papers to produce new and relevant research ideas. The objective was simple: take a broad research question and let the agents run for hours to connect the dots between very large amount of research directions.

The underlying model was not the differentiator, it was the harness.

Starting from the model is not enough

A frontier model already knows how to search, reason, summarize, and write. Yet when deployed directly on a real research task, performance quickly plateaus.

The agent would:

• miss important sources,
• fail to explore alternative hypotheses,
• lose context during long investigations,
• produce inconsistent reports,
• struggle to verify information.

The challenge was therefore not adding more intelligence to the model but increasing the probability that the model would successfully complete the research objective.

Evals: the engine of iteration

The most important component was the evaluation system.

Every version of the research agent was tested against a set of research tasks with predefined success criteria.

The evals measured questions such as:

• Is the idea novel?
• Is it relevant? Based on number of citations of similar papers
• Were claims properly supported?
• Did the final report answer the original question?

The eval suite became the feedback mechanism guiding harness development. The evaluation being part of the harness: a page-rank inspired algorithm leveraging similar papers' citations.

Sandboxes: creating a safe execution environment

Research requires interaction with external systems: web searches, document parsing, data extraction, and code execution for analysis.

Rather than exposing those capabilities directly, the agent operated inside an isolated environment where it could:

• execute code,
• manipulate files,
• store intermediate results,
• process datasets,
• generate artifacts.

The sandbox extended the agent's capabilities while maintaining control over execution.

Without the sandbox, the model could reason about data. With the sandbox, it could actually work on data and spawn new agents as needed to explore the whole topic in parallel.

Hooks: controlling the workflow

One of the most useful harness components was the introduction of hooks to steer the agent behavior.

Hooks are interventions that occur at specific moments of the agent lifecycle.

Examples included:

• automatically saving intermediate findings,
• forcing source attribution before report generation,
• triggering additional searches when confidence was low,
• validating outputs before moving to the next stage.

Rather than relying on the model to remember every rule, hooks enforced behavior externally.

This is a recurring pattern in agent design: reliability often comes from moving requirements outside the model and into the harness.

For those long running agents it's also an option to say: is it worth investing compute to investigate the idea? Hooks allowed to take this step back by evaluating at each step the results produced.

The harness checklist

Those two examples of agents Opencode coding and Rippletide research can be taken as examples to generalize for someone willing to build other agents.

A harness serves two purposes: extending the agent's capabilities and improving its performance.

Capabilities

What expands what the agent is able to do.

• Tools, Run code, generate files, perform calculations
• MCP connections, Connect to MCP servers (GitHub, Linear, Figma, Stripe...)
• Plugins / connectors, Connect to plugins from Slack, Gmail, Notion, HubSpot, etc.
• Context, System prompt, RAG, documents, structured data
• Memory, Remember preferences and past interactions
• External systems, Call APIs and interact with business applications
• Sandboxes / execution environments, Execute code and workflows securely

Performance

What increases the probability the agent achieves its objective.

• Orchestration, Plan and coordinate multi-step workflows
• Skills, Specialized instructions for recurring tasks
• Hooks, Trigger actions before or after key events
• Evals, Benchmark datasets, golden sets, micro and macro eval
• Feedback loops, User ratings, corrections, reinforcement signals
• Human-in-the-loop, Approval steps, review queues, escalation
• Monitoring & observability, Logs, traces, metrics, dashboards
• Guardrails, Enforce safety rules
• Policies & permissions, Control access and authorized actions

The process: a harness gets build iteratively based on evals

A harness is not designed once; it is built through a continuous improvement loop. Start with a minimal harness, run it on a representative evaluation suite, measure where it fails, modify the harness to address those failure modes, and evaluate again.

Repeat this cycle until the agent consistently reaches the desired level of performance. Each failed eval points to a concrete improvement: adding a tool, introducing a hook, refining the orchestration, improving memory, tightening permissions, or enriching the context.

The evaluation suite therefore acts as the optimization function for the harness. Just as a model is trained by repeatedly optimizing its weights against a loss function, a harness is "trained" by repeatedly testing, measuring, and modifying its components until the agent reliably achieves its objective. The harness is the final artifact produced by this iterative loop.

Want to accelerate your harness development?

Rippletide provides the platform to optimize and improve agent harnesses. Request access to the Rippletide platform!