EMHO: EMbodied Agent Harness Optimization via Experience Traces
Abstract
Improving embodied agents often focuses on optimizing the underlying model through training, while the surrounding agent harness that controls planning, context, and tool use is typically engineered. We ask whether this harness can instead improve itself directly from experience traces under sparse environmental feedback. We propose EMbodied Agent Harness Optimization (EMHO), a self-evolving framework that keeps the embodied model frozen and iteratively revises its harness by analyzing execution trajectories and prior harness history. EMHO optimizes beyond skills or recovery prompts, modifying how the agent monitors progress, uses vision tools, grounds observations, and responds to failures. To support multiple subtasks with a single harness, we introduce EMHO-Merge, which addresses trade-offs in jointly optimizing a single shared harness across subtasks by using episode-level gains and losses to guide evidence-supported refinement of when and how revised behaviors are applied. We evaluate EMHO on EmbodiedBench across navigation and manipulation tasks, and EMHO consistently improves task success for both Qwen 9B and 27B models. Qualitative analysis shows that EMHO goes beyond recovering from failures and unproductive actions to reshape how the embodied agent interprets and interacts with its environment.
Community
We introduce EMHO, a framework that improves embodied agents by refining their instructions and code
from experience—while keeping model weights frozen. EMHO-Merge combines improvements across tasks, boosting navigation and manipulation performance on EmbodiedBench.
🔗 Project: https://hyunjung00.github.io/emho/
The harness is the highest-leverage code I own — it's the only part of the stack I can change without booking a training run, so optimizing it from traces aims at the right target. My problem is what actually lands in those traces. Environmental feedback is sparse and biased toward loud failures, so the harness learns mostly from the least representative slice of traffic: the calls that broke. A harness that gets excellent at recovering from logged failures can quietly regress on the 95% of calls that never errored, and you won't notice because nothing throws. I'd hold every harness diff against a frozen eval set with automatic rollback, and version the harness itself so I can run v7 and v3 on the same task and diff the trajectories. Without that it's drift with a changelog. Curious whether the trace collection here filters for success cases at all, or whether it's failure-weighted by construction.
Hi, thanks for the thoughtful question! We collect traces from all episodes in the search set, including both successful and unsuccessful runs. The sparse feedback refers to the limited diagnostic information provided by the environment, rather than collecting only failure cases.
During optimization, each candidate harness is evaluated on the search set and replaces its parent only if it achieves a strictly higher success rate. Otherwise, we retain the parent harness. Also, our qualitative analysis shows that the updates extend beyond failure recovery to vision-tool orchestration, progress monitoring, and visual grounding - changing how the agent perceives the environment and uses tools during ongoing interaction.
Get this paper in your agent:
hf papers read 2610.08432 Don't have the latest CLI?
curl -LsSf https://hf.co/cli/install.sh | bash Models citing this paper 0
No model linking this paper
Datasets citing this paper 0
No dataset linking this paper
Spaces citing this paper 0
No Space linking this paper
Collections including this paper 0
No Collection including this paper