Source-linked AI summary

OneDayAgent: Towards a Long-Horizon Harness for Autonomous Agents

Jingsheng Zheng, Xinyuan Fang, Jintian Zhang, Zhengke Gui, Huajun Chen, Ningyu Zhang

arXiv:2608.05013v1cs.CLcs.AIcs.HCcs.LGcs.MA

TL;DR

Long-horizon everyday agent tasks require preserving goals and intermediate state across many steps, tools, environments, and attachments, but joint management across backends remains less studied. OneDayAgent combines task decomposition, execution memory, and deliverable verification and repair; on 104 AgentIF-OneDay tasks, it achieves a 0.821 overall score with GLM-5.2 and runs across five backends from three model families.

  • Problem

    Whether one harness can jointly manage long-horizon agents’ goals, state, and context while remaining effective across backends remains less studied.

  • Method

    OneDayAgent decomposes requests into bounded subtasks, maintains execution memory under context pressure, and verifies and repairs final deliverables.

  • Results

    Across 104 AgentIF-OneDay tasks, GLM-5.2 achieves a 0.821 overall score, while the unchanged harness runs across five backends from three model families.

  • Takeaways & Limitations

    The findings support one harness jointly managing decomposition, memory, and verification across backends without backend-specific tailoring.

  • Takeaways & Limitations

    A paired comparison reports Gemini-3.1-Pro-Preview scoring 3.12 percentage points lower than Gemini-3-Pro-Preview under the same parameter settings.

Abstract

from arXiv · show

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.

1 Introduction

OneDayAgent is introduced as a long-horizon harness for open-ended everyday tasks that jointly manages decomposition, execution memory, and deliverable verification. Experiments on AgentIF-OneDay report a new state of the art with an overall score of 0.821 and stable cross-backend generalization.

  • Motivation: Open-ended everyday agent requests increasingly span work, study, and life, requiring web evidence collection, local-file editing, and deliverable production.These tasks are long-horizon, cross-environment, and multimodal.
  • Evaluation and contributions: 0.821 is OneDayAgent’s overall score on AgentIF-OneDay, establishing a new state of the art.The paper also reports stable cross-backend generalization and releases the harness and trajectories.
  • Motivation: Longer horizons create context accumulation, goal drift, and intermediate-state transfer failures across environments.An agent may lose earlier formatting constraints or previously gathered search evidence before completing a later editing step.
  • OneDayAgent: OneDayAgent decomposes requests into bounded subtasks, uses execution memory to compress observations and checkpoints, and verifies and repairs deliverables against original intent.The capabilities operate over a unified action space covering web and computation.

2 OneDayAgent

OneDayAgent is a long-horizon execution harness for open-ended everyday tasks spanning multiple steps, environments, and modalities. It manages these tasks through decomposition, execution memory, unified tool interaction, and final verification with targeted repair.

  • End-to-end workflow: OneDayAgent converts an everyday request into a managed execution process with explicit decomposition, memory, and verification stages.The workflow begins with the user request and its attached files, images, or other task-context materials, then verifies the final result before delivery.
  • Task decomposition: Task decomposition turns overloaded long-horizon requests into ordered, bounded, executable subtasks.This structure addresses requests that combine implicit requirements and artifact-level constraints, which are difficult to manage in a single uninterrupted executor trajectory.
  • Verification and repair: Global verification checks whether the synthesized deliverable remains aligned with the original intent, including early constraints and implicit requirements.Completing every subtask may still yield a locally plausible but globally incomplete artifact, so verification occurs after synthesis.
  • Verification and repair: Targeted repair uses verifier-identified defects to update only missing or inconsistent parts of the deliverable instead of restarting all subtasks.The repair stage converts verification failures into localized ReAct-style execution updates.
  • Execution memory: Execution memory preserves task-relevant intermediate state under context pressure through summarized observations, compact subtask checkpoints, and automatic context compression.These mechanisms retain reusable evidence, result-file handles, original task instructions, and recent actions while discarding low-level traces or noisy observations.

3 Experiments

Experiments on the 104-task AgentIF-OneDay benchmark show that OneDayAgent achieves state-of-the-art performance, supports decomposition, verification, repair, and context management, and transfers across heterogeneous backend LLMs. Ablations and execution analyses reveal tradeoffs between score, cost, and module composition, while backend choice produces distinct execution styles under the same harness.

  • Main results: OneDayAgent with GLM-5.2 achieves the best overall score of 0.821, leading across task types, domains, rubric dimensions, and input-attachment settings.AgentIF-OneDay contains 104 tasks and 767 instance-level scoring points spanning work, study, and life scenarios.
  • Ablations: Enabling both decomposition and verification yields the best overall score, 0.821, versus 0.771 for DIRECT, 0.8039 for DECOMP, and 0.8044 for VERIFY.Execution memory remains enabled in every ablation because disabling it causes context overflow or state loss that prevents completion.
  • Execution behavior: Decomposition increases execution cost from 20.6 minutes and 17 tool calls for one-subtask tasks to 117.2 minutes and 156 tool calls for five-subtask tasks.Most tasks use two to four subtasks, while 16 of 104 tasks use one subtask.
  • Execution behavior: Verification passes on the first attempt for 95 of 104 tasks; 9 enter repair, 6 are recovered, and 3 still fail.Repair is concentrated in harder settings, especially iterative-refinement tasks, study-domain tasks, and long time-budget tasks.
  • Execution behavior: Context compression occurs in 35 of 104 tasks, yet compression count has near-zero correlation with score, indicating stable task quality under context pressure.The highest-pressure task accumulates roughly 350K context tokens across compression rounds.
  • Backend transferability: The unchanged harness transfers across five backend LLMs from three model families and vendors, with overall scores ranging from 0.613 to 0.821.Backend scale correlates imperfectly with performance, while execution profiles differ substantially; GLM-5.2 averages 53.6 minutes, 51.6 tool calls, and 585.7 KB context per task.

4 Related Work

Prior work frames general-purpose agents as tool-using systems that reason, act, react to feedback, and organize workflows across digital settings. Long-horizon research additionally emphasizes execution harnesses and benchmarks spanning cross-environment tasks and verifiable constraints.

  • General-purpose agents for everyday digital tasks: General-purpose agents extend language models to problem solving by reasoning about intent, invoking tools, and reacting to environment feedback.ReAct interleaves reasoning and acting, while Reflexion and Self-Refine add feedback-based revision.
  • Harnesses for long-horizon agent execution: Long-horizon agent reliability depends on both the backend model and its execution harness, motivating benchmarks across long-horizon and cross-environment settings.Examples include Tool Decathlon, LifeSim, AgencyBench, OdysseyArena, WeaveBench, Workspace-Bench, and Terminal-Bench, alongside benchmarks for verifiable constraints and interactive real-world workflows.

5 Conclusion

OneDayAgent is a long-horizon harness that manages open-ended requests through bounded decomposition, execution-memory maintenance, and final-deliverable verification and repair. On AgentIF-OneDay, it achieves an overall score of 0.821 with GLM-5.2 and runs stably across five backend LLMs from three model families without changes.

  • 5 Conclusion: OneDayAgent manages open-ended requests by decomposing tasks into bounded subtasks, maintaining execution memory under context pressure, and verifying and repairing final deliverables.The harness integrates these mechanisms into a single managed execution process.
  • 5 Conclusion: 0.821 overall score is achieved by the GLM-5.2 backend on AgentIF-OneDay, the benchmark’s best reported result.This result is reported for the overall score metric on AgentIF-OneDay.
  • 5 Conclusion: Five backend LLMs from three model families run stably with the same unchanged harness.The harness therefore operates across multiple backend model families without modification.

Appendix · A Tool Interface Details

The appendix details OneDayAgent’s concrete runtime tool interfaces, expanding the main text’s functional tool groups by environment role. It specifies each tool’s inputs, outputs, and workspace-state effects.

  • A Tool Interface Details: Table 5 expands the main text’s abstract tool groups into concrete runtime interfaces exposed to OneDayAgent.The interfaces are grouped by environment role.
  • A Tool Interface Details: Each listed tool includes its expected inputs.The appendix presents inputs as part of the concrete interface specification.
  • A Tool Interface Details: Each listed tool includes its observable outputs or workspace effects.The table records how tool use affects or exposes the workspace state.
  • A Tool Interface Details: The appendix describes the workspace state affected by each tool.This makes state changes an explicit part of the runtime interface description.
  • A Tool Interface Details: The appendix organizes OneDayAgent tools by environment role.This grouping provides the implementation-level structure for the interface inventory.
  • A Tool Interface Details: Table 5 provides implementation-level tool names alongside their interface behavior.The table complements the main text’s higher-level functional grouping.

B Harness Configuration Details

Table 6 documents the OneDayAgent harness configuration used in the reported experiments, covering execution, decomposition, memory, verification, and tool-service settings. Deployment-specific secrets, API keys, and local or machine-specific paths are omitted.

  • Configuration scope: The configuration covers execution, decomposition, memory, verification, and tool-service settings.These categories define the main components of the reported harness setup.
  • Configuration scope: Deployment-specific secrets, API keys, and local or machine-specific paths are omitted.The omissions apply to the configuration presented for the reported experiments.
  • Configuration scope: Table 6 specifies the OneDayAgent harness configuration used for the reported experiments.The table is the configuration reference for the reported experimental setup.

C Runtime Cost Details

Table 7 reports runtime service usage for the GLM-5.2 run, separating backend-LLM traffic from auxiliary service pathways. It provides token totals and per-task averages across the 104 evaluated tasks, excluding service-side failed requests when reported.

  • Service usage: Table 7 summarizes runtime service usage for the GLM-5.2 run.The reported traffic separates backend-LLM activity from auxiliary services invoked through different tool pathways.
  • Token accounting: Token totals are reported for model-service inputs and outputs using model-service dashboards.The table distinguishes input and output columns for the reported token traffic.
  • Aggregation: Per-task averages are computed over the 104 evaluated tasks, excluding service-side failed requests when reported.This averaging and exclusion rule defines how the runtime usage statistics are aggregated.

D Harness Prompt Templates

The harness prompt templates define a long-horizon agent operating across web, code, file, and multimodal environments. They require advance planning, step verification, failure recovery, and compliant file-generation outputs.

  • Template organization: Prompt files are stored under prompts/, while runtime-injected tool schemas are summarized separately in Appendix A.The templates include an example trajectory’s system prompt and the core task-level instructions used by the reported harness.
  • System prompt: The system prompt frames the agent as a long-horizon task-completion agent spanning web, code, file, and multimodal inputs and outputs.Tasks may require dozens of steps across search, browsing, Python execution, file manipulation, and visual content generation.
  • System prompt: The core instructions require the agent to plan before acting, verify each step, diagnose failures, and recover from them.These requirements are embedded in the system-level workflow guidance for multi-step tasks.
  • File-generation rules: Generated outputs must be physically written to the current working directory without subdirectories or absolute paths.The prompt names tools such as Python, write, and image generation as appropriate mechanisms for creating files.
  • File-generation rules: Final responses for file-producing tasks must list generated basenames inside <result_files> tags and briefly describe each file inside <answer> tags.The template provides an example containing one filename per line and a numbered description for each result file.

E Security Considerations

OneDayAgent currently executes commands and handles files, webpages, and images directly on the host without workspace isolation, creating security risks. Recommended safeguards include sandboxing, command controls, input sanitization, and compression-aware filtering.

  • Security considerations: The current implementation runs shell commands, reads and writes files, visits webpages, and processes images directly on the host without workspace isolation.Infrastructure constraints prevented deployment of a stable sandbox environment.
  • Security considerations: Untrusted webpages and downloaded documents may inject hidden instructions that cause unintended command execution or data exfiltration.Adversarial content can enter the agent’s context through external sources.
  • Security considerations: The execute_command tool permits arbitrary shell commands without an allowlist, enabling system-file changes, package installation, or unintended network requests.A compromised or confused agent could act beyond the intended task scope.
  • Security considerations: Prompt-injected directives that survive context compression may persist across later subtasks, verification, and repair, propagating adversarial behavior.Memory persistence extends the potential impact across the execution lifecycle.
  • Security considerations: Recommended mitigations include containerized workspaces, filesystem and network restrictions, command allowlists, approval for destructive operations, input sanitization, and compression-aware filtering.Filtering should flag potentially injected instructions before they enter long-term state.

F Judge Comparison

A paired re-scoring experiment shows that substituting Gemini-3.1-Pro-Preview for Gemini-3-Pro-Preview lowers OneDayAgent’s scores because the new judge applies stricter evaluation criteria. Consequently, scores reported under the new judge are conservative relative to the original-judge baseline.

  • Paired judge comparison: 80.39% versus 77.27%: replacing Gemini-3-Pro-Preview with Gemini-3.1-Pro-Preview reduced the March-run score by 3.12 percentage points.The comparison used the same March run and identical settings.
  • Judge behavior: Gemini-3.1-Pro-Preview is stricter, checking artifact existence, exact titles and labels, explicit reasoning traces, and rendered screenshots for missing content.The new judge also recognized partial successes more accurately in some cases.
  • Interpretation: The reported 0.821 overall score is conservative because Gemini-3.1-Pro-Preview scores lower than Gemini-3-Pro-Preview on the same evaluation.The score would likely increase if re-evaluated with the original judge.
Loading 2608.05013v1…