Deepseek Open-Sources Super Agent Architecture: Letting Agents Manage Agents

From the Multi-Session Dilemma to Super Agent

If you're a heavy Agent user, you've likely been through this scenario: several conversation windows open at once, each handling a different task, and every so often you have to switch back to check each Session's progress. After a meal or a meeting, you've forgotten which window is at which step. This mode, where a human acts as the "scheduler," is becoming the bottleneck for further unlocking Agent productivity.

According to Bilibili creator Lipsic's reading of a 10,000-word article from the Deepseek^Ad Harness team, the team proposed an architecture concept called Super Agent, whose core goal is precisely to free human attention from multi-Session management. This architecture has two main threads: first, the user faces only a single assistant, while the Agent manages the different Worker Agents; second, the Agent can proactively perceive environmental changes and trigger task execution.

Sounds like a rehash of Multi-Agent systems? In fact, Super Agent makes clearly different trade-offs in layering logic, trigger mechanisms, and memory design.

Coordination Layer and Execution Layer: The Division-of-Labor Philosophy of a Lightweight Router

The first layer of Super Agent's design is a two-tier structure of Router Agent + Worker Agent. The Router Agent is the entry point for direct user conversation and can be pulled into Feishu groups, connected to GitHub code repositories, or bound to email. User input, group discussions, and code repository changes all trigger the Router Agent, which decides which Worker Agents the task should be assigned to, then launches the Workers to do the work. After a Worker finishes, it packages the results and sends them back; the Router summarizes and presents them to the user.

The key difference from traditional Multi-Agent systems is this: past solutions often required an extremely capable Manager Agent to oversee sub-agents, meaning the strongest large model had to be used; in the Super Agent concept, the Router Agent only bears coordination and communication responsibilities, making it a lightweight entry point that can use a "lighter" model.

This raises a natural question: the Router must both understand user intent and keenly capture environmental changes to proactively wake Workers—can a lightweight model really handle that? The team's answer is two-layer filtering—the first layer uses machine learning or code rules for programmatic filtering, keeping irrelevant information out; only the second layer is handed to the model for judgment. This design is also the foundation of the "proactive execution" capability.

Multi-Agent systems refer to architectures where multiple Agents with autonomous decision-making capabilities collaborate to complete tasks; common patterns include hierarchical (Manager-Worker), peer-to-peer, and pipeline. Their core challenge is coordination overhead: the more sub-agents, the higher the cost of context synchronization, task allocation, and result aggregation, and the easier it is to fall into the trap of "the coordinator itself becoming the bottleneck." Super Agent's Router design is precisely a response to this dilemma—by lowering the model cost of the coordination layer, it concentrates compute on the Workers that actually execute tasks.

Trigger Mechanism: Letting Agents Act Proactively Rather Than Intrude

Super Agent introduces the concept of Trigger, i.e., a mechanism that can trigger Agent behavior. Imagine an Agent pulled into a work group where there are messages that need no handling at all, such as "let's grab lunch" or "got it, thanks," as well as issues that need investigation, such as "image uploads keep failing after the update." Through two layers of screening—programmatic filtering and model judgment—the Agent identifies tasks that truly need handling before launching sub-agents, and stays quiet the rest of the time.

This design optimizes two directions at once: on one hand, it reduces the time cost and economic cost of judging "what is noise"; on the other, it minimizes missed detection of important information. Proactive execution is not the same as frequent intrusion—this is the essential difference between Super Agent and a simple "message bot": what it needs is judgment, not response speed.

The division of labor between programmatic filtering and model filtering is a typical "cascaded judgment" strategy in engineering: first use low-cost, high-certainty rules (keyword matching, event-type whitelists, frequency thresholds) to filter out the vast majority of clearly irrelevant input, then hand boundary samples to a large model for semantic judgment. The economic significance is that model calls are the main source of Token cost, while rule filtering is nearly free; at the same time, the rule layer can withstand extremely high information throughput, making it suitable for high-frequency event streams such as group chats and code commits. The risk is that overly strict rule configuration causes missed detection, so a fallback channel is usually kept between the two layers.

Thread Subscription and Chained Recall: Two Solutions to the Memory Problem

Tasks often cannot be wrapped up in a single conversation. A Worker fixes a bug, the user reads the Router's reply and feels there are still issues, and continues to give feedback—if every revision has to go through the Router, the chain becomes lengthy. Super Agent's solution is Thread subscription: similar to how Feishu turns each message into an independent topic, the Worker Agent subscribes directly to that topic, and every subsequent reply goes straight to the Worker without being dispatched by the Router. The same applies to different comments under the same PR. Furthermore, a Worker can subscribe to multiple related Threads at once, both connected to the code repository to write code and connected to Feishu to see new progress on user bug feedback, avoiding missing context.

There are two more designs at the memory level. Inline: when executing a task, the Agent not only looks at the current Session but also reads summaries of other recent related Sessions, solving the hassle of "losing historical requirements when opening a new window." Spill: keeps long content outside the conversation window and expands it only when needed. For example, the Router tells the user that Plan A is better, and the user asks why; the Router itself does not know the Worker's specific execution details, so it locates which Worker Plan A came from, what its context is, and then cites it back—this process is called chained recall.

Imagine a somewhat romantic scenario: three years ago you discussed with an Agent a line from a book—"the ideal job is the free expression of lifelong learners in the market"—and three years later, when your career hits a bottleneck and you talk about career planning again, the Agent retrieves that line from historical conversations. According to the creator's assessment, this kind of cross-time-scale memory recall is still rather mystical at present, but the direction is worth looking forward to.

The context window is the upper limit on the total number of Tokens an LLM can see in a single inference; anything beyond it is truncated or needs summary compression. Inline and Spill are essentially memory management under limited-window conditions: Inline injects summaries of related Sessions as "external context," effectively expanding the field of view without blowing up the window; Spill keeps long documents and large code blocks outside the window and recalls them via reference location only when needed, which is on-demand loading. Chained recall further requires the Agent to trace the source chain of a conclusion, which depends on indexing capability over the conversation structure rather than mere vector similarity retrieval.

One-Step Advancement and Cloud Residency: Another Source of Efficiency

One-step advancement means that when the Agent receives a new requirement during execution, it does not interrupt the current flow but handles it in parallel. For example, after the code is written and enters the testing phase, the user proposes a change of direction; the Agent will run tests while handling the new requirement, advancing both at the same time.

In the same vein is the cloud-based continuous coordination design: Agents such as GrowthBot and Dot already have built-in cloud computers, fetching information from the user's local computer and executing tasks in the cloud. Shutting down the local computer does not affect cloud progress; when local information is needed, the task waits for the next boot rather than terminating directly. This provides the infrastructure for the Agent's "continuous presence."

Cloud residency essentially decouples the Agent's runtime state from the user's terminal device. The lifecycle of a traditional local Agent is tied to the user's computer and is interrupted on shutdown; a cloud sandbox gives the Agent an independent execution environment and persistent session, with the local machine serving only as an information source and result display end. This model is especially critical for long-running tasks (such as batch testing and multi-round crawling), but it also brings new engineering problems: state synchronization between cloud and local, credential security, and timeout and recovery strategies when a task waits for local information.

Watchdog: Equipping the Main System with an Independent Observer

The more complex the architecture, the more prone it is to problems. Super Agent's response is to set up an independent Agent outside the main system—Watchdog—which runs continuously, checks whether tasks are making substantive progress and whether they deviate from the goal, and starts fixing problems when found, ensuring tasks proceed smoothly.

Measured Data: Faster, but at a Higher Cost

According to the creator's account, Deepseek Harness actually tested the Super Agent architecture: in 95% of cases, Super Agent takes far less time than the traditional single-Session Agent architecture; the average time to complete a task is less than 16 minutes, compared with nearly 30 minutes for the traditional architecture.

The cost is equally clear: more sessions mean more Token consumption. As the architecture scales up, whether the Router can truly coordinate a large number of sub-agents, how to solve long-term memory, and how to ensure permissions and privacy are all questions awaiting answers from development and product practice.

Office Scenarios First, Personal Agents Await Context Integration

At the end of the interpretation, the creator gave his own judgment: this Super Agent design is better suited to work scenarios, and most personal-life scenarios do not need such a complex system. For some time to come, the focus of development will be office Agents; when Personal Agents take off depends more on when different contexts on the internet can be integrated than on the evolution of Agent capabilities themselves.

This judgment is worth pondering. Super Agent is essentially a convergence at the engineering architecture level—handing over human scheduling duties to Agents, and handing over Agent scheduling duties to lighter Agents. It solves the problem of collaboration complexity, and the urgency of this problem is far higher in office scenarios than in personal life.

One-line Summary

Super Agent uses a lightweight Router to coordinate Workers, letting Agents proactively perceive the environment and manage memory, cracking the multi-Session dilemma.

Paragraph Summary

The article interprets the Super Agent architecture proposed by the Deepseek Harness team, aimed at freeing users from multi-Session switching and manual scheduling. The architecture adopts a two-tier structure of Router Agent plus Worker Agent; the Router only bears coordination and communication duties and can use a lightweight model, controlling cost and missed detection through two-layer screening of programmatic filtering and model judgment. The Trigger mechanism enables the Agent to proactively perceive environmental changes in group chats, code repositories, and email, and trigger tasks while staying silent on irrelevant information. At the memory level, Thread subscription lets Workers connect directly to topics, bypassing Router relay, and together with Inline, Spill, and chained recall, solves cross-Session context and long-content citation. Tests show Super Agent is faster in 95% of cases, averaging under 16 minutes versus nearly 30 minutes for the traditional architecture, but Token consumption is higher, and scaling and permission/privacy remain open issues. The author judges the architecture is better suited to office scenarios.