Papers to Code: How Agent Harnesses Improve Without

By Lazar Milicevic · Published October 22, 2026 · 9 min read

Your agent works about 70% of the time, the failures are annoying and inconsistent, and you can't fine-tune the model because it's either a closed API or your budget says no. A recent paper from UCSB researchers (with Microsoft, according to VentureBeat) shows a different lever: stop touching the model and systematically upgrade the code around it, using ideas pulled straight from published research.

This post breaks down what that work did, what the numbers actually show, what transfers to a small-business agent, and what doesn't.

What a "harness" is, and why it's where the leverage is

A harness is everything around the model: the system prompt, how context is assembled and trimmed, the tool definitions, retry and error-handling logic, output formatting, memory, and the workflow that decides what runs next. The model produces tokens. The harness decides which tokens it sees, what it's allowed to do with them, and what happens when something breaks.

If you've shipped an agent, you already know this is where most real-world failures live. The model rarely "forgets how to reason." More often, a tool call returned an unexpected shape, an exception wasn't surfaced in a useful way, the context window filled with junk from three steps ago, or the final answer was submitted in a format the downstream system rejects.

That's why harness optimization is an appealing target. You can change it without weights, without GPUs, and without waiting for a model vendor. You can also version it, diff it, and roll it back like any other code.

The research field has been moving fast here. According to VentureBeat's coverage, existing optimizers fall into two groups: component-specific tools (Google's WikiSkill, Microsoft's SkillOpt, Memento-Skills) that refine one part of the stack like a skill library or memory store, and full-harness optimizers. A related effort from Salesforce, DarwinX, evolves the prompts, tools, and skills around a frozen model and reportedly took an agent from 43.5% to 93% on browser tasks without retraining (VentureBeat). Google Research has also open-sourced Harness², another framework for improving the systems around a model without changing its weights.

What ScholarEvolve does differently

Most self-evolving harness optimizers draw on two sources: whatever knowledge is already baked into the underlying model, and the trajectories the agent has explored so far. Both are closed loops. The optimizer can only invent improvements it can already imagine, or reinforce patterns it has already tried.

ScholarEvolve adds a third source: the published literature. Per VentureBeat, it automatically extracts new information from research papers and translates it into code upgrades for an agent's harness. The paper is Learning from Research: Toward Lifelong Agent Harness Evolution (arXiv 2609.40169, by Jingbo Yang, Kwei-Herng Lai, Xiaowen Wang, Yaar Harari, Evgeniy Gabrilovich and Shiyu Chang; abstract).

According to the paper's description, the framework:

1. Organizes harness improvement directions into functional modules (think: planning, memory, error recovery, tool use).
2. Uses topic modeling over papers to find distinct improvement strategies within each module.
3. Implements those strategies as code changes.
4. Evaluates combinations of them, since improvements interact.
5. Is designed to incorporate new publications over time, hence "lifelong."

In the paper's setup, both ScholarEvolve and the Meta-Harness baseline use GPT-5.4 through Codex as the code-writing engine and receive the same search rollout budget per setting. Results are means over three independent evaluation runs. That matters: it's a controlled comparison of where the ideas come from, not of who spent more compute.

The code is public on GitHub (UCSB-NLP-Chang/ScholarEvolve), so you can read exactly how the module decomposition and paper-to-patch step work instead of trusting a summary.

The numbers, split by benchmark

The two benchmarks were AppWorld (agents write code and call APIs across multiple apps) and τ-Bench Telecom (agents handle customer-service, mobile data, and messaging troubleshooting with a simulated user). The researchers evolved harnesses for two models: open-weight Qwen3.5-27B and GPT-5.4-mini.

These figures come from different splits and metrics, so they're laid out separately rather than blended:

Some detail worth pulling out:

• On AppWorld Normal, the gain was +12.4 points in task goal completion (TGC) and +20.2 points in scenario goal completion (SGC). SGC is the stricter metric: the agent has to succeed across three variations of the same scenario. A 20-point jump there suggests the improvement isn't just luck on one phrasing.
• On the Challenge split, the evolved harness beat Stanford's Meta-Harness by 9.0 points on applications (Amazon and Gmail APIs) that never appeared in the evolution or validation sets. Generalizing to unseen apps is the part that makes the result interesting rather than overfit.
• VentureBeat reports that the Normal-split gain closed roughly 74% of the gap between Qwen3.5-27B and GPT-5.4. That figure comes from VentureBeat only; I haven't seen it confirmed in the paper text, so treat it as a journalist's framing.

The error-recovery row is the most instructive for practitioners. Recovery after a failed intermediate step is a classic harness problem, and a 15-point lift there is the kind of thing you can feel in production.

Reading the results without over-reading them

A few cautions, because a pillar post that only cheers would be doing you a disservice.

Benchmarks are not your business. AppWorld and τ²-Bench Telecom are structured, simulated environments with scoreable outcomes. I found nothing showing the same magnitude of gain for a small business's invoicing, inbox triage, or CRM workflows. Don't plan around "+12 points" as a promise.

"Smarter" is not proven. One third-party review (a blog, not the paper's authors) argues that much of the failure reduction on the hard split came from answers being submitted in the wrong form, with such failures dropping from 407 to 177. I can't verify that reading. But it points at something plausible and useful: a lot of harness gains come from boring fixes like output format validation, not from clever reasoning scaffolds. That's good news if you're building your own, because boring fixes are cheap.

Costs are unknown. I found no published figure for the compute or wall-clock cost of running ScholarEvolve's evolution loop. The search uses a strong code-writing model (GPT-5.4 via Codex in the paper's setup) and many rollouts. Before you consider running anything like it, budget a small pilot and measure. Don't borrow cost-savings numbers from other papers; one figure circulating about reduced inference spend belongs to a different paper entirely.

The attribution caveat. VentureBeat and social posts say UCSB and Microsoft; the arXiv abstract page I reviewed lists author names without affiliations. I'm attributing the Microsoft link to VentureBeat.

The part you can steal today: a lightweight version of the loop

You probably won't run the full ScholarEvolve pipeline. But the underlying pattern is portable at small scale: treat your harness as code with a test suite, and source improvement ideas from outside your own head.

Step 1: Build a replayable eval set from your own failures

Before any evolution, you need a score. Log every agent run (inputs, tool calls, outputs, final result) and tag failures. Aim for a fixed set of real tasks you can replay.

# eval_set.py - replay logged tasks against a harness version
import json
from pathlib import Path

def load_cases(path="evals/cases.jsonl"):
    return [json.loads(l) for l in Path(path).read_text().splitlines()]

def run_eval(harness, cases):
    results = []
    for case in cases:
        out = harness.run(case["input"])
        results.append({
            "id": case["id"],
            "passed": case["check"](out),   # your own pass/fail function
            "tool_errors": out.get("tool_errors", 0),
        })
    passed = sum(r["passed"] for r in results)
    return {"pass_rate": passed / len(results), "details": results}

Run each case more than once if your agent is non-deterministic. The paper reports means over three independent runs for exactly this reason.

Step 2: Cluster your failures by harness module

Map each failure to a module, the same decomposition idea the paper uses:

modules:
  planning:      # wrong step order, skipped steps
  context:       # stale/irrelevant info crowding the window
  tool_use:      # bad arguments, wrong tool choice
  error_recovery:# fails after one exception instead of retrying
  output_format: # right answer, wrong shape

Count failures per module. If output_format and error_recovery dominate, you've just found your cheapest wins, which lines up with the error-recovery gain in the table above.

Step 3: Mine papers for one module at a time

Pick the worst module and search for literature on it (agent error recovery, context compression, tool-use verification). Read abstracts, extract a concrete mechanism, and write it as a small patch, not a rewrite. Examples of paper-shaped patches:

• After any tool exception, inject the traceback and a one-line "what changed" summary instead of letting the model guess.
• Validate the final answer against a schema before submission; on mismatch, re-prompt with the schema error.
• Truncate old tool outputs to a short summary once they're two steps behind.

Step 4: Evaluate patches in combination, not just alone

ScholarEvolve explicitly evaluates combinations of strategies because improvements interact: a context-trimming patch can undo an error-recovery patch that relied on the old context. Test each patch alone against your eval set, then test the winners together.

# compare harness variants on the same replayed cases
python run_eval.py --harness base            --runs 3
python run_eval.py --harness +schema_check   --runs 3
python run_eval.py --harness +retry_summary  --runs 3
python run_eval.py --harness +schema_check+retry_summary --runs 3

Keep a results table. If a combination loses to its parts, you've learned something about interaction effects rather than discovering it in production.

Step 5: Guard against overfitting to your eval set

The Challenge-split result is persuasive because it held up on apps absent from evolution and validation. Copy that discipline: hold out a slice of cases that you never use when choosing patches, and only check it at the end. If gains on the held-out slice are far smaller than on the tuning slice, you've been fitting noise.

When this approach is the wrong tool

Harness evolution is not always the right move.

• You have no logs or evals. Without a score, you're guessing. Build the replay set first; it's valuable on its own.
• Your failures are knowledge gaps. If the model lacks domain facts, better retrieval or a stronger model may matter more than a smarter harness.
• Your task is deterministic. If a Python script solves it, don't wrap it in an agent and then optimize the wrapper. Fix the architecture first.
• Your volume is tiny. If the agent runs a few dozen times a month, manual review and a hand-edited prompt will beat any search loop.

How BizFlowAI approaches this

The prompt, context, and workflow tuning described above is the work I do on production agents for small teams: instrument the agent, build a replayable failure set, sort failures by harness module, and make targeted, testable changes to prompts, context handling, error recovery, and workflow logic, with the base model left untouched. The ScholarEvolve result is a research-grade version of the same instinct: the harness is where a lot of the leverage lives, and it can be improved systematically instead of by vibes.

If you have an agent in production (or about to be) and want it audited and tuned against your own data, that's a good fit for a discovery call. I'll tell you plainly whether harness changes are likely to help your case or whether the problem lives somewhere else.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Request a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.