arxiv:2608.05013

OneDayAgent: Towards a Long-Horizon Harness for Autonomous Agents

Published on Aug 4

· Submitted by

Ningyu Zhang on Aug 6

ZJUNLP

Upvote

Authors:

Jingsheng Zheng ,

Ningyu Zhang

Abstract

LLM agents are increasingly applied to open-ended everyday requests that span work, study, and life. These tasks are long-horizon, cross-environment, and multimodal, forcing the agent to preserve goals and constraints across many steps while navigating heterogeneous tools and attachments. While prior work has addressed individual failure modes such as goals drift, states loss, and context overflow, whether a single harness can manage them jointly and remain effective across backends has received less study. We present OneDayAgent, a long-horizon harness for autonomous agents. OneDayAgent turns an open-ended request into a managed execution process that decomposes tasks into bounded subtasks, maintains execution memory under context pressure, and verifies and repairs the final deliverable. We evaluate OneDayAgent on AgentIF-OneDay across 104 tasks. With the GLM-5.2 backend, OneDayAgent sets a new state of the art with an overall score of 0.821. The same harness runs across five backend LLMs from three model families, indicating the harness generalizes across backends without tuning, even as different models induce distinct execution styles under the same workflow.

View arXiv page View PDF GitHub 9 Add to collection

Community

Ningyu

Paper author Paper submitter 1 day ago

One Prompt. One Day. One Agent. Turning open-ended requests into long-horizon execution.

O96a

1 day ago

What surprised me most about this one is that they're not proposing a new agent — they're proposing a harness that wraps existing agents and handles the boring stuff (goal persistence, context management, tool routing) so the agent doesn't have to. That's the right direction. Most long-horizon failures I've seen aren't reasoning failures, they're bookkeeping failures — the agent forgot what it was doing three steps ago or lost track of which file it was editing. A harness that externalizes that state management is basically admitting the agent's context window isn't the right place for it, which I think is true. I'd want to see how it handles the case where the harness itself becomes the bottleneck — if every tool call routes through a state manager, that's a new single point of failure. But the framing is honest: solve the infrastructure problem first, then layer intelligence on top.