MemoHarness: How Agents Evolve Beyond Model Parameters
MemoHarness expands the notion of self‑evolving agents by keeping the language model frozen while continuously adapting the external control system—context assembly, tool interaction, generation settings, workflow orchestration, memory management, and output validation—demonstrating measurable gains on terminal, code‑generation, and finance tasks, yet highlighting limited scalability and transferability.
Background and Motivation
When people discuss “self‑evolving agents,” they usually focus on changes inside the model—self‑reflection, continued training, or reinforcement‑learning updates. MemoHarness proposes a different route: the model itself stays unchanged, while the surrounding control system that decides context, tool calls, step orchestration, memory handling, and result verification is continuously refined.
Agent Harness Architecture
The paper calls this external system the Agent Harness and decomposes it into six editable dimensions (D1–D6):
D1 Context Assembly : construct the input before invoking the model, including prompts, constraints, retrieved materials, and examples.
D2 Tool Interaction : decide when and how many external tools or retrieval results to use and whether to re‑rank evidence.
D3 Generation Control : adjust generation parameters such as max tokens, temperature, and sampling strategy.
D4 Task Orchestration : choose between a single call or a multi‑stage “plan‑execute‑revise” workflow.
D5 Memory Management : retain key state across calls, summarize trajectories, and discard stale context.
D6 Output Processing : extract answers, verify format, and apply fallback strategies on failure.
This six‑dimensional control space makes every modification explicit, versionable, and testable.
Learning from Execution Traces
MemoHarness records, for each task, the task features, current Harness configuration, delta from the previous configuration, full model‑tool trace, result score, token consumption, and diagnosed failure mode. These per‑case records form an experience library. Periodically, the system abstracts global patterns from many cases, identifying which strategies succeed, which fail, and how the six dimensions interact.
Two‑Phase Optimization Process
During the training‑time optimization phase, the system searches over Harness configurations on tasks with reference answers, keeping the base model frozen. Scoring prioritizes correctness first, using token cost only as a tie‑breaker. The best configuration per task is stored in the experience library.
In the testing phase , for a new unlabeled task, the system retrieves similar cases, applies the learned global Harness, and adapts it to the specific task in a single adaptation step—no further label feedback or iterative search.
Experimental Evaluation
The authors evaluated MemoHarness on three benchmark suites:
Terminal‑Bench (long‑horizon terminal operations): score improved from 0.722 to 0.806.
LiveCodeBench (single‑shot code generation): score improved from 0.900 to 0.967.
FinanceAgent (multi‑step tool‑heavy financial analysis): score improved from 0.600 to 0.767.
Improvements were larger on tasks that require extensive tool use and multi‑stage reasoning, suggesting Harness optimization benefits complex, tool‑intensive workloads.
Cross‑task transfer showed selective gains: the optimized Harness helped on MMMLU, StrongReject, and SWE‑Bench Pro, but not on HumanEvalFix, Reasoning‑Gym‑Easy, or consistently on LawBench. Cross‑model transfer (applying a Harness found with GPT‑5.3‑Codex to six other models) yielded an average success‑rate increase of 0.098, ranging from 0.038 to 0.233.
Cost analysis on Terminal‑Bench reported a total of 14.18 M input tokens (13.32 M cached) costing $6.89 under public pricing—cheaper than Codex and Claude Code but more expensive than OpenCode, with the advantage hinging on high cache reuse.
Limitations and Open Questions
The paper acknowledges several constraints: the evaluation used point estimates without confidence intervals; baselines sometimes employed different models or tool interfaces, preventing strict ablations; the experience library and global rules were not fully ablated per task; and the cost advantage depends on cache hit rates that may not hold in production.
Furthermore, the current system does not continuously ingest new experience after deployment—each test task receives a one‑time case‑specific adaptation, and the result is not fed back for further online learning. The authors list “online continual experience accumulation” as future work.
Implications for Practice
MemoHarness shifts the focus of agent improvement from model weight updates to external system engineering. Because each Harness change is versioned, enterprises can compare success rates, costs, latency, and error types across releases, roll back regressions, and disable risky components individually.
In the long run, organizations may accumulate proprietary experience assets—rules about when to increase retrieval depth, which tool combinations tend to fail, how to prune context, and what validation checks are necessary—stored outside the model. This suggests that competitive advantage may stem more from a well‑engineered, evolvable Harness than from a marginally larger LLM.
Agent evolution may no longer be limited to the model; the surrounding “operating system” can evolve independently.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
DataFunSummit
Official account of the DataFun community, dedicated to sharing big data and AI industry summit news and speaker talks, with regular downloadable resource packs.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
