Current Harness Optimization Has Two Main Directions

The first is a unified global scaffold that tries to rely on a single set of prompts and control logic. But as business scenarios multiply, instructions optimized for financial spreadsheets tend to interfere with code generation tasks, causing severe rule conflicts and excessive context bloat.

The second is to copy a dedicated implementation for each specific domain. But different versions cannot share code, making maintenance a nightmare. And when a never-before-seen out-of-distribution (OOD) task appears, the specialized scripts tend to crash outright with no fallback.

In fact, software engineering solved the problems of reuse, specialization, and isolation perfectly over 40 years ago with object-oriented programming.

So why not apply this directly to the automatic evolution of Agent Harnesses? Google Cloud AI Research, together with a team from UIUC, has just published a paper on arXiv: Object-Oriented Harness: Evolving Agent Harnesses through Object-Oriented Design

They propose OO-Harness, which for the first time brings the inheritance, encapsulation, and polymorphism of object-oriented design into the self-evolution of agent scaffolds.

The design philosophy of OO-Harness is remarkably clean: model the Agent Harness directly as a hierarchy of executable Python classes.

First, a standard base class is defined, encapsulating the most general core execution logic, basic tool interfaces, and a fault-tolerance foundation, ensuring the system always has a solid performance floor.

The evolution agent uses Claude Opus 4.8 to deeply analyze historical failure logs, automatically identifying the pain points of specific business clusters, and autonomously writing new Python subclasses.

Subclasses inherit the general control logic from the base class and only override specific methods for targeted improvements.

During testing, a routing agent combines initial execution evidence — such as first-round error logs or environment state — to make precise decisions. If a known pain point is matched, the task is immediately dispatched to a specialized subclass harness. If an unfamiliar out-of-distribution task is detected, the system safely falls back to the Base Harness, completely eliminating the collateral damage caused by blind over-specialization.

In this research, they completely froze the underlying execution LLM, gemini-3.5-flash — not a single parameter was tuned. By relying solely on evolving the OOP code harness, they achieved a performance leap across three long-horizon, complex benchmarks. Covering finance, HR, marketing, sales, and other long-chain business workflows, the composite primary score jumped from 61.62% to 77.41%. The pass rate on difficult tasks rose from 25.44% to 37.22%, and at the same time, thanks to more streamlined and direct logic, the average number of execution steps actually decreased by 3.28.

Additionally, on highly complex cross-application tasks involving documents, slides, and spreadsheets, the composite score rose from 25.45% to 39.48%.

In multi-tool complex interactions, the score steadily advanced from 71.87% to 77.18%.

When facing previously unseen out-of-distribution tasks, traditional self-evolution methods saw their pass rate plunge to 44.90% because they forcibly applied over-fitted specialized rules to new tasks. In contrast, OO-Harness, leveraging its object-oriented safe fallback mechanism, automatically detected unfamiliar scenarios and reused the Base class, maintaining a performance level of 59.18%.

OO-Harness points an incredibly clear and elegant path for all of AI engineering. Treat the Agent as a stateful software engineering entity. Use object-oriented inheritance and encapsulation as the vehicle for AI’s automatic evolution and self-restructuring — this elegantly solves the problems of code reuse and generalization regression.

Highly recommended reading for anyone working on deploying Agents in production environments, toolchain governance, and long-horizon complex workflow architecture. The arXiv paper: https://arxiv.org/abs/2610.28380

Object-Oriented Harness: Evolving Agent Harnesses through Object-Oriented Design

Source: https://arxiv.org/html/2610.28380

Bhavana Dalvi Mishra — Google Cloud AI Research Yifei Ming — Google Cloud AI Research Yanfei Chen — Google Cloud AI Research Zhongying Cui — Google Cloud AI Research Lesly Miculicich — Google Cloud AI Research Long T. Le — Google Cloud AI Research Rui Meng — Google Cloud AI Research Chun-Liang Li — Google Cloud AI Research Hanghang Tong — University of Illinois Urbana-Champaign Chen-Yu Lee — Google Cloud AI Research Tomas Pfister — Google Cloud AI Research

Abstract

Agent harnesses are executable code that specifies the prompts, tools, and control flow around a language model. A single global harness can struggle with heterogeneous tasks that require different execution strategies. In this work, we introduce Object-Oriented Harness (OO-Harness), a harness optimization framework that evolves a hierarchy of executable harness classes using object-oriented design. During training, an evolution agent uses execution records to create a family of specialized harnesses, each implemented as a subclass of the base or an existing specialized harness via inheritance. At test time, a harness router uses routing lessons accumulated during training to select a specific harness for each task. Across three long-horizon benchmarks spanning business workflows, workspace tasks, and tool use, OO-Harness achieves the best performance among the compared methods, with an absolute improvement of up to 15.79% over the base harness. Extensive ablation studies examine the contributions of its core components.

^1 This work was done during Gaotang Li’s internship at Google Cloud AI Research.


1 Introduction

Generalizing to tasks beyond the training distribution is a central goal of language-agent research (Zeng et al., 2023; Xi et al., 2024). Recent benchmarks illustrate the breadth of tasks agents must handle: FutureX evaluates agents on forecasting real-world events using external information (Zeng et al., 2025), while APEX-Agents evaluates cross-application workflows in investment banking, management consulting, and corporate law (Vidgen et al., 2026). These workloads differ in the tool use, context management, and completion checks they require. An agent’s harness implements these choices as executable code around a language model (Yang et al., 2024).

Recent approaches automate agent design and harness optimization by refining executable code and other harness components using execution feedback (Hu et al., 2024; Zhang et al., 2025; Lou et al., 2026; Lee et al., 2026; Lin et al., 2026a; Karten et al., 2026; Nie et al., 2026; Jiang et al., 2026). Meta-Harness, for example, evolves candidate programs using discovery-set feedback and selects a global harness based on performance on that set (Lee et al., 2026). Such selection does not guarantee that the same changes remain beneficial under distribution shift. Even within a benchmark, Agentic Harness Engineering’s component ablations show that adding evolved memory improves performance on hard tasks but reduces it on easy ones (Lin et al., 2026a). EvoHarnessBench further shows that adding tools, skills, and specialist agents can degrade previously effective behavior (Ke et al., 2026). These findings motivate specialized harnesses that share common code while preserving different execution strategies, with a router selecting a harness for each task. Because harnesses are executable code (Ning et al., 2026), object-oriented design offers a natural way to express shared and specialized behavior.

We introduce Object-Oriented Harness (OO-Harness), a harness optimization framework that evolves a hierarchy of executable classes (Figure 1). Each specialized harness inherits from the base or an existing specialized harness, overriding inherited methods or adding new ones. During training, we first cluster discovery tasks by shared execution needs identified in base-harness execution records. An evolution agent iteratively selects a cluster and parent harness, creates a subclass, and evaluates it across the cluster’s tasks. This feedback guides subsequent revisions and accumulates as design and routing lessons. This offers two advantages. Efficiency: evaluating candidates on their target clusters avoids rerunning the entire discovery set. Generalization: specialized changes leave the base and other learned harnesses intact, so new tasks can use an appropriate harness without inheriting unrelated changes. At test time, polymorphism allows the executor to run a selected harness through a common execution interface. A harness router uses the task, an observable base trajectory, and routing lessons to select a specialized harness or retain the base result. The hierarchy and lessons are frozen before deployment; executor weights remain fixed in both phases.

Concurrent work also explores task-specific harness selection. Adaptive Auto-Harness routes tasks among specialized Git branches (Liu et al., 2026b). In OO-Harness, inheritance shares code across harnesses, and routing lessons learned during training guide selection alongside class descriptions and observable base trajectories.

We evaluate OO-Harness on AutomationBench, Workspace-Bench, and Toolathlon-GYM, where it achieves the highest primary score among the compared methods. Our contributions are:

• A harness representation combining shared code and specialized behavior through inheritance, method overrides, and new methods.
• An evolution framework that learns specialized harnesses and routing lessons from execution records to support task-specific selection.
• Strong empirical results across three long-horizon benchmarks, with extensive ablations validating individual components.

2 Related Work

Self-evolving agents.

Self-evolving agents use execution experience to improve prompts, memories, skills, and other persistent components. GEPA reflects on trajectories to optimize prompts (Agrawal et al., 2025), while ReasoningBank distills successful and failed experiences into reusable memories (Ouyang et al., 2026). A-Evolve considers deliberate updates to persistent agent state (Lin et al., 2026b), and HASP represents skills as executable functions that modify actions or supply corrective context (Liu et al., 2026a). These forms of adaptation provide building blocks for harness evolution. OO-Harness evolves specialized harnesses through inheritance and uses a harness router to select one for each task.

Automatic harness evolution.

Recent work automates harness construction and revision through code search and execution feedback, including Meta-Harness (Lee et al., 2026), Agentic Harness Engineering (Lin et al., 2026a), and HarnessEvolve (Jiang et al., 2026). These approaches primarily optimize a global harness across tasks, although changes that benefit one task group may not benefit another. HarnessDev benchmarks harness creation and evolution (Wu et al., 2026), while EvoHarnessBench shows that expanding tools, skills, and specialist agents can degrade previously effective behavior (Ke et al., 2026). Concurrent work explores adaptation across tasks and deployments: Adaptive Auto-Harness shares and specializes workspace contents through Git branching and rebasing (Liu et al., 2026b), while EvolveNet integrates adaptations from distributed deployments into a global harness (Nie et al., 2026). At the representation level, NOOA provides a programming model that expresses agents as native Python objects (Furgale et al., 2026). OO-Harness evolves a hierarchy of executable harness classes through inheritance, method overrides, and new methods. Its harness router selects a harness using routing lessons accumulated during training, class descriptions, the task, and an observable base trajectory.

3 Method

3.1 Problem setting and overview

A harness implements the prompts, tools, and execution rules around an executor, the language model M that carries out tasks (Ning et al., 2026). OO-Harness evolves this code on discovery tasks while keeping M fixed, then evaluates the frozen harnesses on disjoint held-out tasks (Figure 2). This differs from Meta-Harness’s TerminalBench-2 discovery experiment, which uses the same tasks for search and final evaluation (Lee et al., 2026). Separating discovery from evaluation is essential for assessing generalization beyond the search set (Wang et al., 2026).


A harness hierarchy T_H stores complete harness classes, starting from the base H₀. Each child inherits its parent’s methods and can override existing methods or add new ones. Task clusters C group discovery tasks with related execution needs. For cluster c, let D_c denote its discovery tasks and H_c the harness currently chosen for that cluster. Clusters organize task evidence; the hierarchy organizes reusable harness code. The evolution agent π constructs candidate subclasses from discovery-task evidence, while the harness router ρ selects the base or a specialized harness (Figure 3). §A.1, §A.4 describe model prompts/implementation details; Table 2 compares routing inputs. Execution records E store candidate code, discovery-task trajectories, outcomes, and reflections from successful and unsuccessful proposals. Where lesson stores are enabled, we summarize these records into design lessons L_π for code revision and routing lessons L_ρ for harness selection. Design lessons describe useful changes and failed approaches; routing lessons describe when a harness applies. Both accumulate during discovery and remain frozen at deployment. The router’s model weights stay fixed; training changes the evidence that guides its decisions.


3.2 Representing the harness hierarchy

Interfaces and inheritance.

Harness evolution operates on executable class definitions and supporting source files. The agent can change prompts, tools, context management, and execution control, and introduce additional methods. Where supported by the scaffold, it can also configure middleware, file backends, and subagents. The resulting class must remain compatible with the scaffold’s execution interface. A subclass reuses inherited methods and overrides or adds methods for a targeted change. Overrides can call parent methods through super(). Figure 1 illustrates the hierarchy; Listing 1 shows inheritance in a saved harness lineage.

Execution within one instance.

The harness router selects a complete class whose methods execute within one instance; ancestors are not separate agent runs. Methods can condition their behavior on runtime evidence, such as repeated tool errors or unfinished output artifacts.

3.3 Training initialization

We first run H₀ on discovery tasks D_tr and retain trajectories and evaluation feedback. We group tasks whose base executions suggest that they may benefit from a shared harness change, yielding clusters C and task sets D_c. Each cluster records its shared execution needs and starts with H_c = H₀; the initial hierarchy is T_H = {H₀}.

3.4 Training iteration

At each iteration, the evolution agent works in a code workspace with filesystem access to harness source, task clusters, and execution records. It can inspect files, delegate analysis to subagents, and write or edit candidate code. It selects a target cluster and parent