Papers
Topics
Authors
Recent
Search
2000 character limit reached

HarnessMM: Recursive Self-Improvement for Harness Token Efficiency

Published 23 Oct 2026 in cs.AI | (2610.32813v1)

Abstract: Agent harnesses repeatedly invoke reasoning after tool feedback, even when an earlier call has already fixed the next action. We introduce HarnessMM (Harness Minus Minus), a method for improving harness token efficiency through guarded decision reuse and recursive self-improvement (RSI). RSI iteratively refines companion harness configurations from training feedback, with validation selecting the configuration for deployment. A controller at the model-tool boundary reuses resolved decisions to replace later reasoning callbacks while actor weights remain fixed. Executable Decision Graphs store exact actions, literal arguments, causal dependencies, and public guards. Guarded Decision Reuse activates these persistent decisions from observed receipts; Certified Callback Substitution executes them through the native interface and records removal of the registered slow callback. New semantic decisions, unsupported evidence, and selector abstention invoke the original actor again. The representation restricts what feedback may change, while complete-task measurements establish quality and cost. On HumanEval, HarnessMM preserves Codex success at 90.82\% while reducing Tokens/task (k) from 66.72 to 47.02 (29.54\% saving). For DeepSeek Harness, success rises from 71.43\% to 85.71\% while Tokens/task (k) fall from 96.28 to 11.62 (87.93\% saving). A separate MBPP ablation measures 26.91\% lower cost than single-use graphs and 19.52\% lower cost than retained callbacks. These results establish guarded decision reuse as a practical way to reduce repeated reasoning in existing harnesses.

Authors (4)

Summary

  • HarnessMM, a recursive self-improvement mechanism, targets token inefficiency by treating reasoned actions as executable commitments, eliminating repeated reasoning calls. It is optimized for token efficiency across a complete task population, including failed workflows.
  • HarnessMM's architecture includes three key components: executable decision graphs, guarded decision reuse, and certified callback substitution, enabling reconstruction of arguments without altering executions semantics. The Exit of Replaced reasoning calls are certified,

The paper studies a specific source of inefficiency in tool-using agents: repeated invocation of a reasoning model after tool feedback even when a previous reasoning call has already determined the next action. “HarnessMM: Recursive Self-Improvement for Harness Token Efficiency” (2610.32813) proposes to treat such actions as persistent, executable commitments rather than regenerating them at every reasoning boundary. The central claim is that token efficiency can be improved without changing actor weights, tools, task interfaces, or native execution semantics, provided that the harness can distinguish unresolved semantic decisions from resolved actions whose readiness depends only on subsequently observed public feedback.

Problem formulation and central claim

The paper frames harness optimization as a constrained computation-substitution problem. Let the original harness invoke a fixed actor and tool interface over a task execution graph. HarnessMM modifies the execution policy so that some reasoning nodes are not invoked when a previously authored action can be safely reused. The optimization target is complete episode cost, including input and output tokens for authorship, routing, selectors, fallback, recovery, finalization, failed calls, and shared authoring. This accounting is important because a short selector or fast path does not provide a saving unless the computation it introduces is smaller than the reasoning callback it removes.

The paper calls this accounting issue the “Substitution Paradox.” A fast decision mechanism can increase cost if it is appended to the original reasoning path rather than substituting for it. Consequently, the claimed efficiency gain requires both a capability constraint and actual callback elimination. Quality is evaluated on the complete task population, including unsuccessful tasks, while cost is measured over the same population. This avoids attributing savings only to successful trajectories or to a subset of locally favorable substitutions.

The method therefore makes a relatively narrow claim. It does not assert that arbitrary future actions can be predicted from earlier reasoning, nor that a guard certifies task correctness. Instead, it assumes that a previous actor call can sometimes produce an action whose literal arguments and semantic role are already resolved, while later observations determine only whether the action is ready.

HarnessMM architecture

HarnessMM consists of three principal components: Executable Decision Graphs, Guarded Decision Reuse, and Certified Callback Substitution. Recursive self-improvement supplies an offline procedure for refining the surrounding harness configuration, but it is distinct from the online execution mechanism.

Executable Decision Graphs

An Executable Decision Graph (EDG) is an acyclic continuation authored by a slow reasoning call. Each node stores a native action, complete literal arguments, predecessor dependencies, and a public execution guard. For a coding task, a single actor call might specify a file-writing operation, a compilation command, and a test command. The tool receipt after compilation determines whether the test command is admissible, but it need not cause the actor to regenerate the test command and its arguments.

This representation imposes a structural separation between action semantics and execution readiness. Literal closure is enforced syntactically: the selector cannot fill in missing arguments or construct a new command. Semantic closure is an assumption about the authoring call and the adapter: the authored action must remain appropriate whenever its public guard passes. The paper explicitly acknowledges that a passing guard proves only the declared public condition, not general task correctness.

Guarded Decision Reuse

Guarded Decision Reuse (GDR) retains an EDG across tool transitions. After each receipt, the controller updates predecessor completion and evaluates public guards. A node is eligible only when its predecessor is complete, its guard is true, and its arguments are closed. Unsupported observations, unmet dependencies, ambiguous states, or arguments requiring new inference cause the controller to defer to the original actor.

The selector is constrained to return an eligible node identifier or abstain. It cannot revise arguments, invent actions, or reinterpret the graph. When there is exactly one eligible node, execution can be deterministic and incur no selector-model tokens. When multiple nodes are eligible, a typed selector may choose among them. Abstention and empty candidate sets preserve the original slow path.

This design makes reuse conservative by construction. Feedback is used to activate an existing commitment, not to generate a new semantic decision. The distinction is central to the paper’s safety and attribution arguments: the controller can guarantee that it executed an authored action under a declared public condition, but it cannot guarantee that the authored action was substantively correct.

Certified Callback Substitution

Certified Callback Substitution (CCS) is the mechanism that turns reuse into an actual efficiency intervention. At a registered reasoning boundary, the controller dispatches the stored action through the original native interface and omits the corresponding slow callback. The substitution certificate binds the graph hash, decision identifier, predecessor receipt, exact arguments, tool receipt, and the identifier of the bypassed callback.

The certificate is not a correctness proof. It verifies that the native action was executed with the authored arguments and that the registered callback was absent from the physical request sequence. Task scoring separately determines whether this substitution helped or harmed the task. This separation is methodologically sound: execution omission is an observable structural property, whereas the quality of the counterfactual reasoning call is unavailable because it was never made.

Recursive self-improvement

Recursive self-improvement (RSI) operates offline over harness configurations. A current harness produces training feedback, candidate edits are proposed, disjoint validation selects a candidate, and the selected harness is frozen before test evaluation. The search can modify author prompts, context handling, adapter rules, and related configuration, but actor weights, tools, task interfaces, evaluators, and deployment limits remain fixed.

The paper carefully separates RSI from runtime decision reuse. RSI determines the configuration that will be deployed; GDR and CCS determine, within an episode, whether an authored decision can replace a future actor callback. This distinction matters because some reported benchmark gains combine multiple interventions, including prompt changes, context compaction, finalization changes, and executable reuse. The MBPP ablations are consequently more informative for attributing the core mechanism than the integrated harness comparisons.

The visual RSI study on MiniWoB++ provides a direct illustration of iterative harness development.

Figure 1

Figure 1: Eight training-guided HarnessMM RSI iterations on MiniWoB++, showing increasing success and decreasing complete episode token cost under persistent decision reuse.

Across eight iterations on the same 32 training tasks, HarnessMM success increases from 34.38% to 90.63%, while Tokens/task decreases from 3.26k to 1.06k. At iteration eight, both the single-use and persistent-reuse arms solve 29 of 32 tasks, but persistent reuse reduces cost from 1.51k to 1.06k tokens per task, a 29.83% saving. Calls per task fall from 1.47 to 1.03, with 16 second-or-later executions occurring inside retained graphs. These results demonstrate iterative improvement of a fixed execution contract, although they are training-task measurements rather than held-out test results.

Experimental design and accounting

The experiments compare HarnessMM against native Codex and DeepSeek Harness configurations, as well as against targeted ablations. The principal coding comparisons use the same task sets, backbone, tools, evaluator, task limits, and complete-task accounting within each harness pair. HumanEval uses all 98 test tasks, and MBPP-sanitized uses all 257 test tasks.

The paper distinguishes three kinds of evidence:

  1. Integrated harness comparisons measure the quality and cost of a deployed HarnessMM configuration relative to its native parent.
  2. Mechanism ablations vary graph persistence and callback substitution while holding the coding execution environment fixed.
  3. Certificates and request ledgers verify that stored actions were executed natively and that specified reasoning callbacks were omitted.

This separation is necessary because reduced total model-call counts in an integrated comparison need not equal the number of certified substitutions. Context management, fallback behavior, finalization, and changes in trajectory can also alter the number of physical requests.

Main coding results

The strongest results concern HumanEval and MBPP-sanitized. They show substantial token reductions, but the quality effects differ by harness and model.

Benchmark and harness Success baseline Success with HarnessMM Tokens/task baseline Tokens/task with HarnessMM Token change
HumanEval, Codex 90.82% 90.82% 66.72k 47.02k −29.54%
HumanEval, DeepSeek Harness 71.43% 85.71% 96.28k 11.62k −87.93%
MBPP-sanitized, Codex 91.83% 90.66% 129.55k 49.22k −61.99%
MBPP-sanitized, DeepSeek Harness 90.27% 91.83% 53.98k 10.61k −80.35%

The Codex HumanEval result satisfies the paper’s zero-regret objective at the observed population level: success remains 90.82% while token use falls by 19.70k per task. The DeepSeek Harness result is more pronounced and contradictory in the relevant sense: HarnessMM both reduces cost by 87.93% and raises success by 14.28 percentage points. Paired outcomes contain 22 improvements, eight regressions, and 68 unchanged tasks; the reported exact McNemar test gives p=0.0161p=0.0161. This establishes a statistically detectable paired difference for that comparison, although it does not by itself identify which component of the integrated configuration caused the quality increase.

The MBPP results show that the effect is not limited to HumanEval. DeepSeek Harness improves from 90.27% to 91.83% while reducing cost by 80.35%. Codex loses 1.17 percentage points while reducing cost by 61.99%, demonstrating that substantial efficiency gains do not guarantee zero quality regret across all actor-harness combinations.

The paper also reports a separate MiMo-v2.6-pro evaluation. On HumanEval, DeepSeek Harness improves from 96.94% to 97.96% while reducing cost from 11.62k to 4.40k tokens per task, a 62.12% saving. Codex improves from 93.88% to 94.90% while reducing cost from 62.60k to 10.09k. On MBPP-sanitized, Codex changes from 96.50% to 97.28% at 47.56k versus 11.00k tokens, while DeepSeek Harness changes from 97.67% to 98.05% at 6.20k versus 5.11k. These results suggest that the substitution mechanism can remain useful when the underlying actor is already substantially more capable, although the relative saving is smaller when the parent harness is already efficient.

The integrated coding comparison is summarized visually below.

Figure 2

Figure 2: HarnessMM quality and token-cost comparisons across native harnesses and selected benchmark configurations; lower token cost is obtained without uniformly sacrificing task success.

Mechanism attribution through MBPP ablations

The most direct test of GDR and CCS is the MBPP-sanitized ablation with 257 test tasks. Full HarnessMM is compared with single-use EDGs, retained callbacks, and disabled EDG execution.

Condition Success Tokens/task Certified bypasses
Full HarnessMM 93.77% 13.17k 407
Without GDR: single-use EDG 93.00% 18.03k 212
Without CCS: callbacks retained 93.39% 16.37k 0
Without EDG execution 95.33% 16.19k 0

Persistent reuse is the clearest isolated effect. Relative to single-use graphs, GDR lowers cost by 26.91% and increases success by 0.78 percentage points. The adjusted bootstrap interval for cost savings is reported as [4.01,45.57]%[4.01,45.57]\%, while the correctness interval includes zero. Thus, the evidence supports a robust cost advantage for persistence in this experiment, but not a statistically established quality advantage.

CCS also matters. Retaining callbacks while preserving graph execution increases cost from 13.17k to 16.37k tokens per task, corresponding to a 19.52% saving for full HarnessMM. The full system solves one additional task in this comparison. However, the reported cost interval includes zero, so the paper appropriately treats the measured callback-removal advantage as supportive but less statistically decisive than the GDR contrast.

Disabling EDG execution yields the highest observed success, 95.33%, at 16.19k tokens per task. Full HarnessMM is therefore 18.62% cheaper but solves four fewer tasks. This result is important because it prevents an overly strong interpretation of the method: the lowest-cost configuration is not uniformly best on quality, and the quality-cost trade-off can favor a slower non-executing control on a finite benchmark.

The ablation also provides concrete reuse coverage. Full HarnessMM performs 407 certified bypasses, including repeated bypasses in 201 graphs. The single-use control performs 212 bypasses and discards the remaining graph after its first execution. The difference directly operationalizes the paper’s claim that retaining a graph across multiple feedback transitions is necessary for sustained savings.

Broader benchmark evidence

The paper includes companion studies on ALFWorld, SearchQA, LiveMath, AIME, Terminal-Bench 2, and GAIA2. These results should not be interpreted as homogeneous evidence for the same mechanism because the adapters and surrounding configurations differ.

On ALFWorld, HarnessMM’s selected instruction configuration reaches 66.20% success at 31.12k tokens per task, compared with 63.29% at 101.33k for SkillOpt and 61.74% at 40.30k for AutoSaddler. The paper’s instruction ablations show that task-family guidance is the dominant component: removing it reduces success to 49.21% while increasing cost to 38.94k. These are instruction-content results under a common actor, not independent demonstrations of EDG persistence.

On SearchQA, HarnessMM reaches 76.76% exact match at 0.99k tokens per task on the stated validation population. It saves 19.08% relative to No Skill, with a reported paired 95% interval of [16.57,21.23]%[16.57,21.23]\%. The improvement is obtained through a terminal-answer adapter involving source selection, draft generation, acceptance checks, and paid fallback rather than the multi-action coding graph. It therefore supports the broader commit-or-defer interface, but not the specific causal contribution of persistent executable action graphs.

AIME reveals a negative cost case. HarnessMM reaches 87.14% accuracy, close to No Skill at 86.96%, but costs 5.90k tokens per task, above No Skill’s 4.59k and AutoSaddler’s 4.90k. Shared authorship contributes 1.08k tokens per task, and output savings do not offset additional input and authoring cost. This result directly validates the Substitution Paradox: a method that reduces some generated reasoning can still be more expensive when the workload has few reusable action transitions.

On GAIA2, HarnessMM reaches 43.96% success at 639.64k tokens per task, versus 42.71% and 730.22k for No Skill. The 12.41% cost reduction is accompanied by a 1.25-point success increase, but 99.47% of HarnessMM actor cost is input. Only 146 verified fast executions occur among 10,424 native action attempts. The result therefore measures a combined configuration involving literal banks and context handling, and does not isolate fast execution from input-context reduction.

The paper also reports negative or incomplete cases. On Terminal-Bench development snapshots, token reductions are accompanied by quality declines. A CoT/Jev-style configuration executes fast actions in most episodes but costs more than the original harness and loses success. These cases reinforce the paper’s requirement that callback substitution, not merely fast-path activation, must be evaluated with complete accounting.

Limitations and open questions

The method depends on a task-specific public-state adapter, a native callback boundary, a serialization scheme for literal actions, and guards that sufficiently characterize readiness. The paper does not provide a general procedure for discovering semantically valid guards. Its key implication, eligible⁡(d,s)⇒valid⁡(d,s)\operatorname{eligible}(d,s) \Rightarrow \operatorname{valid}(d,s), remains an adapter-dependent assumption evaluated indirectly through benchmark performance.

The actor’s earlier decision can also be wrong even when all structural checks pass. Certificates establish exact execution and callback omission, not semantic correctness, safety, or equivalence to the omitted reasoning trajectory. The system therefore preserves a fallback to slow reasoning for unsupported evidence, abstention, unmet dependencies, and new semantic decisions, but the quality of this defer policy is task dependent.

The integrated comparisons combine EDG reuse with context management, author-prompt changes, finalization rules, and harness-specific configuration. The MBPP ablation improves causal attribution, but it still does not isolate every implementation detail, including certificate overhead and selector behavior. Several benchmark results are single-seed or one-execution-per-task measurements, and the paper notes runtime nondeterminism, provider accounting assumptions, incomplete historical cost records, and previously exposed public data in some companion studies.

A further open question is whether the large savings persist after amortizing RSI development and validation costs over realistic deployment volumes. The paper reports development cost separately and correctly avoids conflating deployment savings with optimization expenditure. However, a complete economic break-even analysis requires measured provider pricing, latency, caching behavior, and energy use, none of which follows from token savings alone.

Conclusion

HarnessMM presents a constrained execution transformation for agent harnesses: slow reasoning authors episode-specific executable continuations, public receipts activate guarded actions, and certified native dispatch removes redundant reasoning callbacks. Its strongest evidence is the combination of complete-task accounting, request-level omission audits, and mechanism ablations.

On HumanEval, the method preserves Codex success at 90.82% while reducing token use by 29.54%, and raises DeepSeek Harness success from 71.43% to 85.71% while reducing cost by 87.93%. On MBPP-sanitized, persistent graph reuse lowers cost by 26.91% relative to single-use EDGs, while callback substitution yields an additional measured advantage over retained callbacks. The results support guarded decision reuse as a practical harness-level optimization, but they do not establish a general correctness guarantee or uniform quality dominance. Its effectiveness depends on the prevalence of semantically resolved actions, the fidelity of public guards, and whether authorship and control overhead remain below the reasoning computation they replace.

Whiteboard

Explain it Like I'm 14

1. What is this paper about?

This paper introduces HarnessMM, a method for making AI agents use fewer computer tokens while solving tasks.

An AI agent often works like this:

  1. Think about what to do.
  2. Use a tool, such as a code editor or command line.
  3. Look at the tool’s result.
  4. Think again.
  5. Use another tool.

The problem is that the agent may think again even when it has already decided what the next action should be. HarnessMM tries to avoid this unnecessary repeated thinking.

The main idea is simple:

If an earlier decision is already clear, save it and use it later instead of asking the AI model to think through the same decision again.

The paper also uses recursive self-improvement, meaning that the system tests different ways of organizing the AI agent and keeps the versions that work best.

2. What questions did the researchers ask?

The researchers mainly wanted to find out:

  • Can an AI agent reuse decisions it has already made?
  • Can this reduce the number of tokens the agent uses?
  • Can the system save tokens without making the agent worse at completing tasks?
  • When is it safe to skip another reasoning step?
  • Does the method work with different AI systems and different coding tasks?

A token is a small piece of text processed by an AI model. Fewer tokens usually means lower cost, although it does not automatically guarantee that the system will run faster.

3. How does HarnessMM work?

Saving decisions in a decision graph

The system stores planned actions in what the paper calls an Executable Decision Graph, or EDG.

Think of an EDG as a flowchart or checklist. It records:

  • What action should be taken
  • The exact arguments for that action
  • Which earlier action must happen first
  • What condition must be true before the action can happen

For example, while solving a programming problem, the AI might already decide to:

  1. Write code to a file.
  2. Run a compiler.
  3. If compilation succeeds, run tests.

The AI does not need to rethink steps 2 and 3 from scratch if their exact commands are already known.

Checking conditions with guards

HarnessMM uses guards, which are like safety checks.

For example:

  • “Only run the tests if compilation succeeded.”
  • “Only edit this file if the file exists.”
  • “Only run this command after the previous command has finished.”

The system checks the actual result from the tool, called a receipt, before carrying out the saved action. It does not simply guess that the previous action worked.

This part is called Guarded Decision Reuse.

Replacing a reasoning call

If a saved action is ready and safe to use, HarnessMM sends it directly to the original tool.

Normally, the process might be:

1
Tool result → AI thinks → next action

With HarnessMM, it can become:

1
Tool result → saved decision → next action

This is called Certified Callback Substitution. The system records proof that:

  • The saved decision was used
  • The exact command or action was executed
  • The normal reasoning call was skipped
  • The tool produced a real result

If the situation is new, confusing, or unsupported, the system does not reuse the old decision. Instead, it asks the original AI model to reason again.

Improving the harness

The paper also uses recursive self-improvement, or RSI. This does not mean the AI changes its own basic model. Instead, the researchers create different versions of the surrounding system, test them on training tasks, and choose the best version for later testing.

The model’s weights remain fixed. In other words, the AI’s main “brain” is not retrained; the researchers change how it is used.

4. What did the researchers find?

The researchers tested HarnessMM on coding benchmarks such as HumanEval and MBPP. These benchmarks contain programming problems that an AI must solve.

HumanEval results

On 98 HumanEval tasks:

System Success rate Tokens per task
Codex 90.82% 66.72k
Codex + HarnessMM 90.82% 47.02k
DeepSeek Harness 71.43% 96.28k
DeepSeek Harness + HarnessMM 85.71% 11.62k

The results show that:

  • With Codex, success stayed exactly the same while token use fell by about 29.54%.
  • With the DeepSeek system, success increased from 71.43% to 85.71%.
  • At the same time, DeepSeek’s token use fell by about 87.93%.

MBPP results

On another coding benchmark, the system also greatly reduced token use.

For example, one DeepSeek comparison changed from:

  • 53.98k tokens per task to 10.61k
  • Success increased from 90.27% to 91.83%

The researchers also performed an experiment to separate the effects of the different parts of HarnessMM. They found that keeping decisions for use across multiple tool steps and actually removing unnecessary reasoning calls both contributed to the savings.

Why are these findings important?

Many AI agents spend a large amount of their cost repeatedly explaining or reconsidering actions that are already known. HarnessMM shows that an agent can act more like a careful programmer:

  • Think carefully once
  • Save the plan
  • Check whether each step is allowed
  • Carry out safe steps directly
  • Think again only when something genuinely changes

This is important because AI coding agents can be expensive when they use many tokens, especially on long tasks.

5. What could this research lead to?

HarnessMM could make AI agents more practical and affordable. It might help coding assistants, computer-use agents, and other tool-using systems complete tasks with less repeated reasoning.

The method could be especially useful when:

  • Several future actions are already known
  • Tool results mainly determine whether an action is ready
  • The exact action does not need to be changed
  • Safety conditions can be checked clearly

However, the system must be careful. Reusing an old decision could cause mistakes if the situation has changed. That is why HarnessMM uses guards and returns to the original AI whenever new reasoning is needed.

Overall, the paper’s main message is:

AI agents do not always need to think again after every tool result. If a previous decision is still correct and the required conditions are met, the agent can safely reuse it, saving tokens while keeping its performance the same or even improving it.

Practical Applications

Immediate Applications

  • LLM coding agents and software engineering (industry): Integrate HarnessMM as a controller between an existing reasoning model and tools such as shells, compilers, test runners, file editors, and version-control systems. An agent can author a sequence such as “write file → compile → run tests” once, then reuse later actions when public receipts satisfy explicit guards.
    • Potential product/workflow: A drop-in execution-efficiency layer for SWE agents, CI assistants, terminal agents, and code-generation platforms.
    • Evidence: On HumanEval, the method reduced Codex token use by 29.54% while maintaining 90.82% success; with DeepSeek Harness, token use fell by 87.93%, while success increased from 71.43% to 85.71%.
    • Dependencies: Tool interfaces must expose reliable receipts and stable action semantics. The stored arguments must be fully resolved; any action requiring new interpretation must trigger fallback reasoning.
  • Terminal automation and DevOps: Apply Executable Decision Graphs (EDGs) to repetitive command sequences involving builds, tests, deployments, log inspection, and environment setup. For example, a successful build receipt can activate an already-authored test command without another model call.
    • Potential tool: A certified command-execution middleware for agentic terminals, with graph hashes, decision IDs, predecessor receipts, and omitted-callback records.
    • Dependencies and risks: Public guards must distinguish safe states from partial failures. Deployment, deletion, permission changes, and other high-impact commands should require human approval or stricter policies rather than automatic reuse.
  • Agent infrastructure and API orchestration: Use Guarded Decision Reuse (GDR) to avoid repeatedly asking an LLM to select the next API call when the action and literal arguments have already been fixed and only execution status is changing.
    • Sectors: Cloud operations, customer-service workflows, enterprise resource planning, database administration, and web automation.
    • Potential workflow: After an agent creates a ticket, a previously resolved notification or metadata-update action can execute once the ticket API returns a qualifying receipt.
    • Dependencies: APIs need typed schemas, deterministic or clearly interpretable status codes, idempotency controls, and publicly observable state. Ambiguous natural-language feedback should cause selector abstention and return control to the original model.
  • Cost reduction for high-volume LLM services: Deploy Certified Callback Substitution (CCS) to reduce input and output token consumption in workloads with long multi-step episodes, such as coding assistants, research agents, and support automation.
    • Potential product: A token-accounting and callback-audit service that reports authorship cost, selector cost, fallback cost, recovery cost, and actual bypassed callbacks.
    • Dependencies: Savings must be calculated over complete tasks, including graph construction, selector calls, failed executions, and fallback reasoning. Token savings should not be assumed to imply lower wall-clock latency, electricity use, or total monetary cost without separate measurement.
  • Model-serving and agent-platform optimization: Use the paper’s policy-level objective—minimize execution cost subject to a predefined quality tolerance—to evaluate routing and execution policies in production.
    • Potential workflow: Compare a baseline harness and HarnessMM on the same task population, define an allowed quality regret ϵ\epsilon, and deploy only if measured performance remains within that bound.
    • Dependencies: Requires representative held-out tasks, stable evaluators, monitoring for distribution shift, and confidence intervals around quality differences.
  • Research and benchmarking infrastructure (academia): Add callback-substitution statistics to agent evaluations rather than reporting only final accuracy and average generated tokens. Useful metrics include calls per task, certified bypasses, fallback rate, graph-authoring cost, and complete-episode cost.
    • Potential tool: A standardized benchmark instrumentation package for ReAct-style agents and tool-using models.
    • Value: This separates genuine elimination of reasoning calls from methods that merely add a small selector while retaining the original callback—the paper’s “Substitution Paradox.”
    • Dependencies: Benchmarks must record all physical model requests and use identical tasks, tools, limits, and scorers across comparisons.
  • Education and developer training: Use EDGs to teach the distinction between semantic uncertainty—what action should be taken—and execution uncertainty—whether an already-decided action is now permitted.
    • Potential application: Interactive programming laboratories in which students inspect action graphs, guards, receipts, fallback paths, and certificates.
    • Dependencies: Educational implementations should expose graph state clearly and prevent unsafe commands from being executed solely because a guard passed.
  • Personal productivity and daily-life assistants: Apply guarded reuse to low-risk routines such as calendar updates, shopping-list maintenance, file organization, or household reminders. For example, a resolved reminder can be issued after a calendar service confirms that an event was created.
    • Dependencies: Suitable only for reversible, low-consequence actions unless explicit confirmation is obtained. Privacy controls, authentication boundaries, stale-state detection, and idempotency are essential.

Long-Term Applications

  • Robotics and embodied agents: Extend EDGs to robot action sequences in which high-level reasoning resolves a plan while sensor receipts determine whether the next motion is admissible—for example, grasping an object after visual confirmation that it is present.
    • Potential product: A safety-certified action graph layer for warehouse robots, delivery systems, and household robotics.
    • Dependencies: The current method relies on public guards and literal action arguments; real-world robotics additionally requires probabilistic perception, continuous control, timing guarantees, collision avoidance, and recovery under uncertain or adversarial sensor data. Formal safety verification would be needed before autonomous deployment.
  • Healthcare workflow automation: Use guarded reuse for administrative and clinical-support processes, such as scheduling, document routing, laboratory-order preparation, or follow-up reminders, where a prior decision is fixed and the next action depends on a verified receipt.
    • Potential workflow: A system prepares a follow-up action after a laboratory result or appointment status satisfies a predefined condition, while escalating ambiguous cases to a clinician.
    • Dependencies: The paper does not establish clinical safety. Deployment would require privacy protection, auditability, regulatory compliance, calibrated uncertainty, human oversight, and strict separation between administrative automation and clinical judgment.
  • Finance and compliance operations: Apply receipt-bound action reuse to transaction reconciliation, compliance checks, document collection, and workflow escalation. A previously resolved action could proceed when an external system confirms a qualifying status.
    • Potential product: An auditable financial-operations agent with immutable graph hashes and callback-substitution certificates.
    • Dependencies: Financial actions are often irreversible and regulated. Systems would require authorization controls, segregation of duties, fraud detection, human approval for material actions, and protection against stale or manipulated receipts.
  • Energy and industrial control: Use the method for monitoring and scheduling in power grids, data centers, manufacturing, and building-management systems, where repeated status checks can activate preplanned low-level actions.
    • Potential workflow: A maintenance or load-management sequence proceeds only after telemetry satisfies explicitly defined public guards.
    • Dependencies: Token efficiency is not sufficient for safety-critical control. Real-time latency, deterministic behavior, sensor integrity, fail-safe operation, cyber-security, and formal verification would be required.
  • Long-horizon autonomous agents with recursive self-improvement: Extend RSI beyond benchmark-specific harness configuration to systems that refine their action schemas, guard libraries, recovery policies, and context-management strategies across deployment cycles.
    • Potential tool: An offline harness optimizer that proposes candidate EDG schemas, evaluates them on disjoint training and validation tasks, and freezes the selected configuration before testing or production release.
    • Dependencies: Recursive improvement can amplify specification errors or benchmark overfitting. Safe use requires immutable evaluation sets, versioning, rollback, change approval, monitoring, and explicit limits on what the system may modify.
  • Cross-task reusable procedural memory: Combine episode-specific EDGs with more general skills or macros. A future system could learn which portions of a graph are safe to generalize while retaining literal, task-specific commitments for execution.
    • Potential product: A hierarchical agent memory containing reusable procedures, public guards, provenance records, and task-local action graphs.
    • Dependencies: The paper distinguishes EDGs from general skills: EDGs store fully resolved episode-specific decisions. Generalization would therefore require additional research on abstraction, stale plans, argument substitution, permissions, and transfer across tools or environments.
  • Formal verification and governance of agent actions: Use CCS certificates as a foundation for auditing which reasoning callbacks were bypassed, which exact arguments were executed, and which receipts justified execution.
    • Potential application: Regulatory reporting, incident investigation, reproducible agent evaluation, and enterprise approval workflows.
    • Dependencies: A certificate proves execution provenance and callback omission, not that the action was globally correct or safe. Governance systems would need independent policy checks, tamper-resistant logs, receipt authenticity, and end-to-end validation of guard definitions.
  • Energy-aware and latency-aware agent scheduling: Investigate whether callback substitution reduces electricity consumption, response time, or server load in addition to token use. The paper explicitly limits its claims primarily to token efficiency.
    • Potential research direction: Couple complete-task token accounting with GPU utilization, memory traffic, queueing delay, tool latency, and carbon-intensity measurements.
    • Dependencies: Selector inference, graph maintenance, serialization, deterministic checks, and tool execution may offset token savings. Benefits will depend on model architecture, caching, serving infrastructure, and workload shape.

Glossary

  • Abstention: A deliberate decision by a selector not to choose any available action, thereby deferring to the original reasoning process. “A typed selector chooses an eligible decision or abstains”
  • Ablation: An experiment that removes or isolates components of a method to measure their individual effects. “A separate MBPP ablation measures 26.91\% lower cost than single-use graphs”
  • Amortization: The allocation of a one-time development cost across multiple deployment tasks or executions. “This deployment amortization is separate from reuse within an episode.”
  • Acyclic graph: A directed graph containing no cycles, so its dependencies cannot loop back to an earlier node. “Edges connect the root or an earlier node to a successor, forming an acyclic graph.”
  • Actor: The model component responsible for reasoning and producing actions or executable decision structures. “The actor parameters θ\theta are fixed.”
  • Callback: A registered invocation of a reasoning or computation component triggered at a particular execution boundary. “CCS then dispatches the stored action through the native interface and omits the corresponding reasoning callback.”
  • Capability constraint: A requirement that an optimization must not reduce performance beyond a predefined tolerance. “This is a policy-level constraint, assessed by evaluating both harnesses on the same tasks.”
  • Capability regret: The difference in benchmark quality between an original harness and a modified policy. “Relative to the original harness h0h_0, define capability regret Rb(π)=Qb(h0)−Qb(hπ)R_b(\pi)=Q_b(h_0)-Q_b(h_\pi).”
  • Causal dependency: A relationship in which one action or event must be completed before another can be executed. “Executable Decision Graphs store exact actions, literal arguments, causal dependencies and public guards.”
  • Certified Callback Substitution (CCS): The verified replacement of a reasoning callback with execution of a previously resolved action. “Certified Callback Substitution (CCS) then dispatches the stored action through the native interface”
  • Complete-task accounting: Cost measurement that includes every relevant operation over an entire task, including failed attempts and auxiliary processing. “Complete-task accounting includes graph authorship, selection, remaining slow calls, fallback and unsuccessful executions.”
  • Context compaction: The reduction or compression of contextual information supplied to a model call. “Prompt editing, context compaction and finalization rules configure the surrounding harness.”
  • Controller: A software component that decides whether to reuse a stored action or invoke the reasoning model. “HarnessMM inserts a controller at the native decision boundary”
  • Decision graph: A structured graph representing actions, their arguments, dependencies, and conditions for execution. “At slow decision ii, actor H0H_0 emits the current tool action and an EDG Gi=(Vi,Ei)G_i=(V_i,E_i)”
  • Decision reuse: The repeated execution of a previously resolved decision when later feedback confirms that it is applicable. “We introduce HarnessMM (Harness Minus Minus), a method for improving harness token efficiency through guarded decision reuse”
  • Deterministic tool: A tool whose output is fixed by its input and execution state, without requiring model-generated reasoning. “Deterministic tools use no actor tokens but affect subsequent calls and quality.”
  • Deployment amortization: The distribution of development or authoring costs across the tasks on which a system is deployed. “This deployment amortization is separate from reuse within an episode.”
  • Eligibility: The condition that determines whether a stored decision is currently allowed to execute. “GDR determines their eligibility”
  • Executable Decision Graph (EDG): A bounded graph encoding fully specified actions and the conditions and dependencies governing their execution. “Executable Decision Graphs (EDGs) store actions and literal arguments already resolved by slow reasoning”
  • Execution guard: A public-state predicate that must evaluate to true before a stored action can be run. “The author fixes gjg_j with the node; the adapter evaluates it against subsequently observed receipts.”
  • Execution receipt: A record of the result produced by a tool or action execution. “Each observed receipt updates predecessor completion and guard truth.”
  • Fallback: A return to an alternative execution path, typically the original reasoning process, when reuse cannot be safely performed. “The ledger charges authorship, selector inputs and outputs, added context, remaining slow calls, fallback, recovery, finalization and failed paid executions.”
  • Fast–slow architecture: A system design that separates inexpensive, shallow decisions from more expensive, deeper reasoning. “Fast--slow architectures and routing change who reasons and how deeply”
  • Guarded Decision Reuse (GDR): The reuse of stored decisions only when their dependencies, arguments, and public guards indicate that execution is safe. “Guarded Decision Reuse (GDR) retains these decisions across tool transitions and checks whether observed receipts satisfy their guards.”
  • Harness: An execution framework that connects a reasoning model to tools, feedback, and task-management logic. “Agent harnesses connect model reasoning to tool execution.”
  • Literal arguments: Fully specified, exact arguments to an action that do not require additional semantic interpretation. “EDG stores resolved decisions, GDR determines their eligibility, and CCS substitutes native execution for registered slow callbacks.”
  • Native interface: The original tool-execution interface used by the unmodified system. “It runs the exact authored action through the original tool interface”
  • Native execution: Direct invocation of an action through the system’s original execution mechanism rather than through a newly generated reasoning step. “CCS converts an admitted GDR decision into an executable replacement for the next slow callback.”
  • Observation-independent plan: A plan whose actions are prepared without requiring new observations between each step. “Executable skills, observation-independent plans and compiled tool dependencies reuse or schedule prior computation”
  • Policy-level constraint: A restriction applied to the behavior of an entire execution policy rather than to an individual prediction or action. “This is a policy-level constraint, assessed by evaluating both harnesses on the same tasks.”
  • Public state: Information available to the controller from the task request, tool feedback, and completed actions. “We use sts_t for public state at transition tt: the request, observed tool feedback and completed action history.”
  • Receipt-bound certificate: A verification record linking an executed action and its result to the callback that it replaced. “CCS substitutes native execution for registered callbacks and verifies omission with receipt-bound certificates.”
  • Recursive self-improvement (RSI): An iterative process in which an improved system generates feedback used to improve a subsequent version of itself. “RSI iteratively refines companion harness configurations from training feedback”
  • Semantic uncertainty: Uncertainty about what action should be taken or what its arguments should mean, rather than uncertainty about whether execution is currently permitted. “The example separates semantic uncertainty from execution uncertainty”
  • Selector: A component that chooses an eligible stored decision or declines to select one. “A Jev-motivated typed selector returns an eligible candidate ID or abstains”
  • Substitution Paradox: The situation in which adding a fast decision mechanism fails to reduce total computation because it does not eliminate the original reasoning work. “We call this accounting mismatch the Substitution Paradox”
  • Tool transition: A step in an agent execution in which control moves from one tool result or action to the next decision. “HarnessMM changes the route from tool feedback to the next native action.”
  • Typed selector: A selector constrained to return outputs from a predefined type or schema, such as a candidate identifier or abstention. “Our Jev-motivated typed selector uses a candidate-ID/abstention interface”
  • Unroll: The process of expanding an execution into the sequence or graph of nodes that may be invoked. “For task xx, unroll a finite execution under the benchmark limits into a computation graph”

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Tweets

Sign up for free to view the 7 tweets with 710 likes about this paper.