DeepSeek proposes Super-agent architecture: a two-tier design of Router and Worker

IT Home, October 31 news: The official DeepSeek Harness team today published the article "Super-agent Design Exploration: Toward a More Autonomous Agent System," introducing its Super-agent architecture design approach oriented toward engineering practice.

As large models increasingly require less human intervention when executing a single task, the factor limiting further productivity gains is gradually shifting to human attention, and Agent systems need to evolve from single-task tools that passively respond to instructions into autonomous collaborators that are continuously online and able to process multiple tasks in parallel.

DeepSeek stated that existing mainstream Agent designs still use a single Session as the basic unit, with different Sessions independent of one another. When users advance multiple workstreams in parallel, they need to manually switch between and maintain the context of each Session.

According to observations by the DeepSeek team, a person can usually only follow 3 to 5 active Sessions at the same time. Even when extending a local Agent through CLI, MCP, or external connectors, users may still face problems such as synchronous blocking within a single session, chaotic context across multiple tasks, and tasks stopping after the local device goes offline.

They call this new Agent form and its system architecture Super-agent, and summarize four basic characteristics: continuous, efficient, proactive, and persistent.

First, continuous means users can interact with the same Agent across different channels such as instant messaging and GitHub comments; efficient means it can process multiple complex tasks in parallel; proactive means the system can continuously observe environmental events and advance matters worth handling on its own; and persistent requires the Agent to be always online and able to recover from abnormal states during long-term operation.

▲ The same task advances continuously between an IM group chat and GitHub Pull Request review

▲ Continuously monitoring a public group chat, proactively identifying a defect and submitting a fix Pull Request without anyone @-mentioning it

The overall architecture proposed by DeepSeek mainly consists of five parts: a two-layer architecture, event-driven operation, human-oriented interaction, separation of computation and state from the environment, and a Watchdog.

Among these, the two-layer architecture divides the system into a Router layer and a Worker layer: the Router is responsible for receiving human interaction, maintaining global context, and dispatching tasks, while Workers execute specific work concurrently in mutually isolated sessions. Workers do not reply directly to users; instead, they report status and results to the Router, which handles external communication in a unified manner.

▲ Two-layer architecture: the Router layer is uniformly responsible for 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 is called a Trigger. The system first filters events through programmatic rules, then lets the large model determine whether action is needed. For event streams to which tasks have already been assigned, Workers can subscribe to the corresponding Thread, and subsequent related events are sent directly to the Worker by the program without passing through the Router each time, thereby reducing routing load.

The DeepSeek team also introduced the Inline & Spill and Chain of Recall mechanisms. The former places information likely to be used in the near term directly into the model's context window, while keeping content that exceeds the budget or is used infrequently outside the window for the model to read on demand; the latter uses reference relationships among objects such as Triggers, Threads, and Worker Sessions to let the model gradually recover historical task information along associated IDs.

▲ Overall system architecture of Super-agent

To reduce human waiting time, Super-agent also introduces a speculative execution mechanism, which can start work in the background in advance based on environmental signals. For example, after receiving a meeting invitation, it first checks for schedule conflicts, gathers background materials, and prepares a draft reply; in R&D collaboration scenarios, when a problem is discussed in a group chat, it can try to reproduce the failure and look for a fix, and only deliver results to the user after confirming the problem and finding a simple fix.

In terms of human-computer interaction, the article proposes an asynchronous ReAct Loop, changing time-consuming tool calls into asynchronous start () and stop (). After starting a background task, the Agent can return the Started state without waiting for the task to complete, and the background result then enters the session as a new event.

In this way, the foreground conversation can continue to receive new messages from the user. However, the DS team specifically notes that this asynchronous task mechanism has been implemented in DeepSeek Harness but is not yet enabled by default.

▲ Two-level filtering: most irrelevant messages are first screened out by program-layer policies, then judged by semantic-layer policies

For long-term online operation, DeepSeek decouples the Agent Loop's computation, session state, and execution environment: computation and persistent state are placed in the cloud, while the execution environment can remain on the user's local device, with only a lightweight daemon deployed to execute commands and return results. This design supports BYOM (Bring Your Own Machine), i.e., connecting the user's everyday development machine or personal computer to the cloud Agent, and also supports connecting to cloud-hosted machines or on-demand compute environments.

In addition, outside the main architecture, the system sets up an independent Watchdog Session, forming an external control loop. The Watchdog not only monitors infrastructure issues such as interface errors and state recovery failures, but also uses the model to judge whether the Worker is making substantive progress and whether the execution direction deviates from the goal, and intervenes to repair when anomalies are found.

The DeepSeek team also conducted preliminary experiments comparing Super-agent, a Super-agent with the event pass-through mechanism removed, and a single-Session plus Subagent scheme under two prompt configurations.

Each experiment contained about 300 messages, of which about 20 were work requests, and each scheme was run 5 times. The results show that Super-agent's task completion time p50 and p95 were 12.4 minutes and 15.7 minutes, respectively; the single-Session scheme under neutral prompts had a p95 of 29.5 minutes.

The DeepSeek team points out that these experiments are based on synthetic load and a simplified environment, mainly evaluating the system's scheduling and collaboration capabilities, and do not measure the actual execution capability of a single task.

▲ Cumulative arrival curve of work requests and cumulative completion curves of the four schemes (mean of 5 experimental runs; message intervals and work durations scaled by 1/4, model call latency is the real value)

In the Router-layer stress test, when the Trigger arrival rate increased from about 1 per minute to about 40 per minute, the average batch size increased from 1.0 to 2.8, the single-request latency increased from 2.5 seconds to 3.9 seconds, while the inference time amortized per decision dropped from 6.4 seconds to 1.6 seconds. The team therefore believes that during event bursts, the Router can improve effective throughput by merging backlogged events.

▲ Each scheme was run 5 times; task completion time refers to the time from work request to result message.

The article also points out that this architecture still has unresolved issues, including how the Router layer scales with task size, long-range memory spanning months or even longer time spans, human-machine collaboration methods after leaving the Session, A2A communication between different Agent instances, and security and privacy protection. In particular, after the cloud Agent connects to local devices, prompt injection, endpoint credential leakage, and cross-device permission risks all need further resolution.

▲ Router Session batch size, single-request latency, and amortized inference time per decision under different Trigger arrival rates

The DeepSeek team states that the internal Super-agent instance built on the above ideas and DeepSeek Harness has been running continuously, participating in problem reproduction and repair, code review responses, and iteration of DeepSeek Harness itself.

In addition, they also provide a prototype implementation named dsh-superagent-prototype in the article, but clearly state that this plugin is used to validate the technical approach and is not an official DeepSeek product.

"Special statement: The above content (including videos, pictures, or audio) is uploaded and published by users of "Dafeng Hao", a self-media platform under Phoenix Net. This platform only provides information storage space services.

Notice: The content above (including the videos, pictures and audios if any) is uploaded and posted by the user of Dafeng Hao, which is a social media platform and merely provides information storage space services."