Source: arXiv preprint — Du, Wang, Xu et al. — 2026-07-29
Summary
LLM agents can often recover from a mistake within a single task, but the same class of mistake tends to recur on the next task because whatever fixed it — a workaround, a clarified instruction — usually dies with that session. Living-Harness proposes a self-evolving agent harness that treats every completed trajectory, plus the evaluator's judgment of it, as evidence for a bounded update to the harness itself: its tools, its context, its workflow instructions. Guided by a domain-level "Evolution-SOP," it extracts an abstraction of what happened and writes that back as durable procedural knowledge, so the harness — not just the agent's short-term memory — actually improves over time.
Key Takeaways
- The distinction that matters: a static harness (fixed tools, fixed prompts, fixed workflow) can make an agent more reliable at launch, but it's frozen after deployment — Living-Harness keeps updating after deployment.
- The update is explicitly "bounded" — the harness doesn't rewrite itself wholesale after one bad trajectory, it accumulates evidence and applies constrained revisions, which is the difference between principled self-improvement and an agent flailing after every failure.
- It writes two distinct forms of procedural knowledge from each episode — meaning the system distinguishes between "what happened this one time" and "what should generally change going forward," which is a harder and more useful distinction than most self-improving-agent proposals attempt.
- This targets a real production pain point: the same tool-call mistake or misunderstood instruction recurring across sessions, which is one of the most common complaints about deployed agent systems today.
Reel Script
Hook (~17s, 38 words): Most AI agents forget every lesson the moment the conversation ends. The same bug, the same misunderstood instruction — it happens again next week, because nothing about the agent actually changed. A new paper fixes that.
Core Concept (~65s, 150 words): An agent's "harness" is everything around the model itself — the tools it's allowed to call, the instructions it's given, the workflow it follows step by step. Think of it as the employee handbook a new hire gets on day one. Most agent systems today write that handbook once and never touch it again, even after the agent screws up the same way five times. Living-Harness changes that: after every completed task, it looks at what happened and what an evaluator judged about the outcome, and treats that as evidence for a small, deliberate edit to the handbook — not a full rewrite, a bounded update. A domain-specific "Evolution-SOP" governs what counts as valid evidence, so the system doesn't overreact to one weird trajectory and doesn't ignore a pattern that keeps recurring.
Hands-On (~50s, 120 words): The loop worth sketching has four boxes in a circle. Box one: the agent runs a task, producing a trajectory. Box two: an evaluator scores that trajectory — did it succeed, where did it struggle. Box three: the system extracts an abstraction of the episode and checks it against the Evolution-SOP to decide if it's real signal or noise. Box four: if it's real signal, the harness itself — its tools, context, or instructions — gets a bounded update, and the loop starts again with the improved harness. The key arrow to draw thick is the one going from box four back into the next task — that's the part static harnesses don't have.
Takeaway (~22s, 48 words): This is the right direction for anyone running agents in production: stop treating the harness as a one-time setup step and start treating it as something that should evolve from real usage data. If your agent keeps making the same mistake, the fix belongs in the harness, not another prompt patch.