DeepSeek Unveils Super-agent Architecture: Two-Tier Router and Worker Design

DeepSeek has made another move!

And this time, the team directly made public its underlying architecture approach for a Personal Agent.

You should know that many people had been waiting for DeepSeek to launch the rumored "dsh dot," but instead what arrived first was an architecture discussion aimed at engineering practice—

Super-agent: Toward a More Autonomous Agent System.

What does that mean? AI can, without anyone @-mentioning it or giving it instructions, discover bugs on its own, pinpoint the problem, and even proactively submit a fix PR.

It can even continuously monitor work group messages, collaborate across platforms, process multiple complex tasks in parallel, and even run online 24 hours a day.

The DeepSeek team also shared preliminary test results—

In a simulated multi-task environment, Super-agent's median task completion time was 12.4 minutes, with a 95th percentile of 15.7 minutes, outperforming the traditional single-session approach in the tests.

In the daily software development process, developers often run into a problem: we need to switch back and forth between different platforms!!

For example, first discuss the technical approach in an IM group chat, then submit code on GitHub, and then revise the implementation based on PR comments.

For traditional Coding Agents, these operations are often scattered across different sessions—

The DeepSeek team mentioned in the article that, based on their observations, a person can usually only follow 3 to 5 active Sessions at the same time.

This creates a problem: as models become increasingly capable of handling individual tasks, the efficiency of multi-task collaboration is increasingly constrained by human attention.

As luck would have it, this is exactly the problem Super-agent aims to solve.

In instances running inside the DeepSeek team, the same development task can continue from an IM group chat all the way to GitHub PR review.

For example, users first decide in the group to adopt Plan A, and then later request in a GitHub comment to change it to Plan B.

Super-agent can understand that these two messages belong to the same piece of work and adjust the subsequent execution direction accordingly.

What users face is always the same Agent, while the multiple underlying sessions are managed by the system itself—and it begins to participate in the work proactively.

A technique is also used here— Speculative Execution .

For example, when someone in the group discusses a Bug, Super-agent first starts reproducing it and looking for the cause. If it ultimately finds a simple and feasible fix, it hands the result to the user.

If no effective result is found, it can stay quiet to avoid disturbing anyone. The same idea can also be used for personal assistants.

This also corresponds to the four core characteristics DeepSeek proposed for Super-agent:

DeepSeek designed a two-layer architecture for this.

The upper layer is called Router, which can be understood as the dispatcher responsible for receiving messages and coordinating tasks; the lower layer is called Worker, which is a set of Agent sessions responsible for specific execution.

Specifically, the upper-layer Router acts as the chief dispatcher, responsible for receiving messages, assigning tasks, and maintaining global context.

The lower-layer Worker is responsible for specific execution, and multiple tasks can proceed simultaneously without interfering with each other.

When someone later proposes revisions, the message is handed directly to this Worker for processing, without having to go through the Router layer by layer.

In this way, old tasks have someone continuously following up, and new tasks can also be assigned promptly, allowing the entire system to operate more efficiently.

In addition to multi-task collaboration, enabling Super-agent to run autonomously over the long term also requires solving issues such as message filtering, task blocking, and exception recovery.

First, message filtering.

When an Agent is connected to platforms such as work groups, GitHub, and email at the same time, a large number of messages will continuously pour in, but only a few may actually need to be handled.

To this end, DeepSeek designed a two-level event filtering mechanism—

First, program rules filter out irrelevant messages, and then the large model determines whether the remaining events require action, reducing unnecessary Token consumption.

At the same time, Super-agent also introduced an asynchronous ReAct Loop.

When AI executes time-consuming tasks, it can still continue to respond to new instructions without waiting for the previous task to finish. This mechanism has been implemented in DeepSeek Harness but is not yet enabled by default.

As for 24-hour online operation, DeepSeek adopted the idea of separating computation, state, and execution environment.

The Agent's computation logic can run in the cloud, session state is stored independently, and the local device retains its original working environment. Even if the computer is temporarily offline, the cloud Agent can maintain task state and continue the related work after the device comes back online.

Furthermore, the team also introduced an independent Watchdog mechanism.

It is equivalent to an AI specifically responsible for supervising other Agents. It can detect program failures and also determine whether a task has fallen into an ineffective loop or deviated from its goal, and try to intervene and repair it.

The DeepSeek team also conducted a set of preliminary experiments—

They simulated a collaborative environment containing about 300 messages and 20 work requests, comparing Super-agent with the traditional single-Session plus Subagent approach, repeating the test 5 times for each configuration.

The results showed that Super-agent's median task completion time was 12.4 minutes, and its 95th percentile task completion time was 15.7 minutes.

Under neutral prompts, the traditional single-Session approach reached a 95th percentile task completion time of 29.5 minutes.

Of course, the efficiency improvement also comes with a certain Token overhead.

DeepSeek found that after canceling the direct event pass-through mechanism, the Router's number of decisions increased by about 30%, and cached Token reads increased by about 37%.

This also shows that reasonable event routing can effectively reduce system operating costs.

From this technical sharing, it can be seen that DeepSeek is exploring ways to further free Agents from the limitations of a single session and achieve continuous online operation, parallel execution, proactive response, and exception self-healing.

As AI gradually becomes able to complete complex tasks independently, how to enable it to advance multiple pieces of work stably over the long term is also becoming a new problem that Agent systems need to solve.