DeepSeek open-sources Super-agent architecture prototype, unveils five-module design

Just now, DeepSeek made public the "secret manual" for its super agent.

Author | Li Shuiqing

Editor | Xin Yuan

Zhi Dong Xi reported on November 1 that on the evening of October 31, the DeepSeek Harness team unveiled the underlying architecture of its autonomous Agent exploration—the Super-agent.

▲Super-agent open-source project address

GitHub address:

https://github.com/deepseek-ai/dsh-superagent-prototype

The "Super-agent" that DeepSeek wants to build can be colloquially understood as an Agent that is always online, can do multiple things at once, actively seeks out work, and can recover on its own when problems arise. The result the team launched this time is not a new product, but rather closer to a new way of thinking—bringing classic ideas from computer systems such as scheduling, caching, storage-compute separation, and Watchdog into the Agent architecture.

As models reduce manual intervention in single-task execution, the bottleneck shifts to human attention. DeepSeek Harness attempts to take over session management and context synchronization at the underlying level through five major modules—dual-layer architecture, event-driven design, asynchronous multi-channel interaction, storage-compute separation, and an external Watchdog—so that humans move up to decision-making and acceptance, improving the Agent application experience.

▲Overall system architecture of Super-agent

In experiments, based on this approach, half of the Super-agent tasks were completed within 12.4 minutes, and 95% of tasks were completed within 15.7 minutes, significantly better than a single Session with Subagent tools; after removing subscription passthrough, the number of Router decisions increased by about 30%, and read-cache tokens increased from 23.23 million to 31.77 million; Router batching reduced the inference time allocated per single decision from 6.4 seconds to 1.6 seconds.

This set of data means that Super-agent has proven the feasibility of "system-layer takeover of session scheduling" in preliminary experiments.

On the one hand, multi-task completion is faster and more stable, with the Router saving overhead through passthrough and handling bursts through batching; but on the other hand, it trades more tokens for time and stability, and the experiments are based on synthetic loads and a simplified environment, serving only as preliminary reference, not formal product conclusions.

Over the past year, single-task Agents such as Coding Agent have proven that models can use tools to solve complex problems, with humans intervening less and less in underlying execution and their role moving up to decision-making and acceptance. New forms such as personal assistants that are continuously online and event-driven have begun to emerge.

However, existing Agents are based on a single Session as the unit, and the upper limit of multi-tasking is constrained by human attention; simple scaling is still limited by synchronous blocking, context confusion, and stopping when the device goes offline.

Therefore, the DeepSeek Harness team proposes Super-agent: a continuous entity that maintains context across sessions, advances multiple tasks in parallel without interfering with each other, and already has internal instances continuously advancing tasks between IM and GitHub.

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

▲Continuously monitors public group chats, proactively identifies defects and submits fix Pull Requests without anyone @-mentioning it

The team believes that Super-agent has four basic characteristics:

- Continuous: Users can interact with it directly in familiar interfaces such as IM chats and GitHub comments, feeling that there is always only one Agent, without needing to think about "whether Session X's context contains information Y." For example, if a user first proposes adopting Plan A in IM and later changes to Plan B in a GitHub PR comment, it can understand and adjust the execution direction.

- Efficient: It responds quickly to interactions while completing multiple complex tasks in parallel with high quality. It can accept the next instruction without waiting for the previous command or task to complete.

- Proactive: Without waiting for users to issue instructions one by one, it can continuously observe environmental events and proactively advance matters worth handling, while staying quiet when no intervention is needed.

- Persistent: Always online, directly connected to the user's real work environment, and automatically recovering from anomalies during long-term operation.

A single ReAct Loop cannot simultaneously support the above four characteristics; a corresponding architecture is needed at the underlying level. The article argues that similar design constraints will lead to similar architectural choices. Whether for personal assistants or Agents in commercial scenarios such as software development, if the goal is to build a system that is continuously online and concurrently responsive to environmental events, the underlying architecture may be similar. Many of the problems faced in this process are highly similar to problems long discussed in traditional computer systems, so classic design ideas from computer systems also apply.

Specific implementations will have different variants, but the article argues that five modules form the basic framework supporting the above four characteristics: a dual-layer architecture balances continuous interaction and efficient concurrency, event-driven design enables proactive response, human-oriented interaction achieves both continuity and efficiency during interaction, and separation of computation, state, and environment plus Watchdog enables cross-device persistent online operation and anomaly self-healing.

There is a fundamental trade-off between continuous cross-channel interaction and efficient multitasking concurrency: if everything is handed to a single Session, the context is the most continuous, but a single ReAct Loop is serial, throughput is low, and details get mixed together; if independent Sessions are all opened, throughput is the highest, but there is no global context, results are fragmented, and interaction becomes chaotic.

The DeepSeek Harness team's solution is to split "maintaining global continuity" and "high-concurrency execution" into two layers: a resident Router layer handles human interaction and global coordination, while a context-isolated Worker layer executes specific tasks concurrently. Sessions should become a system implementation detail, not a user cognitive burden.

▲Dual-layer architecture: the Router layer is uniformly responsible for routing and external interaction, while multiple Worker Sessions execute tasks concurrently in isolation

1. Router layer: only dispatches, does not do the work, and amortizes cost through batching

The Router layer is a resident global routing layer responsible for handling human interaction at all entry points. All cross-task information and decisions are aggregated at the Router layer, which serves as the global sequencing point, coordination point, and memory. To prevent this global node from becoming a performance bottleneck, the Router layer is designed not to directly execute specific tasks, but only to handle human interaction and task dispatch; it may not even be equipped with Bash tools.

This structure, in which one central node dispatches multiple execution nodes, superficially resembles a common Agent Team, but the emphasis is different. A common Agent Team is mainly used for step decomposition and role collaboration within a single complex task; sub-steps are usually tightly coupled, and the Team Lead often needs to deeply understand task details, plan subtasks, and coordinate members frequently, bearing a heavy reasoning load itself. In a Super-agent, by contrast, the Router layer only handles high-level associations and dispatch between tasks and does not need to intervene in the internal decomposition of a single task. Conversely, if prompt constraints are used to make the main session of an Agent Team not personally execute specific tasks, but only handle external interaction and dispatch different tasks to members to advance independently, that can also be regarded as this dual-layer architecture. Team practice shows that Router-layer tasks are often not as complex as imagined, and a lighter-weight model is often enough to balance speed and effectiveness.

Internally, the Router layer likewise need not be limited to a single Session, and some logic may not even need to call an LLM. The team chose the most direct implementation, a single resident LLM Session, as the core of the Router layer, and found that it is not as likely to become a throughput bottleneck as it appears, because environment events arriving during the previous round of inference accumulate and are processed together in the next round, forming batching, and the extra overhead of merged processing is very small:

- When the external event stream is steady, Triggers enter the Router Session one by one, and single-response latency is low;

- When events flood in and the Router Session becomes queued and congested, multiple Triggers accumulated during the previous round of inference are automatically merged and injected together in the next LLM call. The Router Session only performs lightweight interaction and dispatch, and each step is usually long input and short output. Merging multiple accumulated Triggers into one LLM API call computes them in parallel during the Prefill stage, and the latency growth of a single request is far slower than the batch size. Therefore, within a certain range, the more backlog there is, the lower the inference time amortized per decision; the upper limit depends on context length and how many Triggers the model can accurately process in one round.

The article later quantitatively demonstrates the effect of the batching mechanism through experiments. With subscription and pass-through mechanisms plus chain recall, a single resident Router Session is already sufficient at the current team scale while maintaining context continuity.

When the scale expands further and a single session is truly insufficient, the Router layer can also be designed internally as a multi-level filtering structure, or horizontally split into multiple sessions. At that point, the internal design of the Router layer is essentially a trade-off between continuity and throughput. The finer the split granularity, the higher the concurrent throughput of the Router layer, but the lower the memory and context continuity between shards. Before the global memory problem is solved, this trade-off always exists.

The Worker layer consists of sessions responsible for concrete execution. Each Worker is context-isolated from the others, mounts the full execution toolset, and focuses on completing a single task in an independent context. Because Worker Sessions directly determine task results and code quality, they usually need to be configured with the most capable model.

Workers do not interact directly with humans; their reasoning processes and tool calls are not output directly to external channels. Instead, they report status to the Router layer, and the Router layer uniformly replies to the user, thereby ensuring concurrency and delivery quality while avoiding the chaos caused by multiple sessions each replying on their own.

When multiple tasks execute concurrently, each Worker advances its task independently, and Workers at the same layer usually do not need to communicate directly. Conflicts among multiple Workers in concrete execution often arise in shared working environments such as the same Pull Request; as long as they all subscribe to the corresponding Thread, they will receive the same event notifications, giving them a chance to discover and resolve conflicts themselves, while a small amount of cross-task coordination is relayed through the Router layer.

Similar to the Router layer, each Worker Session does not have to be limited to a single conversation: when executing a complex single task, a Worker can internally create Subagents, or can itself be an Agent Team, and all of this remains transparent to the upper Router layer. This structure applies both to code collaboration scenarios, advancing multiple independent issue reproductions, PR reviews, and feature development in parallel without blocking one another, and to personal assistant scenarios: although the personal assistant interface usually provides only a single-conversation chat page, when a user discusses multiple different topics simultaneously in the same dialog box, the single front-end chat page is responsible for maintaining interaction continuity, while underneath a separate Worker can be dispatched for each topic to advance tasks and draft replies in parallel.

To make the Super-agent proactive, the system's driving method must first be changed. The main input driving the Agent is no longer prompts typed line by line by a human in a Session, but semi-structured events in the environment. In the Super-agent, environmental events such as group chat messages, email and calendar reminders, code review comments, and CI run results are called Triggers. By listening for and responding to Triggers, the Agent no longer has to wait passively for a human to issue a command before executing once, as in single-Session mode.

Following the lifecycle of an environmental event from entry to processing, the article discusses four progressive questions in turn: how to filter out a large amount of noise through a two-level strategy combining programs and models; how to route events to Workers through subscription and direct-pass mechanisms; how to use Inline & Spill and chained recall to inject context into the model at high density and recall it on demand; and how to use speculative execution to act ahead of time in the background based on environmental signals.

1. Event filtering: programs screen quickly first, then models judge slowly

After connecting to real group chats and code platforms, the environmental event stream exhibits a pronounced characteristic of "high noise, low trigger rate," and the vast majority of daily messages do not require Agent intervention. If a large model were called to judge every event from scratch, both latency and compute cost would be unbearable. Drawing on the Fast Path / Slow Path idea from computer systems, large-model inference can be regarded as a flexible but costly Slow Path, while solidifying already clear and stable high-frequency judgments into deterministic code constitutes a low-latency, low-cost Fast Path.

Therefore, the first step after an event enters the system is filtering, with the goal of using deterministic strategies to screen out noise before calling a large model, handing only candidate events that require semantic understanding to the model for judgment. The team adopts a two-level filtering mechanism combining program strategies and large models:

- Program-layer strategies, as the Fast Path: for deterministic conditions such as event source, group scope, and user or bot whitelists, quick admission checks are performed directly through code, for example setting "respond only to explicit requests," "treat as candidate event," or "ignore directly" for different sources, filtering out most irrelevant messages before calling the model.

- Semantic-layer strategies, as the Slow Path: candidate events that pass program-layer admission are handed to the LLM, which judges whether action is needed based on strategies written in prompts and on context. The semantic layer also serves as a natural-language extension point for humans, making it convenient to toggle or add strategies via prompts at any time.

▲Two-level filtering: program-layer strategies first screen out most irrelevant messages, then semantic-layer strategies make the judgment

Section 2 introduces the global Router layer, which is responsible for maintaining cross-channel continuity, but if every subsequent event of an already-assigned task still needs to be forwarded through the Router layer, this global node will still bear a large load, pushing up system response latency. Therefore, Fast / Slow Path also applies to event routing after filtering. The global Router layer is responsible only for cold-starting new tasks and cross-task coordination, and subsequent events with an established ownership relationship are sent directly by programs to the corresponding Worker Session without being forwarded through the Router layer.

In actual workflows, consecutive events under the same GitHub PR, the same IM topic, or the same email thread form an event stream, i.e., a Thread.

- Subscribed, Fast Path: subsequent events under the same Thread are passed directly by programs to the subscribed Worker, without the Router layer calling tools to forward them again. If a new event exceeds the scope of the current task, the Worker can also unsubscribe or hand it back to the Router layer for reassignment.

- Not subscribed, Slow Path: the Router layer can still observe all events to grasp global state, but is responsible only for judging and dispatching new events that have not yet been subscribed.

▲Subscription and direct pass: the initial event creates a Worker and establishes a subscription via the Router layer, and subsequent events in the same Thread are sent directly to that Worker

In addition, the subscription relationship between Threads and Workers is many-to-many. A single Worker can subscribe to multiple related Threads at the same time, and the same Thread can also be subscribed to by multiple Workers. When multiple Workers intersect in the same work environment or discussion, new events under that Thread are simultaneously passed directly to all Workers subscribed to it, so that without peer-to-peer communication they still have the opportunity to learn of each other's operations and resolve conflicts on their own. On the output side, Workers still report key conclusions to the Router layer, which uniformly replies to the user and synchronizes global memory.

3. Context organization: put commonly used content directly, summarize long texts first, and find old tasks by ID

After events are filtered and routed and enter the target Session, the next question is how much information should be injected into the model's context window. Because system input shifts from limited human prompts to semi-structured events continuously generated by the environment, the structural design of tool calls and event injection becomes more important. Injecting too much crowds the window and dilutes the model's attention, while injecting too little forces the model to repeatedly call tools to read, increasing the number of execution steps. The article states bluntly: wasting the context window is wasting the model's intelligence.

To this end, the limited context window can be managed as a Cache. Borrowing concepts from compiler optimization and computer systems, the design of context injection can be summarized into two basic operations. Inline means directly inlining information that is very likely to be used soon into the current context window, to save extra tool-call round trips. Spill means leaving complete information that exceeds the window budget or is used infrequently outside the context window, keeping only references or summaries inside the window for the model to read on demand.

Combining the classic locality idea in computer system design, Inline & Spill can be used to progressively optimize event injection and tool calls:

- Start with the minimum information: initially provide only the current object ID and a content summary.

- Use locality to progressively Inline related information: Inline information that is very likely to be used soon into the context, first attaching closely related object IDs, then attaching spatiotemporally adjacent content, such as the first 50 characters of the content, the messages adjacent to and replied to by an IM message, or adjacent comments in the review discussion where a code comment resides.

- Spill when exceeding the limit: set a relatively small length limit for long content that cannot all be Inlined, and Spill the excess outside the window. A simple and direct approach is to truncate the excess and keep an entry point for continued reading, so that the model can call tools to read when it needs the complete content.

In addition, after a large number of subsequent events are passed directly to Workers and the system has accumulated many historical tasks over long-term operation, the Router layer can neither put the full history of all tasks into its own context window nor fail to retrieve context when the user brings up an old task across channels. By consistently applying Inline & Spill to various objects in the system, an on-demand expanding multi-hop retrieval mechanism is obtained, namely chain recall. This chain recall alleviates the problem of the Router layer losing prior information over the long range.

▲Chain recall: each recalled object inlines the ID of the next-hop related object, supporting hop-by-hop expansion of context along reference relationships

Specifically, the system assigns unique IDs to objects such as Triggers, Threads, and Worker Sessions, and inlines closely related object IDs at injection time, so that these objects form a reference graph at the underlying level. Because objects recalled by each tool call also follow Inline & Spill, their returned results in turn inline the summaries and IDs of next-hop related objects, so the model can start from the current event and progressively recall context on demand along reference relationships. For example, it reads the Thread containing a current message, then traces from the Thread's inlined ID to the related Worker Session, and further finds another code review Thread associated with that Worker.

4. Act early: try in the background in advance, deliver only when valuable

Drawing on the idea of speculative execution in computer systems, an Agent can, when it is not yet certain whether a result will be adopted, try in advance in the background based on environmental signals, reducing human waiting and intervention costs by consuming extra background compute. If the result is valuable, deliver it; if not, discard it.

In the personal assistant scenario, when receiving a meeting invitation email or a to-do message, the Agent can first check schedule conflicts, gather relevant background materials, and prepare a reply draft in the background, and then directly confirm and send after the user reviews it. The same applies in the R&D collaboration scenario. For example, the team configured a "silently reproduce and fix" policy in the DeepSeek Harness internal user group: when someone in the group reports a problem or discusses a change proposal, the Agent first tries in the background to reproduce it and find a fix, and only after confirming the problem and finding a simple fix does it deliver the result to the user; otherwise it stays silent throughout.

▲Speculative execution example: while the group is still discussing a solution, the Super-agent has already submitted a fix Pull Request in the background

The two-layer architecture ensures cross-channel context continuity, but the actual interaction experience still needs to solve two points: use an asynchronous ReAct Loop so that time-consuming background operations do not block the foreground, and the session can accept new instructions at any time; and make the output method match the bandwidth of different channels and people's usage habits.

1. Full-duplex interaction: work in the background, the foreground does not stall, and new instructions can come in at any time

In the classic ReAct Loop, after the model initiates a synchronous run() tool call, the loop blocks until the tool finishes executing and returns the final result; during this period, the session cannot respond to any new user input. To eliminate this blocking, the conversation needs to shift from the half-duplex mode of one question and one answer to full-duplex mode.

▲Comparison between the classic ReAct Loop and the asynchronous ReAct Loop

To this end, the team changed time-consuming commands and subtask tool calls into asynchronous start() and stop(), forming an asynchronous ReAct Loop. After the model calls start(), it immediately receives a "started" response, and the loop no longer waits for that tool; after the background tool finishes executing, the system then delivers the final result into the session as a new event message; at the same time, the model can also call stop() based on context to proactively terminate background commands that have been executing for too long.

As a result, foreground conversation responses and background task execution are decoupled, and the Agent can respond to human input while running time-consuming tasks in the background. New input is processed as soon as the current reasoning step ends, without waiting for background tools to complete. The article reveals that this asynchronous task mechanism has been implemented in DeepSeek Harness, but is not yet enabled by default.

2. Multi-channel interaction: low-disturbance short replies for group chats, high-density complete writing for PR emails

Different work channels have different information densities and interaction habits, and system output needs to match them. If the interaction style designed for a single-person terminal is directly moved into group chats, outputting lengthy reasoning processes and dense tool calls as-is, it is very easy to cause information overload in multi-person collaboration.

In Super-agent, the two-layer architecture has already solved part of this problem: in specific tasks, lengthy reasoning processes and dense tool calls are isolated inside the Worker Session and are not directly output to external channels, while the Router layer is uniformly responsible for external interaction. On this basis, the system also needs to connect to the various work environments users use daily, and customize interaction specifications for different channels through prompts:

- Instant messaging channels such as IM: focus on low-disturbance lightweight communication, like a human colleague, sending notifications only when a decision or acceptance is needed, asking only direct questions and giving brief conclusions. The team has verified a simple and effective hard rule: a single reply must not exceed 100 words.

- Asynchronous channels such as GitHub, email, and documents: focus on structured, high-information-density asynchronous delivery, for example, when creating or updating a Pull Request, writing complete problem background, change descriptions, and verification results according to project specifications, or in personal assistant scenarios directly drafting structured emails and document summaries.

Existing local Agents by default bind the computation that advances the Agent Loop, the session state that needs to be persistently saved, and the execution environment such as code repositories and local toolchains to the same device. Once the device sleeps or goes offline, the Agent stops running and cannot access environments on other devices.

To make Super-agent persistently online and flexibly connect to various real work environments, we can draw on the idea of compute-storage separation in computer systems and decouple the binding of the three in two steps: the first step is to separate the computation that advances the Agent Loop from the persistent session state, freeing the Agent from the lifecycle constraints of a single machine and achieving persistent cloud-based online operation; the second step is to decouple the cloud Agent Loop from the heavy-state execution environment, leaving the real work environment in place and supporting cross-device access.

The article points out that this idea is consistent with the "brain-hand separation" proposed by Anthropic, which likewise keeps the harness stateless, stores session logs outside the harness, and connects to execution environments on demand through a unified interface.

But the difference between the two lies in the scenario: the Anthropic article describes a managed service, mainly discussing on-demand sandboxes and resources within customer VPCs; what needs to be connected here first are the personal machines users use daily and that may be intermittently online, with uncommitted changes and local credentials on them. Therefore, this design supports both BYOM, that is, connecting the development machines or personal computers users use daily to the cloud Agent, and connecting to cloud-hosted machines or on-demand compute environments.

As a result, an Agent is no longer limited to a single machine, but can switch between different execution devices, choosing an environment according to task needs to execute commands and obtain context from the environment. It can even support intermittently online devices, for example, after one of the user's personal devices comes back online, the cloud Agent automatically triggers and completes tasks that need to be executed on that device.

To achieve persistent online operation, in addition to the compute-storage separation in Section 5, the system also needs to be able to automatically recover from anomalies during long-term operation. It is difficult for a persistently online distributed system to guarantee long-term reliable operation solely through the internal logic of the main system; an independent external control loop, namely the Control Loop, needs to be introduced outside the main system.

At the same time, in an Agent system, traditional process liveness detection or monitoring scripts alone are not enough, because many anomalies are not process crashes, but the model falling into an ineffective loop or deviating from the goal during execution. Therefore, a long-running Agent system needs to monitor not only infrastructure liveness but also the progress of the task itself.

The team configured an independent Watchdog Session outside the main system, driving it with scheduled messages to form an external Control Loop. In addition to handling infrastructure failures such as interface errors and state recovery failures, the Watchdog also uses the model to judge whether each Worker is making substantive progress and whether its direction deviates from the overall goal. When anomalies are found, it intervenes promptly to repair them; when external sporadic failures occur, it keeps rechecking until normal operation is restored.

Since the Watchdog itself is also an Agent Session with full tool capabilities, maintainers can ask it in natural language about the causes of failures, and can also have it correct the main system's behavior online, for example by adding or removing prompts and adjusting trigger rules.

To evaluate the core scheduling and routing design described above, the team conducted preliminary experiments at two levels: first, end-to-end experiments comparing the two-layer architecture, subscription passthrough, and the single-Session approach; then, separately testing batching at the Router layer. Because the experiments are based on synthetic load and a simplified environment, some settings could be made more rigorous, and the following results are for preliminary reference only.

1. Ablation experiments: faster and more stable; passthrough does not speed things up but saves the Router about 37% of tokens

The experiment used group chat and GitHub CI message streams to drive four approaches, with about 300 messages per run, of which about 20 were work requests; coding work was replaced by tools that only consume time, and each approach was run 5 times.

▲ Cumulative arrival curve of work requests and cumulative completion curves of the four approaches

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

Super-agent's p50 and p95 were 12.4 minutes and 15.7 minutes respectively, significantly better than the single Session with Subagent tools. The latter is heavily influenced by prompts: under a neutral prompt, none of the 5 runs invoked the Subagent, and all work was done in the main Session, constantly interrupted by new messages, with p95 reaching 29.5 minutes; after switching to prioritize delegation, 4 of 5 runs delegated, but it was still slower than Super-agent, and in the remaining run the model judged the work to be "very small" and executed it itself, creating a long tail.

In terms of overhead, Super-agent maintains multiple sessions, so its read-cache tokens are higher than those of a single Session, trading more tokens for shorter and more stable completion times. After removing passthrough, completion times were basically the same, but the number of Router decisions increased by about 30%, and read-cache tokens rose from 23.23 million to 31.77 million, an increase of about 37%. Passthrough does not improve speed, but it saves the Router considerable tokens and inference overhead.

2. Batching at the Router layer: after merging backlogs, the amortized time per decision dropped from 6.4 seconds to 1.6 seconds

The team separately stress-tested the Router layer: the Router called the real model, Workers used Mock models, and the Trigger arrival rate rose from about 1 per minute to about 40 per minute.

As a result, the average batch rose from 1.0 to 2.8, the time per request increased only from 2.5 seconds to 3.9 seconds, growing more slowly than the batch size, and the amortized inference time per decision dropped from 6.4 seconds to 1.6 seconds.

This shows that during sudden congestion the Router can automatically merge backlogged events to improve throughput, and it also explains why the increased peak load after removing passthrough still did not reach the bottleneck. Therefore, at the current team size, there is no need to prematurely split horizontally and sacrifice the continuity of global context.

▲ Batch size, time per request, and amortized inference time per decision of the Router Session under different Trigger arrival rates

The five modules introduced in Sections 2 through 6 constitute the basic architecture supporting the operation of Super-agent, and the experiments in Section 7 also verified the effectiveness of its core scheduling and routing mechanisms under multi-task concurrency.

The reason this system can operate with relatively low complexity is largely that at the current stage a series of engineering and scenario simplifications have been made. Beyond the applicable scope of these simplifications, there are still some problems to be solved in scaling the two-layer architecture, human-agent collaboration outside Sessions, context boundaries and A2A, and security and privacy.

The article lists four open questions: first, how to scale the two-layer architecture; there is no consensus on when to split once a single Router exceeds its capacity, what granularity to use, or when Workers should communicate directly with each other, and cross-month long-range memory is also a bottleneck; second, how to collaborate outside Sessions; the chat window may not be the final form, and interaction may increasingly occur in domain interfaces such as GitHub, while also needing to support users' mid-course intervention, takeover, and real-time collaboration.

Third, how to divide context boundaries as the organization expands; A2A communication and collaboration among multiple isolated instances remain to be explored; fourth, security and privacy; cloud Agents accessing endpoint credentials carry risks of intrusion and prompt injection, and Agents still need to be able to use credentials without touching the credentials themselves.

The article does not propose an entirely new theory, but applies classic engineering ideas from computer systems to the construction of Agent systems. The specific implementation will evolve, but the design approach has long-term reference value. The internal Super-agent instance based on DeepSeek Harness has been running continuously, participating in problem reproduction and repair, code review, and Harness iteration.

As models reduce manual intervention in executing individual tasks, the bottleneck shifts to human attention. The two-layer architecture, event-driven design, asynchronous multi-channel interaction, separation of storage and compute, and the external Watchdog take over session management and context synchronization at the lower level, moving humans up to decision-making and acceptance.

Agents change from passive chat windows into continuously online autonomous collaborators: for individuals, a cross-device assistant; for teams, integrated into R&D workflows. The team believes that a more autonomous way of working is expected to become the norm. Some designs have been implemented in dsh-superagent-prototype, but this plugin is only a prototype for validating the technical route and is not an official DeepSeek product. Disclaimer

(Disclaimer: This article represents only the author's views and does not represent Sina's position.)