AgentScope 2.0: Harness as the default entry point, separate orchestration and sandbox execution

1. The harness as the default entry point for complex tasks

An Alibaba Cloud Community article published on November 11, 2026 introduces the AgentScope 2.0 harness architecture, focusing on the Java implementation. A framework provides components such as models and tools. The harness also ties together how information reaches the model, tasks advance, tools are called, and progress is saved.

Earlier versions focused on repeated model decisions and tool calls, along with collaboration between agents. This version packages the workflows needed for long-running tasks into the default setup. Developers can use the harness directly or customize its components and execution process.

2. Separating server orchestration from isolated execution

In the Tool-In-Sandbox architecture, tools run in isolation. The service side handles the model decision and tool-call loop, model calls, and context assembly. Operations requiring isolation, such as file operations and command or code execution, run in a sandbox through tool interfaces. Results and artifacts return to the harness. Operators can centrally manage the harness and configure execution environments per user or session. They can also scale orchestration services and sandbox resources separately.

This architecture targets organizations offering agents as a service to multiple business teams. Platform teams provide shared state management, isolated environments, permissions, and observability. Business teams handle domain knowledge, tools, and result acceptance criteria. This can reduce duplicate implementations, but also concentrates responsibility for state, permissions, and execution environments in platform design.

3. Connecting tasks, information, and actions

The article describes the harness in three layers: tasks, information, and actions. The task layer handles planning, progress, and subagent collaboration. The information layer organizes material for the model and the workspace. The action layer checks tool execution permissions and feeds results back into the next decision.

Entering plan mode blocks ordinary modification tools, leaving read-only tools and tools allowed for planning and collaboration. For high-impact changes, the approach is to explore, plan, obtain human confirmation, and then execute. The following configures the harness in the original Java example.

HarnessAgent agent = HarnessAgent.builder()
        .name("remediation-agent")
        .model(model)
        .workspace(workspace)
        .enablePlanMode()
        .enableTaskList()
        .planFileDirectory("plans")
        .build();

In the article's example of fixing a dependency vulnerability in a payment service, the plan defines the scope of changes, and test results guide the next revision. Goals, current progress, and validation results are managed separately. This reduces the need to infer again what has been completed in a long conversation.

4. Designing business boundaries during adoption

The intended tasks span multiple steps, accumulate information, and require finding the next path during execution. The article says lightweight calls and workflow orchestration may suit short queries with fixed paths or structured information extraction.

For vulnerability remediation, the application defines acceptance criteria for the code version to inspect, tests, security checks, and submission documents. Execution boundaries can give the sandbox permissions to modify code and run tests, while treating production deployment as a separate business tool.

5. Adapting to the implementation language and runtime environment

The AgentScope public repository reviewed alongside the article documents the Python implementation and requires Python 3.11 or later. Beyond local environments, it supports containers, which run applications in isolation, and integration with external sandboxes. It also offers agent services that handle multiple users and sessions. It provides a Python adoption path separate from the Java introduction.

Enabling planning in the Java example does not itself start a task in plan mode. Applications requiring planning first must explicitly enter that mode. Automatic acceptance of business results is not provided by default either. Callers must configure what to inspect, the criteria, and the validation procedures.

AgentScope 2.0 moves beyond assembling agents by packaging long-running task workflows into a default harness, while requiring teams to clearly define business permissions and result acceptance criteria.