LongHorizon-Harness

What it is in one line

An open-source execution harness that lets agents operate a computer for hours without losing task state: it moves "where am I in the task" out of the conversation context, runs a Manage-Execute-Audit (MEA) three-role loop, executes each round in a fresh context, and only accepts facts an auditor verified from the environment — cutting off the "the agent wrongly believes it finished" error-propagation chain at the root.

Who built it

Open-sourced by AMAP-ML, the machine-learning team of AutoNavi (Alibaba's mapping arm); the paper is credited to the DreamX Team, Alibaba Group, first author Ziyu Ma. MIT license, code created 2026-08-04, with an arXiv paper (2608.01964). Lab research from a large Chinese tech company's mapping team.

Read: AutoNavi/Alibaba building this makes sense — mapping is a natural long-horizon agent domain (multi-step planning, cross-tool calls, environment feedback). It is a lab research project, not a startup.

What it actually does

• Manage-Execute-Audit loop → the Manager holds task state and dispatches subtasks (reads reports only, never touches the environment); the Executor runs a single subtask in a fresh context (the only role allowed to modify the environment; its traces and reasoning are discarded afterward); the Auditor uses read-only tools to independently check whether the environment meets acceptance criteria (it cannot see the Executor's reasoning or self-assessment, and touching protected state triggers an integrity violation)
• Fresh-context execution → each round the Executor starts from zero, receiving only the current subtask and audit evidence, preventing context rot
• Durable verified state → task state is written by the Auditor from the environment and marked completed / pending / blocked / untrusted, with evidence
• Reset without amnesia → execution errors stay inside their round, exposed by the next audit or never recorded
• Backend-independent → the three roles can each run on Claude Code, Codex CLI, Gemini CLI, mini-SWE-agent, or any other harness
• Usability → Python 3.10+, uv tool install lh-harness, CLI with a live dashboard

What old behavior it replaces

It replaces the default architecture of every current agent harness: stuffing execution traces, task state, and completion self-assessment into one growing context. That "lazy default" has three fatal problems — state becomes untrackable as the context grows, a model believing a step is done lets a wrong self-assessment pollute every later decision, and unbounded context inflates cost.

LongHorizon-Harness pulls "state" out of the context into an external object that updates only from environment-verified facts. It replaces not a tool but an orchestration paradigm.

Read: this is its biggest contribution to everyone building agents — the problem gets redefined as "task-state management," not "make the model smarter."

Business model

None. Pure open source (MIT) plus a paper; no hosted service, no charge.

Read: this is public research from a big-tech lab; the monetization path is not the code itself. If long-horizon agent capability validates internally, the payoff shows up in AutoNavi's own products.

Hard numbers

• 705 stars / 83 forks / 17 open issues, MIT, created 2026-08-04 (about ten days; 166 stars on day one)
• arXiv 2608.01964, submitted 2026-08-03; Hugging Face Daily Papers #2 on 2026-08-04 (131 likes)
• Benchmarks (same model and backend; harness swapped only):
  • WeaveBench (114 tasks): 51.8% → 80.7% (Qwen 3.7-Plus)
  • Terminal-Bench 2.1: 69.7% → 77.2%
  • OSWorld 2.0: 2.8% → 8.3% (3x)
  • OSWorld 2.0 subset (34 tasks, Claude Opus 4.7): 20.6% → 35.3%
• Cost: the Manager consumes only 2.0%–8.1% of tokens; auditing 19.4%–38.1%; on Terminal-Bench total tokens are 24% below baseline
• Team size, any commercialization plan: not disclosed

Four-way read

The call

This is the key infrastructure that moves agents from "can they do it" to "can they finish it reliably." Mainstream agent frameworks are betting on a single long context; LongHorizon-Harness shows that externalizing state and adding a read-only auditor improves long-horizon success across models and backends without touching either. If the result reproduces, it changes the default architecture of agent infrastructure.

The transferable pattern: add an "environment-facts-only" verification gate to any automation agent. When an Executor says "done," do not believe it; have an independent, read-only auditor that cannot see the Executor's self-assessment verify against the real environment. This is anti-hallucination made into engineering, far more reliable than "let the model self-reflect." Any long-flow agent can adopt this gate directly.

The limits are real: the method depends on the environment state being independently readable and verifiable — terminals, OS, and web with observable echoes qualify; open-ended creation and fuzzy requirements have no ground truth to audit. Every round adds one more audit call, raising latency and token cost. The Manager itself may become the next long-horizon bottleneck. And the benchmarks all skew toward verifiable scenarios; generalization evidence is still thin.

What to watch next

① Whether stars break 3,000 in three months — whether "long-horizon harness" as an infrastructure category gets adopted ② Whether a non-academic team publicly reproduces the benchmarks (real business workloads, not benchmark suites) ③ Whether an enterprise hosted tier or official integration with mainstream agent frameworks appears — the signal of moving from paper to product

What you can take from it

Architecture logic: for any long-flow agent team, the first move is to extract "task progress / subtask completion" into structured external state (a database, state machine, or todo list) instead of expecting the model to recall it from tens of thousands of context tokens. Externalizing state is the precondition for everything else.

Execution strategy: give the executor a fresh context per step, feeding only the current subtask plus necessary evidence. Swap "one giant context" for "short context + external state" and noise accumulation drops sharply.

Adapter layer: connect different models and harnesses through a thin adapter without touching their native loops — decouple orchestration from execution backend instead of rewriting the whole pipeline for each new model.

Verdict

Worth watching. The direction is right, the evidence is solid (consistent gains across models and domains), and it comes from a team with a real use case. But it is a research project, not a product; generalization and the cost ledger need real-business validation. Write it down and check against the three items above in three months.