DeepSeek Proposes Super-agent Architecture for Parallel and Persistent Autonomy

IT Home reported on October 31 that the official DeepSeek Harness team today published an article titled "Super-agent Design Exploration: Towards More Autonomous Agent Systems," outlining their architectural design philosophy for Super-agents aimed at engineering practices.

As large models increasingly require less human intervention to execute individual tasks, the bottleneck limiting further productivity gains is shifting toward human attention. Agent systems need to evolve from passive, single-task tools that respond to instructions into autonomous collaborators that remain continuously online and can handle multiple tasks in parallel.

DeepSeek noted that mainstream Agent designs still use a single Session as the basic unit, with different Sessions remaining independent of one another. When users work on multiple tasks in parallel, they must manually switch between and maintain the context of each Session.

According to observations by the DeepSeek team, a person can typically track only 3 to 5 active Sessions simultaneously. Even when extending local Agents via CLI, MCP, or external connectors, issues such as synchronous blocking in single sessions, chaotic context across multiple tasks, and task cessation when local devices go offline persist.

They term this new form of Agent and its system architecture "Super-agent," identifying four fundamental characteristics: continuity, efficiency, proactivity, and persistence.

First, continuity means users can interact with the same Agent across different channels, such as instant messaging and GitHub comments. Efficiency implies the ability to process multiple complex tasks in parallel. Proactivity means the system can continuously observe environmental events and autonomously advance matters worth handling. Persistence requires the Agent to remain always online and capable of recovering from abnormal states during long-term operation.

▲ The same task progresses continuously between IM group chats and GitHub Pull Request reviews.

▲ Continuously monitoring public group chats, proactively identifying defects without being @-mentioned, and submitting fix Pull Requests.

The overall architecture proposed by DeepSeek consists of five main components: dual-layer architecture, event-driven mechanism, human-centric interaction, separation of computation/state/environment, and Watchdog.

Specifically, the dual-layer architecture divides the system into a Router layer and a Worker layer. The Router is responsible for handling human interactions, maintaining global context, and dispatching tasks. Workers execute specific jobs concurrently within isolated sessions. Workers do not reply directly to users; instead, they report status and results to the Router, which handles all external communication uniformly.

▲ Dual-layer architecture: The Router layer unifies routing and external interaction, while multiple Worker Sessions execute tasks concurrently in isolation.

In the event-driven mechanism, external information such as group chat messages, email and calendar reminders, code review comments, and CI run results are referred to as Triggers. The system first filters events using programmatic rules, then passes them to the large model to determine if action is required. For event streams assigned to tasks, Workers can subscribe to the corresponding Thread. Subsequent related events are sent directly to the Worker by the program, bypassing the Router each time, thereby reducing routing load.

The DeepSeek team also introduced the Inline & Spill and Chain of Recall mechanisms. The former places recently relevant information directly into the model's context window, while content exceeding the budget or used infrequently is kept outside the window for the model to read on demand. The latter leverages reference relationships between objects such as Triggers, Threads, and Worker Sessions, allowing the model to gradually retrieve historical task information along associated IDs.

▲ Overall system architecture of the Super-agent.

To reduce human wait times, the Super-agent introduces a speculative execution mechanism, allowing it to begin work in the background based on environmental signals. For example, upon receiving a meeting invitation, it might check schedule conflicts, gather background materials, and prepare a draft response. In R&D collaboration scenarios, it might attempt to reproduce faults and search for fixes while issues are discussed in group chats, delivering results to the user only after confirming the problem and finding a simple fix.

Regarding human-machine interaction, the article proposes an asynchronous ReAct Loop, converting time-consuming tool calls into asynchronous start() and stop() operations. Once the Agent launches a background task, it returns a "Started" status immediately without waiting for completion. Background results subsequently enter the session as new events.

This allows the foreground conversation to continue accepting new user messages. However, the DS team specifically noted that this asynchronous task mechanism has been implemented in DeepSeek Harness but is not enabled by default.

▲ Two-stage filtering: First, the program-layer policy filters out most irrelevant messages; then, the semantic-layer policy makes the final judgment.

To support long-term online operation, DeepSeek decouples computation, session state, and execution environment within the Agent Loop. Computation and persistent state are hosted in the cloud, while the execution environment can remain on the user's local device, deploying only a lightweight daemon responsible for executing commands and returning results. This design supports BYOM (Bring Your Own Machine), allowing users to connect their daily development machines or personal computers to the cloud-based Agent. It also supports connections to cloud-hosted machines or on-demand created computing environments.

Additionally, the system establishes an independent Watchdog Session outside the main architecture, forming an external control loop. The Watchdog not only monitors infrastructure issues such as interface errors and state recovery failures but also uses models to determine whether Workers are making substantial progress and if their execution direction deviates from the goal. When anomalies are detected, it intervenes to fix them.

▲ Thread Example: Consecutive Triggers under the same IM topic or the same GitHub Pull Request constitute a single Thread.

The DeepSeek team also conducted preliminary experiments comparing the Super-agent, a Super-agent variant without the event pass-through mechanism, and two Single Session + Subagent configurations with different prompt settings.

Each experiment involved approximately 300 messages, of which about 20 were work requests. Each configuration was run five times. The results showed that the Super-agent achieved task completion times with p50 and p95 latencies of 12.4 minutes and 15.7 minutes, respectively. In contrast, the Single Session approach with neutral prompts had a p95 latency of 29.5 minutes.

The DeepSeek team noted that these experiments were based on synthetic loads and simplified environments, primarily evaluating the system's scheduling and collaboration capabilities rather than measuring the actual execution capability of individual tasks.

▲ Cumulative arrival curve of work requests and cumulative completion curves for four approaches (mean of 5 experimental runs; message intervals and work durations scaled by 1/4, model invocation times are real values).

In stress tests at the Router layer, when the Trigger arrival rate increased from approximately 1 per minute to about 40 per minute, the average batch size grew from 1.0 to 2.8, and the time per request increased from 2.5 seconds to 3.9 seconds. However, the inference time amortized per decision decreased from 6.4 seconds to 1.6 seconds. Based on this, the team concluded that during event bursts, the Router can improve effective throughput by merging backlogged events.

▲ Each approach was repeated 5 times; task completion time refers to the duration from the work request to the result message.

The article also points out that this architecture still faces unresolved challenges, including how the Router layer scales with task volume, long-term memory across months or longer periods, human-AI collaboration methods after detaching from sessions, A2A communication between different Agent instances, and security and privacy protection. Particularly, when cloud Agents access local devices, risks such as prompt injection, endpoint credential leakage, and cross-device permission issues need further resolution.

▲ Batch size, time per request, and amortized inference time per decision for Router Sessions under different Trigger arrival rates.

The DeepSeek team stated that internal Super-agent instances built upon these concepts and the DeepSeek Harness have been running continuously, participating in issue reproduction and fixing, code review responses, and the iteration of the DeepSeek Harness itself.

Furthermore, they provided a prototype implementation named dsh-superagent-prototype in the article, explicitly noting that this plugin is intended for validating the technical roadmap and is not an official DeepSeek product.

References:

• GitHub repository for dsh-superagent: https://github.com/deepseek-ai/dsh-superagent-prototype