HarnessMM: Recursive Self-Improvement for Harness Token Efficiency
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.
Paper Prompts
Sign up for free to create and run prompts on this paper.
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:
- Think about what to do.
- Use a tool, such as a code editor or command line.
- Look at the tool’s result.
- Think again.
- 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:
- Write code to a file.
- Run a compiler.
- 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 , 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 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 , define capability regret .”
- 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 , actor emits the current tool action and an EDG ”
- 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 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 for public state at transition : 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 , unroll a finite execution under the benchmark limits into a computation graph”

