Breaking Down DeepSeek's Super-agent Architecture: How Router+Worker Solves the Multi-Session Management Bottleneck

When you can run five AI sessions simultaneously to fix bugs, write documentation, and do code reviews, your productivity seems like it should double. But the reality is usually this: you become the person frantically racing between sessions—switching windows, checking progress, adding instructions, handling exceptions, and even forgetting what you were supposed to do next. According to a Bilibili creator's analysis of DeepSeek^Ad team's latest Super-agent paper, this predicament of "humans busy managing models" is exactly the starting point for DeepSeek's new architecture: as model execution capabilities keep growing, human attention, context switching, and task supervision have become the new bottleneck.

The Sweetness and Burden of Multi-Session Parallelism

In the video, the creator reconstructs a typical scenario: early on, we only opened one session and asked AI to modify code or solve problems; as model capabilities strengthened, we began running multiple sessions in parallel—one fixing bugs, one writing documentation, one doing code review. On the surface, productivity improved, but problems quickly emerged: you need to constantly switch sessions to check task progress, add instructions, handle exceptions, and even forget what each Agent is doing because there are too many tasks.

Behind this are the limitations of two traditional approaches. Cramming all tasks into the same Session keeps context continuous and cache reusable, but information from different tasks gets mixed together, task focus declines, and performance suffers; moreover, under synchronous ReAct mode, new instructions interrupt tasks that are already executing. Conversely, opening independent sessions for each task allows parallelism without cross-contamination, but traps people in more frequent switching and management burdens, and cross-session information is hard to share.

DeepSeek's answer is a Router + Worker two-tier architecture: the Router is a long-running Agent session responsible for interacting with users, understanding new tasks, determining ownership, and coordinating globally; Workers handle concrete task execution, each with independent context and tools, and do not interact directly with users. Users only face the Router, and tasks are dispatched to different Workers for parallel progress.

Engineering Mechanisms of the Two-Tier Architecture: Fast Pass, Slow Pass, and Chain of Recall

The architecture diagram reveals how messages flow efficiently. After external events enter the system, they first pass through a rule-based filtering layer that splits them into two paths: Fast Pass and Slow Pass. Taking the PR scenario as an example: when a Worker subscribes to a PR, subsequent commit or review messages for that PR are delivered directly to the corresponding Worker through an internally maintained subscription table—completely bypassing the Router. This is the Fast Pass, avoiding unnecessary routing overhead.

New tasks or unfamiliar messages not in the subscription table go through the Slow Pass, where the model performs semantic analysis (RM) to judge: irrelevant messages are discarded directly, and only tasks that need handling are handed to the Router to dispatch a new Worker. Data shown by the creator indicates that routing through the Router brings about 37% extra cache overhead compared to direct code delivery, mainly because the Router, as a model, needs to read context cache and perform a new round of inference; but since the Router is designed to be lightweight and the model itself responds quickly, the actual speed difference is not significant.

For context organization, DeepSeek proposes two strategies: inline and spell. Inline places the most relevant information directly into context, such as the current comments, task goals, and recent discussions when a Worker processes a PR; spell stores complete information that is temporarily unused in external storage and retrieves references when needed.

More critical is Chain of Recall. The creator gives an example: a few days ago someone reported a bug in a group chat, and a Worker analyzed it; a few days later the user privately messages the Router asking "how's that login issue from last time?" How does the Router know which task is being referred to? Chain of Recall saves previous subscription relationships and dependency associations between Workers; when a new message appears, it judges through dependencies whether it has been handled before, and if so, directly recalls it and sends it to the corresponding Worker.

In addition, the system also designs full-duplex Router communication, reply strategies based on task type (concise in group chats, detailed in PRs), and a watchdog mechanism to monitor whether Workers are progressing healthily rather than falling into infinite loops.

ReAct mode (Reasoning + Acting) is the mainstream paradigm in current Agent design, proposed by Shunyu Yao et al. in 2022. It lets the model alternate through a loop of "reason—act—observe": first output thoughts (Thought), then decide which tool to call (Action), and after receiving the tool's return result (Observation), continue to the next round of reasoning. The advantage of this mode lies in interpretability and dynamic error correction, but the cost is that each step requires the model to fully read the context and generate output—the so-called "synchronous ReAct"—where subsequent instructions cannot be inserted before a tool call returns. When multiple tasks share the same ReAct session, new messages can only queue or interrupt the current loop, which is the fundamental reason why cramming all tasks into a single Session loses focus and responsiveness. The Router+Worker architecture essentially adds a scheduling layer on top of the ReAct loop, splitting long loops into independent Workers for parallel execution, thereby bypassing synchronous blocking.

Context Cache is the key to understanding the 37% extra overhead. During large model inference, if the attention of the entire prefix is recomputed on every request, the cost grows linearly or even quadratically with context length. Mainstream inference frameworks (such as vLLM's PagedAttention and DeepSeek's own context hard-disk cache) retain the KV Cache of tokens already processed, and when subsequent requests hit the same prefix, they directly reuse it and only compute the new part. The Router, as a model, needs to read and reuse the context cache already established by Workers, which amounts to an extra "read cache + re-inference" step, and this extra computation manifests as about 37% cache overhead. However, because the Router's context is usually shorter and the model responds quickly with a high cache hit rate, the end-to-end latency difference is diluted and users do not perceive it clearly.

Separation of Compute and Execution Environments: Cloud Persistence and Multi-Device Nodes

Traditional local Agents put the model running loop, state, and execution environment on the same machine, and they stop when the machine shuts down. DeepSeek's solution runs the Agent loop in the cloud, persists state and tasks in a database, and the actual environment for executing commands can be the cloud, a phone, a Mac, or Windows—as long as the corresponding node runs on the device. The creator uses the locally running GorgBot as an example: sending a message to GorgBot on a phone, it can control execution nodes running on Windows and Mac to handle local tasks. This separation of storage and compute also makes fault recovery possible: after interruption, the stuck point can be found from storage and progress continued.

Separation of storage and compute is borrowed from distributed systems and cloud computing architecture; it originally meant decoupling the data storage layer from the compute layer so that the two can scale independently and isolate faults. In the Agent context, "compute" is the model inference loop and tool-calling logic, and "storage" is task state, conversation history, subscription relationships, and intermediate execution results. Traditional local Agents couple the two in the same process or even the same machine; a process crash or device shutdown means task loss, and the task cannot be taken over from another device. After separation, the Agent loop runs in a cloud-resident service, state is written to a database, and execution nodes (phone, Mac, Windows) only handle concrete command execution and file operations, communicating with the cloud through a node protocol. In this way, any execution node going offline does not affect the task itself; the cloud can reschedule to another node or wait for reconnection, enabling resume-from-breakpoint and cross-device handoff.

Not an Entirely New Paradigm: Comparison with Existing Practices

The creator candidly points out that Super-agent is not a brand-new paradigm proposed from scratch. He shows his own open-source project Hive from April this year, as well as the locally running GorgBot, whose architectures are highly similar: a "chief steward"-style Router managing multiple Workers, even with an architecture observer for self-checking and depositing data to GitHub. He further suggests that in Codex or ChatGPT one can also define rules for sessions to message each other, simulating a Router-Worker architecture. The DeepSeek paper itself also acknowledges that the underlying mechanisms draw heavily on software engineering and distributed systems ideas.

The Architecture Alleviates Entry-Point Chaos, but the Human Attention Bottleneck Remains

This is the creator's most valuable independent judgment. DeepSeek starts from the premise of limited human attention, but Router+Worker merely delegates more session management responsibility to the system—it does not fundamentally eliminate the human attention bottleneck. When one person manages five projects simultaneously and all messages converge into one Router, the person still needs to understand each project's background, handle tasks, and make decisions separately; if all project messages are crammed into the same chat stream, it may instead create new interaction chaos—handling the first task and then scrolling back to find the second only makes things messier. He personally prefers assigning specialized tasks to specialized Bots for greater clarity.

Equally worth guarding against is the assumption that "ten times more Agents means ten times more productivity." Improved capability of a single Agent does not necessarily translate into improved effective system output: tasks have dependencies, conflicts, shared state, and coordination costs; even if an Agent completes tasks quickly, humans still need to judge whether the task is valuable. The creator shares his own feeling: busy every day, Agents running constantly, yet looking back he feels there are not many results, and it has squeezed out time for deep learning and thinking. What truly deserves optimization is not just how smart Agents are, but how to continuously convert this intelligence into effective output at reasonable compute cost and human attention cost.

Editorial View

DeepSeek's Super-agent architecture is solid engineering: the Fast Pass/Slow Pass routing tiers, the memory association of Chain of Recall, and the persistence of storage-compute separation are all targeted designs for the pain points of multi-session management. But it is more a systematic integration than a paradigm revolution. For developers, the real lesson may be: architecture is only a means; when the number of Agents swells, how humans maintain a sense of control over tasks and value judgment is the harder proposition.

One-line Summary

DeepSeek uses a Router+Worker two-tier architecture to manage multiple sessions, alleviating entry-point chaos but not solving the attention bottleneck.

Paragraph Summary

Based on a Bilibili creator's analysis of DeepSeek's Super-agent paper, the article dissects the pain point of people frantically switching and managing multiple parallel sessions. DeepSeek proposes a Router+Worker two-tier architecture: users interact only with the long-running Router, while concrete tasks are executed in parallel by Workers with independent contexts. In terms of engineering mechanisms, Fast Pass uses a subscription table to let related messages bypass the Router and go directly to Workers, Slow Pass uses semantic analysis to filter and route, and routing delivery brings about 37% extra cache overhead but little speed impact; Chain of Recall saves subscription and dependency relationships to recall historical tasks; storage-compute separation runs the Agent loop in the cloud while execution environments are distributed across multi-device nodes and support fault recovery. The creator points out that this architecture is not an entirely new paradigm, and it only delegates management responsibility to the system without eradicating the human attention bottleneck; growth in the number of Agents does not necessarily bring improved effective output.