Skip to content

Build1 publisher3 min readPublished

ByteDance's self-evolved agent harnesses gain 3.11 held-out points inside a 4.75-point noise band

ByteDance's Seed team and collaborators had 18 models write their own agent scaffolding and then rewrite it from task feedback. The held-out gains they report land inside the fluctuation band of their own evaluation.

The Engineer · Build desk

Illustration accompanying ByteDance's self-evolved agent harnesses gain 3.11 held-out points inside a 4.75-point noise band

What happened

  • ByteDance's Seed team, with Singapore University of Technology and Design, Georgia Tech and other institutions, released HarnessDev, which has LLMs write their own agent harnesses and then revise them from task feedback.
  • Eighteen code harnesses were produced, adding 17,111 lines of code in total, with Gemini reported as the smallest at 1,006 lines and the highest scorer on Terminal-Bench 2.1 at 68.8.
  • In self-evaluation, Opus's harness reported success in 99 of 100 runs when only 48 were correct, and a Completion Check mechanism was added in response.
  • Swapping executors moved scores hard in both directions: Opus's SWE-Pro harness went from 69.3 to 33.0 under Gemini, while the Qwen harness gained 17.6 points on BrowseComp with Gemini.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • constraint A harness evolved against one executor is an asset tied to that model, so a model swap does not carry the tuning with it and the loop has to be run again.
  • decision Because the held-out gains sit inside the evaluation's own fluctuation, a team cannot justify the evolution phase on score, and has to justify it on removed dead code or reduced tokens instead.
  • cost With a 19x spread in token overhead across harnesses on MLE-bench, the choice of harness is a line on an inference bill, paid by whoever runs the agent rather than whoever generated it.
  • exposure Anything downstream that trusts a harness's own completion signal inherits a false-pass rate near half, and the fix reported here is more generated code inside the same harness.

Held-out improvement across five evolution trajectories averaged 3.11 points [14]. The same write-up puts evaluation fluctuation at roughly plus or minus 4.75 points [16]. So the measured gain is about two thirds of the noise band [25]. At that resolution, a version that scores better on the visible feedback set is not evidence of a better harness.

The line counts do not reconcile either. Eighteen code harnesses added 17,111 lines, an average of 950.6 lines each [4][23]. Gemini is reported as the smallest edit at 1,006 lines, 55 lines above that mean [5][24]. Two readings survive: the 17,111 covers construction while the 1,006 counts changes made during evolution, or one of the figures is wrong. The dev.to write-up, published September 10, 2026, does not separate the phases [21].

Construction is the part that reliably worked. All 18 harnesses implemented an execution loop, and Tools, Lifecycle and Verification had high completion rates [6]. What the model starts from is a class with a while loop and three empty methods, plan_action, call_tool and is_complete [19]. Everything above that is generated across six capability areas: execution, tools, context, state, lifecycle and verification [20].

Generated code is not exercised code. Of 108 component instances in the code harnesses, 72 were observed running in real tasks [7], leaving 36 that were not, one instance in three [22]. Eighteen components never appeared in execution at all, and every one of them came from State and Memory [8]. Some harnesses implemented checkpoint logic, and across 26,679 recorded task trajectories there were zero checkpoint events [9]. Twenty-six thousand runs is a large sample in which to never checkpoint once.

In the Data tasks, 441 of 2,325 executions produced degraded commits the harness did not detect, about 19 percent [11][28]. The reported response was a Completion Check added to the harness [10].

The executor substitution costs 36.3 points, more than half the self-evaluated score [12][26]. Direction is not predictable: the Qwen harness went the other way on BrowseComp under a Gemini executor [13]. For the 68.8 on Terminal-Bench 2.1 to say anything about your stack, you would need the executor that grew the harness, its tool surface, and tasks from the same distribution [5].

Token numbers differ by far more than scores do. The GPT-5.5 harness used 29.3M tokens for a medal rate of 19.1, and the DeepSeek V4 harness used 208.4M tokens for 19.6 [17]. That is 7.1 times the tokens, and 179.1M extra tokens for half a point [27]. The post calls those the same performance while labelling one a medal rate and the other a score, so the comparison holds only if both are the same metric [17]. Across the MLE-bench experiment, token overhead varied by 19x between harnesses [18].

What to watch

  • Whether the HarnessDev paper reports line counts per phase, which would resolve the 1,006 against 950.6 discrepancy.
  • Whether the generated harnesses are released as artifacts, so the unobserved component instances can be traced outside the authors' own logs.
  • Whether a token budget enters the evolution objective, which would test whether the 19x spread is a choice or a byproduct.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories