HarnessMM: Recursive Self-Improvement for Harness Token Efficiency

“Agent harnesses repeatedly invoke reasoning after tool feedback, even when an earlier call has already fixed the next action.”

Yuhua Jiang, Chang Xu, Feifei Gao +1 · 4 authors · Tsinghua University and Microsoft Research Asia · 2026 · arXiv:2610.32813

After every tool response, how much reasoning actually needs to run again?

Opening

Agent harnesses call reasoning again after every piece of tool feedback, even when an earlier call has already fixed the next action, and most of that reasoning just repeats a decision that already exists. For an agent running many turns every day, the repetition piles up into the token bill of each task while the model weights never change. HarnessMM looks for the cut by reusing the very decisions that were already settled.

What the paper does

The authors add a controller at the model-tool boundary: a decision that has been resolved is stored as an executable graph holding the exact action, the literal arguments, the causal dependencies and public guards. On a later run, when the observed receipt matches a stored decision, the controller replays that exact action through the native interface instead of calling reasoning one more time, while the actor weights stay fixed and genuinely new semantic decisions or unsupported evidence still fall back to the original model. They also let recursive self-improvement refine companion harness configurations from training feedback, with validation selecting the configuration that ships. A separate ablation on MBPP measures 26.91% lower cost than single-use graphs and 19.52% lower cost than retained callbacks, so the saving does not come from one graph format alone. The representation restricts what feedback may change, and complete-task measurements establish both quality and cost.

Findings

  1. Harnesses re-run reasoning after every tool feedback even when the next action was already fixed. (Agent harnesses repeatedly invoke reasoning after tool feedback, even when an earlier call has already fixed the next action)

  2. A controller at the model-tool boundary replaces later reasoning callbacks with stored resolved decisions while the actor weights stay fixed. (A controller at the model-tool boundary reuses resolved decisions to replace later reasoning callbacks while actor weights remain fixed)

  3. On HumanEval the method holds Codex success at 90.82% while cutting Tokens/task from 66.72k to 47.02k, a 29.54% saving; on the DeepSeek Harness success rises from 71.43% to 85.71% while tokens per task fall from 96.28k to 11.62k, an 87.93% saving. (On HumanEval, HarnessMM preserves Codex success at 90.82% while reducing Tokens/task (k) from 66.72 to 47.02 (29.54% saving))

Caveat

The authors state no limitation in the abstract. Their closing sentence only asserts that guarded decision reuse is a practical way to reduce repeated reasoning in existing harnesses, so the savings should be read inside the context of the HumanEval benchmark and the paper’s own configuration, not as numbers owed to every harness. That matters because a team adopting the idea still needs its own measurement to know what its harness actually gives back.

What this means for 5ac

In Hermes, many cards run the same chain of steps: read a file, run a command, read the output, decide the next move, and every loop spends reasoning tokens. Decision reuse here means a skill records the settled operation, the exact script with the exact arguments, and the next run replays it instead of letting the model re-derive it from scratch. Cron is the natural place to test this first: for daily repeated jobs like a health-check sweep, storing the per-step results and dropping the surplus reasoning cuts the cost of each run visibly. The job is to keep the guards exactly as the paper frames them: reuse only when the receipt matches, and when the context has changed or the evidence is new, still let the model decide rather than replaying a stale action.

Source