Object-Oriented Harness (OO-Harness)

• Object-Oriented Harness (OO-Harness) is a framework that optimizes heterogeneous long-horizon workloads by evolving a hierarchy of executable harness classes around a fixed language- model executor, using specialized harnesses for different tasks to enhance performance and efficiency.
• OO-Harness employs an inheritance mechanism to ensure incremental specialization of harness functionality, thereby enabling targeted modifications without affecting the base harness or unrelated specialists, enhancing code reuse and non-interference.
• The specialization and hierarchy in OO-Harness lead to improved task performance, evidenced by the OO variant achieving a 40.56% micro-rubric pass rate in Workspace-Bench, marking a 4.96 percentage point improvement over flat variants in the test benchmarks.

Object-Oriented Harness (OO-Harness) is a harness-optimization framework that evolves a hierarchy of executable harness classes around a fixed language-model executor. During training, an evolution agent uses execution records to create specialized harnesses as subclasses of a base or existing specialized harness through inheritance. At inference time, a harness router selects a suitable class for each task using task information, observable execution trajectories, and routing lessons accumulated during training. The framework targets heterogeneous long-horizon workloads in which a single global harness can be suboptimal because tasks require different prompts, tools, context-management policies, recovery procedures, verification checks, and execution budgets (Li et al., 20 Oct 2026).

1. Concept and scope

An agent harness is executable code surrounding an executor model. Its responsibilities include prompt construction, tool exposure, control flow, context management, error handling, completion verification, output validation, middleware, file backends, subagents, and persistent context management. The executor model remains fixed; OO-Harness modifies the program that determines how the model interacts with tasks and environments.

The framework distinguishes three organizational strategies:

1. One global harness: every task uses the same implementation.
2. Independent specialized harnesses: a router selects among separately implemented harnesses.
3. OO-Harness: a router selects among specialized harnesses organized in an inheritance hierarchy.

The third strategy combines specialization, code reuse, non-interference, and targeted search. A specialization can modify behavior for one task cluster while leaving the base harness and unrelated specialists available. This differs from global harness optimization, in which a change intended to improve one task family may regress another.

The harness is represented conceptually as:

$$H=(\text{prompts},\text{tools},\text{control flow},\text{supporting components}).$$

Prompts include system instructions, task instructions, corrective guidance, and context-injection rules. Tools include functions, APIs, file systems, middleware, subagents, and application interfaces. Control flow governs model invocation, tool-call processing, error recovery, context compression, continuation, stopping, reminders, and completion verification.

OO-Harness does not retrain the executor model or modify its weights. Its optimization target is the executable program around the model. This places it within a broader line of research treating harnesses as first-class execution substrates rather than as static prompt wrappers. Harness-Bench similarly defines capability at the model–harness configuration level and reports substantial variation across harness configurations under common task, budget, and evaluator conditions (Yao et al., 27 May 2026).

2. Hierarchical harness representation

OO-Harness initializes a hierarchy with a base harness $H_0$:

$\mathcal{T}_H=\{H_0\}.$

A specialized harness is a subclass of the base or of an already specialized harness. If $H_j$ is the parent of $H_k$, then $H_k$ inherits the parent’s methods and may override existing methods, call parent implementations with super(), add methods, or alter prompts, tools, context handling, middleware, file backends, and subagent behavior.

The hierarchy may therefore be represented as:

$H_j$1

The ancestors are not executed as separate agent runs. The router selects one complete class, and one instance of that class executes the task. Inherited methods contribute to the selected instance’s behavior.

Inheritance provides incremental specialization:

$$H_{\text{child}}=H_{\text{parent}}+\text{targeted override or addition}.$$

A child can preserve a parent’s behavior and modify only a particular seam. For example, one subclass may extend context management, while a descendant retains that extension and adds a completion check. The parent remains available for tasks that require its mechanism but not the descendant’s additional intervention.

A representative pattern is:

$H_j$2

The framework’s inheritance mechanism is intended to avoid repeated copying of previously discovered behavior. The paper’s inheritance ablation compares candidates that restart from the base, candidates that copy accepted mechanisms into flat specialists, and candidates that inherit from the currently deployed harness for a cluster. On Workspace-Bench, the OO variant achieves a micro-rubric pass rate of 40.56%, and exceeds the flat variant by 4.96 percentage points (Li et al., 20 Oct 2026).

Inheritance does not imply global monotonicity. A child accepted for a target cluster may be harmful outside that cluster:

$S_c(H')>S_c(H_c)$

does not imply that $H'$ is globally superior. This non-monotonicity makes routing a central part of the architecture.

3. Evolutionary discovery and specialization

OO-Harness separates discovery from deployment. Harnesses evolve only on discovery tasks, after which the final hierarchy and routing information are frozen before held-out evaluation.

The evolution pipeline begins by running the base harness on discovery tasks and recording trajectories, tool calls, errors, outputs, evaluation feedback, and reflections. Tasks are then grouped into clusters according to shared execution needs. Clusters need not correspond to manually defined domains; they may instead express recurring failure modes, output formats, tool-use problems, completion issues, or common requirements for prompts, backends, or context interventions.

Let:

$\mathcal{C}=\{c_1,c_2,\ldots,c_m\}$

denote the clusters, with $H_0$0 representing the discovery tasks assigned to cluster $H_0$1. Initially, every cluster uses $H_0$2:

$H_0$3

The evolution agent has access to harness source code, the current hierarchy, cluster definitions, discovery trajectories, task outcomes, evaluator feedback, earlier accepted and rejected proposals, and design lessons. It selects a target cluster, a parent class, and a shared mechanism or failure to address. It then generates a candidate subclass.

The candidate is evaluated only on the target cluster. If $H_0$4 is the candidate score and $H_0$5 is the score of the harness currently assigned to that cluster, acceptance requires:

$H_0$6

Benchmark-specific acceptance checks may incorporate task-level outcomes and execution feedback. When accepted, the subclass is inserted into the hierarchy, may become the active harness for the target cluster, and may serve as a parent for later descendants. Rejected candidates remain available for later analysis but do not become active harnesses.

The evolution process stores two categories of lessons:

• Design lessons guide subsequent harness modifications.
• Routing lessons guide deployment-time selection.

Repeated unsuccessful proposals can lower a cluster’s search priority. Clusters may also be reassigned, split, merged, or reconsidered when successive revisions fail.

The method is execution-feedback-driven program search rather than gradient-based optimization. Its search space includes prompts, tools, context management, execution control, middleware, file backends, subagent configurations, completion checks, error recovery, output validation, and helper methods.

The specialization examples include:

• Missing-write completion: a descendant detects that a task requiring a write has reached completion without a successful mutating API call and requests another agent turn.
• Tool-error recovery: descendants add guidance for unrecoverable tool errors and repeated unproductive tool results.
• Document generation: a specialist renders text intended for a .docx output as a binary Word document and falls back to the parent backend if rendering fails.
• Spreadsheet verification: a specialist checks saved workbooks for percentage-labelled cells containing values such as $H_0$7 where percentage points are expected.

These examples illustrate that specialization can target execution mechanisms rather than semantic task domains.

4. Routing and deployment

At deployment, the router selects either the base harness or a specialized class:

$H_0$8

where $H_0$9 is the task, $\mathcal{T}_H=\{H_0\}.$0 is the observable base trajectory or trajectory summary, $\mathcal{T}_H=\{H_0\}.$1 is the frozen routing-lesson store, and $\mathcal{T}_H=\{H_0\}.$2 is the selected harness.

The router may use:

1. the task description and metadata;
2. class descriptions and applicability conditions;
3. routing lessons;
4. the observable base trajectory.

It cannot use held-out grader feedback, hidden answers, or final evaluation scores. Observable trajectory evidence may include tool calls and results, errors, write counts, event types, assistant-turn counts, tool-call counts, output-file extensions, file-dependency counts, and application or tool families.

Routing lessons encode associations such as:

$\mathcal{T}_H=\{H_0\}.$3

Examples include:

$\mathcal{T}_H=\{H_0\}.$4

and:

$\mathcal{T}_H=\{H_0\}.$5

The router is explicitly allowed to retain the base when no specialized mechanism clearly applies or when specialization could be harmful. This is particularly important under distribution shift. In an out-of-distribution Toolathlon construction involving disjoint application families, the router selected Base for every test task, preserving base performance while a globally evolved harness reduced PASS.

In one AutomationBench run, 134 of 300 tasks, or 44.7%, reused Base, while 166 selected specialists. The tasks routed to specialists had weaker original base performance:

Routing destination	Tasks	Original Base mean reward	Original Base strict PASS
Reuse Base	134	77.15%	36.57%
Specialized harness	166	44.40%	14.25%

This pattern is consistent with a router that uses execution evidence to apply specialization when the base trajectory appears problematic, while preserving already-successful base executions.

The router’s confidence threshold in the task-only routing ablation is $\mathcal{T}_H=\{H_0\}.$6. This confidence is not a calibrated probability and is not based on grader feedback. Adding the observable base trajectory substantially improves routing on some benchmarks, particularly AutomationBench and Toolathlon-GYM, where many relevant failures become visible only during execution.

5. Execution model and benchmark evaluation

OO-Harness was evaluated on three long-horizon benchmarks:

Benchmark	Domain	Discovery tasks	Held-out tasks	Primary metric
AutomationBench	Business workflows in simulated applications	300	300	Mean partial credit
Workspace-Bench Lite-100	Files and cross-application workspace tasks	288	100	Micro-averaged rubric pass
Toolathlon-GYM	Long-horizon multi-tool and application tasks	251	252	Strict PASS

AutomationBench uses API search and request tools in simulated applications, with deterministic assertions producing partial-credit rewards and strict completion verdicts. Workspace-Bench includes documents, spreadsheets, presentations, code artifacts, and file dependencies, using a local shell and filesystem backend with agent-as-judge evaluation. Toolathlon-GYM combines tools and application services exposed through configured MCP servers.

All methods use Gemini 3.5 Flash as the executor and Claude Opus 4.8 as the evolution model, with up to 40 evolution iterations. OO-Harness uses Claude Sonnet 5 for routing in the main comparison. Harnesses are frozen during held-out evaluation.

The compared methods are Base, parallel best-of-$\mathcal{T}_H=\{H_0\}.$7, sequential self-refinement, Meta-Harness, AHE, AAH, and OO-Harness.

Method	Automation Mean	Automation PASS	Automation Steps	Workspace Mean	Workspace PASS	Workspace Steps	Toolathlon Mean	Toolathlon PASS	Toolathlon Steps
Base	61.62	25.44	31.27	25.45	3.67	34.41	71.87	31.15	40.50
Parallel $\mathcal{T}_H=\{H_0\}.$8	61.46	24.67	31.64	32.54	5.67	41.62	74.85	31.55	39.94
Parallel $\mathcal{T}_H=\{H_0\}.$9	60.24	24.00	31.29	37.71	7.67	48.63	75.69	32.14	38.90
Sequential $H_j$0	59.29	25.00	31.86	27.93	3.33	32.91	73.53	33.33	40.97
Meta-Harness	63.92	26.33	30.05	29.56	5.54	35.23	75.84	33.45	39.85
AHE	64.18	28.11	30.61	38.43	7.78	34.59	74.48	36.23	41.02
AAH	75.40	34.31	28.89	38.62	8.00	33.58	74.99	34.32	41.23
OO-Harness	77.41	37.22	27.99	39.48	8.33	32.78	77.18	37.45	37.25

Using the primary metric, OO-Harness improves over Base by:

• 15.79 percentage points on AutomationBench Mean;
• 14.03 percentage points on Workspace-Bench Mean;
• 6.30 percentage points on Toolathlon-GYM PASS.

OO-Harness achieves the best primary score and strict PASS on all three benchmarks. It also has the lowest reported trajectory length on all three benchmarks.

The routing ablation compares Base, task-only routing, and routing using both task information and the observable base trajectory:

Benchmark / primary metric	Base	Task-only routing	Task + trajectory routing
AutomationBench Mean	61.30	64.88	77.52
Workspace-Bench Mean	24.57	40.03	40.56
Toolathlon-GYM PASS	31.35	33.33	37.70

Trajectory evidence improves task-only routing by 12.64 points on AutomationBench, 4.37 points on Toolathlon-GYM, and 0.53 points on Workspace-Bench. The difference across benchmarks is consistent with the relative importance of hidden execution failures versus task metadata such as requested output type.

6. Significance, limitations, and relation to broader harness research

OO-Harness treats harness optimization as conditional program optimization. The system learns both executable behaviors and the conditions under which those behaviors should be applied:

1. Behavior discovery: the evolution agent constructs specialized subclasses from execution evidence.
2. Implementation sharing: inheritance reuses methods, prompts, tools, and checks.
3. Conditional deployment: routing lessons determine whether a specialist or Base should execute.

This differs from a single global harness optimized across all tasks. Harness-Bench’s results similarly indicate that performance should be attributed to model–harness configurations rather than to the base model alone, reporting a configurable-harness gap of 23.8 percentage points between the best and worst evaluated configurations (Yao et al., 27 May 2026). Other work extends harness design in complementary directions: typed Python objects and agentic methods in NVIDIA Object-Oriented Agents (Furgale et al., 22 Jul 2026), lifecycle-attached capability composition and runtime adaptivity in openJiuwen (Team et al., 28 Aug 2026), and multi-objective inheritance-free component evolution in Harmony Harness (Yu et al., 10 Oct 2026).

The direct contributions of OO-Harness are the hierarchical organization of executable harnesses, inheritance-based specialization, cluster-local candidate evaluation, routing based on execution evidence, and preservation of Base as an explicit fallback. The reported results support specialization over a single global harness on the evaluated heterogeneous long-horizon workloads.

Several limitations remain. Harness evolution depends on informative execution records, benchmark APIs, tool schemas, and execution environments. Service outages, API rate limits, private or authenticated services, and interface changes can reduce reliability. The evolution process incurs costs from discovery execution, candidate evaluation, trajectory analysis, lesson distillation, judging, and deployment-time routing; the paper does not provide a complete dollar, token, or API-call accounting.

The hierarchy may become difficult to manage as the number of classes and routing lessons increases. Overlapping applicability conditions, contradictory inherited interventions, long inheritance chains, and larger routing contexts may complicate selection and debugging. A child’s local improvement does not guarantee global improvement, and routing errors can select an inapplicable specialist or fail to select a useful one.

The framework also does not establish a formal guarantee of out-of-distribution robustness. Its OOD construction demonstrates that retaining Base can avoid degradation when specialized harnesses do not transfer, but the router itself may misclassify novel tasks. The paper does not specify a universal score function across benchmarks, a formal routing-complexity bound, or a large-scale hierarchy stress test.

OO-Harness can therefore be characterized as a hierarchical, execution-feedback-driven architecture for specialized agent harnesses. Its defining abstraction is not merely an object-oriented wrapper around an LLM, but a population of executable classes linked by inheritance and selected through evidence-based routing. The base harness supplies reusable behavior, subclasses encode targeted interventions, and the router determines when specialization is justified. This separation enables local optimization without requiring every harness change to be globally beneficial.