ReadingResearchRadarInvestment framework
Sign in / Sign up
← Back to reading
NewsMaterial4 min readDisconfirmAI Editorial

AgentScope 2.0: The Failure of Long-Horizon Agents Lies Not in Single Responses, but in the Lack of a Unified Mechanism for Tasks, Information, and Actions

The Alibaba Cloud AgentScope team argues that the forgetting, drift, and version confusion agents exhibit during sustained work cannot be solved by improving model capabilities alone; instead, a Harness layer must be introduced between the framework and runtime to provide pre-integrated mechanisms for task progression, information organization, and action control.

Verified 2026-11-11 14:54 GMT+8

In a recent technical positioning article, the AgentScope 2.0 team described a specific failure scenario: a model correctly understood a vulnerability advisory but upgraded the wrong dependency because it had not seen the project's constraints; it wrote a correct patch but forgot to test it after context compaction; or it completed its checks yet mistook the old code associated with a test report for the current version. The commonality among these issues is that every individual response was correct, but the entire task chain went astray. The team's judgment is that merely improving the quality of single responses cannot resolve this type of cross-step structural failure.

Based on this, they proposed an engineering-level distinction: the Framework provides abstractions such as models, tools, messages, and state, answering how to build; the Runtime provides infrastructure such as scheduling, persistence, and event delivery, answering how to run; and the Harness answers how to enable the model to work effectively throughout the entire task process. It is not a collection of components, but a set of mechanisms already working in coordination, including how to supply information to the model, advance tasks, call tools, save progress, and involve humans in execution.

The Harness's mechanisms are organized into three layers. The Task Layer addresses sustained progress: execution state is persisted via AgentState, the task list is updated by todo_write, and the model receives a projection of the current progress at each reasoning step, rather than re-inferring where it stands from hundreds of historical messages. Plan Mode turns the planning phase into enforceable constraints—upon entry, general modification tools are blocked, leaving only read-only tools and plan-collaboration tools available, and upon exit, the process moves to human confirmation. Sub-Agents provide context isolation, allowing dependency trees, long logs, and candidate proposals to be explored within subtasks, while the main Agent receives only conclusions and evidence references.

Sign in / Sign up
ReadingResearchRadarInvestment framework

The Information Layer addresses organization within a limited window. Tool-result offloading stores complete content in external files, retaining only compact representations and reference paths in the active context; history compaction preserves task goals, key decisions, unresolved issues, and continuation points, while retaining verbatim recent interactions. Both work in tandem with structured state—Todo items, permission modes, and verification summaries are projected anew from the current state, rather than relying on the model to summarize old conversations. Context construction is made an explicit pipeline, producing a Context Manifest that records source identifiers, content versions, budgets, and transformation information, making 'what the model sees' an inspectable engineering behavior.

The Action Layer addresses execution control and trustworthy feedback. A tool call expresses intent, but before actual execution, the system must validate parameters, bind identity, evaluate permissions, and obtain necessary human confirmation. The permission mechanism supports three modes: ALLOW, DENY, and ASK. Combined with Plan Mode, the task phase itself also influences which actions are executable. The Tool-In-Sandbox pattern decouples orchestration from execution: the service-side Harness initiates the tool call, the sandbox executes and returns results and artifacts, and the Harness continues reasoning and advancing the task. Execution feedback does not rely on guessing success from natural-language logs, but preserves structured facts—Shell directly provides exit codes and output truncation information.

The article uses a running example spanning all three layers: analyzing high-severity dependency vulnerabilities in a payment service, completing remediation and verification, and preparing change documentation pending approval, with the current authorization scope excluding production release. This example demonstrates how the three layers collaborate—the Task Layer distinguishes the goal (remediate vulnerabilities and prepare documentation), progress (integration tests are running), and verified facts (this patch passed tests for the specified version); the Information Layer offloads the scan report to an external file, retaining only the blocking issue list in the context; the Action Layer ensures that creating change documentation and releasing to production are two separate authorized business actions, with plan approval not automatically extending to release authorization.

However, it must be noted that this is a vendor's exposition of its own product architecture, not an independently verified result. The article explicitly acknowledges that existing execution observations and local deterministic checks do not mean the framework already performs automatic acceptance of the entire business task by default—the objects to check, acceptance criteria, and verifiers still require explicit specification by the caller, and a unified completion gate remains to be developed. The definition of Harness may also be viewed as a renaming of existing engineering practices: mechanisms such as state persistence, context management, and sandbox isolation have already been implemented individually by many teams building internal Agent systems. Its true incremental value depends on whether it can reduce the cost of duplicated development, which requires validation through actual deployment data.

Nevertheless, the hierarchical distinction proposed in the article has direct utility for practitioners: when an Agent errs in a long task, first determine which layer the problem lies in—is it unclear distinction of goals, progress, and evidence (Task Layer), were key facts lost to compression or old information not isolated (Information Layer), or does tool-reported success not equal the business object reaching its target state (Action Layer)? This diagnostic framework does not depend on a specific product, but is a structured description of a class of engineering problems.

Sources

  • alibabacloud.comAlibaba Cloud Community↗
Continue researching →