Improving Enterprise Agent Performance with Evolving Harnesses
Listen to the summary
Uses a voice available on your device
Audio options
On this page 5 sections
Related concepts 5 concepts
Key Takeaways
- StarHarness improved benchmark performance by 20 to 35 percentage points over default harness configurations.
- The method achieved significant inference cost reductions of 17 percent on ITBench, 53 percent on EnterpriseOps-Gym, and 29 percent on AutomationBench.
- Performance improvements were driven by 4 to 12 accepted harness edits per environment that refined interfaces and encoded operational knowledge.
- The system remains effective across different models, including GPT-5.4 and Qwen3.6.
Summary & Methodology Analysis
StarHarness implements an outer-loop evolution process that updates the harness (the environment interface and execution policy) rather than fine-tuning the underlying model weights. The system uses a coding harness to host a proposer agent that generates candidate patches (deltas). These patches undergo a validation pipeline that checks for scope and imports, followed by a test flip verification to ensure the change improves a specific task. Successful candidates are integrated into the harness if they improve the mean score on a held-out selection set of tasks. This iterative approach relies on GPT-5.4 as both the agent under test and the proposer to refine the interaction logic between the model and the environment.
Evaluation involved three enterprise benchmarks: ITBench SRE (40 Kubernetes root-cause analysis scenarios), EnterpriseOps-Gym ITSM (103 tasks against a ServiceNow backend), and AutomationBench Finance (100 finance workflow tasks across 47 simulated SaaS applications). The resulting evolved harnesses demonstrated improved performance, ranging from 20 to 35 percentage points, while simultaneously reducing GPT-5.4 inference costs per task by 17 percent on ITBench, 53 percent on EnterpriseOps-Gym, and 29 percent on AutomationBench. These gains were achieved after 4 to 12 accepted changes, which typically repaired interfaces, exposed conventions, or compressed search space over evidence.
While the performance improvements are measurable, the study faces limitations regarding causal analysis. The authors cannot isolate the specific contribution of individual patches because the changes are combined during the evolutionary process. Furthermore, the system comparison is descriptive rather than a controlled experiment. Because the systems differ simultaneously across prompts, tools, execution policies, and harness architecture, the research cannot isolate a single causal component responsible for the performance gains.
Interactive System Flowchart
Illustrative Implementation
A short sketch of the paper's core idea, not the authors' own code.
# Illustrative sketch (not from the paper)
import torch
# 1. Load benchmark tasks and stratify them
tasks = load_tasks() # placeholder
strata = stratify(tasks, by=["failure_mode", "score", "verifier_pass"])
# 2. Split into visible, hidden, and held‑out sets
visible = strata["proposer_visible"]
hidden = strata["proposer_hidden"]
held_out = strata["evaluation"]
# 3. Outer‑loop evolution
harness = load_default_harness()
for generation in range(MAX_GENERATIONS):
# Proposer (GPT‑5.4) suggests a code delta for the harness
patch = proposer_generate_delta(harness, visible)
# 4. Validator checks scope, imports, and a smoke test on one task
if not validator_check(patch, visible[0]):
continue # reject invalid patch
# 5. Apply patch temporarily and test on hidden selection
new_harness = apply_patch(harness, patch)
hidden_score = evaluate(new_harness, hidden)
base_score = evaluate(harness, hidden)
# 6. Commit if mean selection score improves
if hidden_score.mean() > base_score.mean():
harness = new_harness # commit
log_success(patch, hidden_score.mean())
else:
log_failure(patch)
# 7. Final evaluation on held‑out tasks (no further evolution)
final_score = evaluate(harness, held_out)
print("Final held‑out score:", final_score.mean())
// Illustrative sketch (not from the paper)
const torch = require('torch-js'); // placeholder for any tensor ops
// 1. Load and stratify benchmark tasks
const tasks = loadTasks(); // placeholder
const strata = stratify(tasks, ['failure_mode', 'score', 'verifier_pass']);
// 2. Partition task pool
const visible = strata.proposer_visible;
const hidden = strata.proposer_hidden;
const heldOut = strata.evaluation;
// 3. Outer‑loop evolution
let harness = loadDefaultHarness();
for (let gen = 0; gen < MAX_GENERATIONS; gen++) {
// Proposer (GPT‑5.4) creates a delta patch
const patch = proposerGenerateDelta(harness, visible);
// 4. Validator runs scope/import checks and a smoke test on one task
if (!validatorCheck(patch, visible[0])) continue; // reject
// 5. Apply patch temporarily and evaluate on hidden selection
const newHarness = applyPatch(harness, patch);
const hiddenScore = evaluate(newHarness, hidden);
const baseScore = evaluate(harness, hidden);
// 6. Commit if mean score improves
if (mean(hiddenScore) > mean(baseScore)) {
harness = newHarness; // commit
logSuccess(patch, mean(hiddenScore));
} else {
logFailure(patch);
}
}
// 7. Final held‑out evaluation (no further evolution)
const finalScore = evaluate(harness, heldOut);
console.log('Final held‑out score:', mean(finalScore));
Cross-Examination & FAQs
A deeper dive clarifying mechanics, constraints, and baseline evaluations.
Q1. What is StarHarness?
StarHarness is a system that evolves environment-specific harnesses to improve the performance and cost efficiency of AI agents in enterprise environments.
Q2. Does this require training the model weights?
No, StarHarness evolves the harness while keeping the model weights fixed.
Q3. What kind of results can I expect?
The system improved benchmark performance by 20 to 35 percentage points and reduced inference costs by up to 53 percent depending on the benchmark.
Q4. Which models were tested with this system?
The authors used GPT-5.4 for evolution and evaluated the resulting harnesses on GPT models and Qwen3.6.
Q5. What tasks are used to validate the harnesses?
The harnesses are validated against ITBench SRE, EnterpriseOps-Gym ITSM, and AutomationBench Finance.
Q6. How many edits are typically needed to evolve a harness?
The improvements were achieved after 4 to 12 accepted changes per environment.
Q7. Can the authors pinpoint which specific patch improved performance?
No, the authors stated they cannot isolate the causal contribution of individual patches due to the nature of the combined changes.
Q8. Is this a controlled study that isolates variables?
No, the study is descriptive because the systems differ in multiple ways, such as prompts, tools, and execution policies, preventing the isolation of a single causal component.
Q9. What does the harness evolution actually change?
Accepted edits repair interfaces, expose environment conventions, encode operational knowledge, and compress search over available evidence.