Paper Explained: LongHorizon-Harness — Long-Horizon Agent Tasks Are a State-Management Problem, Not an Execution Problem

Without touching the model at all, keeping task state outside execution and running a Manage-Execute-Audit loop dramatically improves long-horizon task performance — a walkthrough of Alibaba DreamX team's harness-design paper, from analogy to pseudocode.

LongHorizon-Harness: Advancing Long-Horizon Agents for Real-World Tasks

The intern who pulls an all-nighter, and the team with a ledger

Hand an AI agent a job that takes hours and a familiar pattern appears: a strong start, then a collapse near the end. The paper we cover here — LongHorizon-Harness, from Alibaba's DreamX team (arXiv:2608.01964) — makes a simple claim: the collapse is caused less by the model's intelligence than by how the work is organized. Without modifying the model at all, changing only the outer framework (the harness), it reports lifting the pass rate on the computer-use benchmark WeaveBench from 51.8% to 80.7% (§3.2).

Start with an analogy. A conventional agent is an intern pulling an all-nighter. Inside one ever-growing conversation (its context), it plans, works, takes notes, and decides for itself whether things are done. Tired, it declares "probably finished" and moves on — and one wrong assumption quietly becomes a premise for every later decision.

LongHorizon-Harness turns this into a team. A coordinator maintains the whiteboard (the task ledger), a worker starts each unit of work with a completely fresh head, and a read-only inspector checks the deliverables against the real thing. The worker's "I'm done" never goes straight onto the ledger. Only facts the inspector has verified against the environment itself get written down. That single rule is the heart of the paper.

Why long tasks fall apart

The paper organizes the difficulty of long-horizon execution into three problems (§1). First, compounding errors and goal drift: small early mistakes distort later decisions, and the trajectory slowly veers away from the original objective. Second, context rot: as the history grows, relevant information becomes harder to retrieve, and performance can degrade sharply once context utilization crosses a threshold. Third, task-state loss: agents fail to keep hold of "what the requirements are, what is already done, and what has been discovered" — their own current position.

On top of this, the paper points out two structural limitations that remain in existing harnesses like Claude Code and Codex CLI (§1): (i) task execution and task-state management live in the same ever-growing context, and (ii) execution and completion assessment are coupled, so an incorrect self-assessment can be recorded as state and become a premise for subsequent decisions. These harnesses already have planning features and subagents — and still break down on long tasks, the paper argues, precisely because these two couplings survive.

The reframing: make it a state-management problem

The paper's reformulation goes like this (§2.1). Long-horizon execution is not one long conversation; it is a sequence of independently audited state transitions. The task state lives outside execution as an explicit record, updated only with facts independently verified from the environment. Across rounds, only the task state and the audit reports persist; the worker's raw interaction history is discarded every round.

The MEA loop: Manage → Execute → Audit

The implementation of this principle is the Manage-Execute-Audit (MEA) loop. Writing $S_i$ for the task state at the start of round $i$ and $V_i$ for the accumulated audit reports, the manager's entire job fits in one equation (§2.2):

In plain words: looking only at the original task $\mathcal{T}$, the current ledger $S_i$, and the pile of verified reports $V_i$, the manager produces the updated ledger $S_{i+1}$, the next move $q_{i+1}$ (one of four: execute, done, blocked, or ask the user), and the next work order $c_{i+1}$. The manager cannot touch the environment at all — it sees no screen and runs no commands. It is a role that judges from ledger and evidence alone.