DeepSeek Splits Agents into Router and Worker: The Multi-Task Bottleneck Is Not the Model, but People

The DeepSeek team published a very long technical article about a system they run internally called Super-agent. The core argument can be summed up in one sentence: the ceiling for a single task is model capability, while the ceiling for multiple tasks is human attention.

They observed a very concrete number: a person can keep up with at most 3 to 5 active Sessions at the same time. Beyond that, context starts bleeding across them. One commenter said that with three Sessions open at once, they pasted A's requirements into B. That limit feels very real.

Traditional Agents use the Session as the basic unit, and each Session is isolated from the others. When users push multiple pieces of work forward in parallel, they have to switch manually and remember each Session's context. DeepSeek's solution is to split work into two layers: the Router layer and the Worker layer.

The Router layer is always on and is only responsible for chatting with people, dispatching tasks, and maintaining global context. It does not directly execute tasks, and it may not even have a Bash tool. The Worker layer consists of multiple isolated Sessions; each Worker focuses on one task and has a full set of execution tools, but it does not interact directly with people—it only reports to the Router. All external replies go out through the Router as the single exit point.

What does this structure look like? Like a project manager leading a group of engineers. The project manager does not write code; they only break down tasks, track progress, and communicate externally. The engineers work in parallel in their own environments without interfering with one another. The article also mentions a detail: Workers usually do not need to communicate directly. Conflicts tend to arise in shared work environments, such as the same Pull Request. As long as Workers are all subscribed to the corresponding Thread, they receive the same event notifications and can discover and resolve conflicts on their own. A small amount of cross-task coordination is relayed through the Router.

Besides the two-layer architecture, the article also describes several supporting designs: event-driven operation, using two levels of filtering—programmatic policies plus model policies—to filter noise from the environment; full-duplex interaction, changing time-consuming tool calls into asynchronous start() and stop(), so the foreground can continue the conversation while background tasks run; separation of computation, state, and environment, with the Agent Loop running in the cloud and the execution environment staying local, connected through a lightweight daemon; plus an independent Watchdog that monitors whether a Worker has fallen into an ineffective loop or drifted from its goal.

The experimental data is also interesting. They drove four approaches with group chat and GitHub CI message streams, running each 5 times. For Super-agent, the p50 task completion time was 12.4 minutes and p95 was 15.7 minutes. By comparison, the group using a single Session plus a Subagent tool and neutral prompts had a p95 of 29.5 minutes. The gap is nearly twofold. The reason is not complicated: under the single-Session approach, the main session often decides to do the work itself, and as soon as a new message arrives it gets interrupted, making completion times long and unstable. The two-layer architecture solves this problem at the system level, without relying on prompt engineering or the model's on-the-spot judgment.

The most thought-provoking thing about this design is that it takes the Session out of the user's cognitive load. The article's exact point is that making users manually manage Sessions is largely a design inertia inherited from low-level LLM APIs. A Session should be an implementation detail of the system, not the user's unit of project management. That judgment makes sense. Most Agent products today have users open new conversations and remember context themselves, which essentially pushes work the system should do onto people.

Of course, the article also lists unsolved problems. For example, how to split the Router layer as scale grows, how to handle long-term memory, what product interaction looks like once it moves beyond Sessions, and security and privacy. The last point is especially important: when a cloud-based Agent Loop is connected to a large number of edge devices, a successful prompt injection could put all connected devices under control. Unless this problem is solved, Super-agent can only be used in small, trusted environments.

One commenter in the discussion mentioned a more hidden difficulty: when an employee says in IM, 'execute according to the usual standard,' the AI is stumped. What is the usual standard? It might have been agreed at some offline meeting, or it might be a company convention from long ago—something employees all know but that is not documented. These invisible constraints, team tacit understanding, and verbal commitments—the Agent does not know them. This may be a harder problem than architecture.

The prototype has already been open-sourced under the name dsh-superagent-prototype. The article explicitly says this is only a prototype to validate the technical direction, not an official DeepSeek product. But the direction is already clear: the Agent is no longer a chat window waiting for you to type commands, but an always-on collaborator that can push multiple things forward at once. As for what it ultimately looks like, that may depend on how product design hides the Session well.