DeepSeek: Exploring Super-agent Design (WeChat translation)
> Towards a More Autonomous Agent System
Yujia Qiao · DeepSeek Harness team
English translation · 31 October 2026
This article explores architectural ideas for engineering practice. It is not an introduction to the features currently available in DeepSeek Harness.
1. Super-agent
Over the past year, single-task agents, exemplified by coding agents, have demonstrated that models can use tools to solve complex problems, with a diminishing need for continuous human monitoring and step-by-step intervention. At the same time, models are becoming better at coordinating multiple agents, making organization and scheduling across Sessions feasible. As human involvement in low-level execution decreases, the human role is gradually shifting toward higher-level decision-making and acceptance of results.
This improvement in model capabilities has also given rise to new forms of application. Personal assistants, or Personal Agents, have recently begun to emerge in large numbers. They connect directly to everyday messaging, calendars, email, and work platforms, continuously observing information streams and helping handle tasks. This continuously online, event-driven way of working is not limited to personal use: personal assistants are just one application. It is equally valuable in business settings such as software development.
However, mainstream agent designs still struggle to support this mode of operation at the scale of multiple tasks and team collaboration. An agent’s work is still organized around a single Session, with different Sessions independent of one another. When users work on several things in parallel, they must manually switch between Sessions and remember the context of each. In our observations, a person can usually keep track of only three to five active Sessions at once. Under this design, the ceiling for a single task depends on the model’s capabilities, while the ceiling for multiple tasks depends on human attention.
Simply extending an existing local, single-Session agent through a CLI, MCP, or external connectors may allow it to receive external messages. But it remains constrained by synchronous blocking within a single Session, tangled context across tasks, and operation stopping whenever the local device goes offline. Substantial human maintenance is still required.
To overcome these limitations, we need to break the coupling between an agent and a single manually managed Session, turning it into a continuous entity that retains context across Sessions and advances several complex tasks at the same time without mutual interference. We call this form of agent and its system architecture Super-agent.
For example, in the Super-agent instance we run internally on DeepSeek Harness, a single development task can continue across IM and GitHub. This instance also continuously monitors feedback in public group chats, proactively identifies root causes, and submits Pull Requests with fixes even when nobody @mentions it:
Specifically, we believe a Super-agent has four fundamental characteristics:
Continuity: Users can interact with it directly in familiar work interfaces such as IM chats and GitHub comments. They feel that they are always dealing with one agent, without having to ask, “Does the context of Session X contain information Y?” For example, if a user first proposes approach A in IM and later switches to approach B in a GitHub Pull Request comment, it can understand the change and adjust its execution accordingly.
Efficiency: It responds quickly to interactions while completing multiple complex tasks in parallel to a high standard. It can accept the next instruction without waiting for the previous command or task to finish.
Proactivity: Rather than waiting for users to issue instructions one by one, it continuously observes events in its environment and proactively advances matters worth addressing, remaining silent when no intervention is needed.
Persistence: It remains online, connects directly to the user’s actual work environment, and automatically recovers from abnormal conditions during long-term operation.
A single ReAct Loop cannot support all four characteristics at once; an appropriate underlying architecture is needed. Similar design constraints lead to similar architectural choices. We believe that, whether the application is a personal assistant or an agent for a business setting such as software development, systems intended to remain online and respond concurrently to events in their environment may adopt similar underlying architectures. Many of the problems encountered along the way also closely resemble those long studied in traditional computer systems, so many classic ideas from computer systems design apply here as well.
Specific implementations will vary, but we believe the following five modules form the basic framework supporting these four characteristics: a two-layer architecture (Section 2) combines continuous interaction with efficient concurrency; an event-driven design (Section 3) enables proactive responses; human-oriented interaction (Section 4) delivers both continuity and efficiency in the interaction process; and the separation of computation, state, and environment (Section 5), together with a Watchdog (Section 6), provides persistent availability across devices and automatic recovery from abnormal conditions.
The following diagram shows the overall Super-agent system architecture. Module labels [2] through [6] correspond to Sections 2 through 6 below:
2. A Two-Layer Architecture
To provide both continuous interaction across channels and efficient concurrency across tasks, the system faces a fundamental trade-off between continuity and throughput in how it organizes its underlying Sessions.
If every event is handled by the same Session, context is as continuous as possible. But execution is limited by the serial processing speed of a single ReAct Loop, resulting in long task completion times and low throughput. Mixing together the intermediate details of multiple tasks can also impair the results.
Conversely, opening a new independent Session for every event maximizes concurrent throughput. But whenever tasks are not completely independent, the lack of global context leaves the Sessions’ results disconnected from one another. Having multiple Sessions respond separately to the user also makes interaction confusing.
To balance continuity and throughput, we can separate “maintaining global continuity” from “highly concurrent execution” into two distinct layers. A long-lived Router layer (Section 2.1) provides a unified point for human interaction and global coordination, while a Worker layer (Section 2.2), with isolated contexts, executes individual tasks concurrently, as shown below:
With this two-layer architecture, the system takes over context management and concurrent execution at the underlying level. Sessions become less prominent to the user, who continues to interact with the same Super-agent. From this perspective, requiring users to manage Sessions manually is largely a design convention inherited from the underlying LLM API. Sessions should be an implementation detail of the system, not a cognitive burden on the user.
In existing designs, a Session serves both technical context management and user-facing project management. Once the product is decoupled from the underlying Sessions, user-facing project management is no longer constrained by them. Deciding what forms of interaction and task management to expose to users becomes a separate product question. We discuss this later in the article.
Here, “two-layer” refers to a logical division of responsibilities. Neither layer needs to be implemented as a single Session; each can have its own internal structure. The following sections describe the Router layer and Worker layer in turn.
The Router layer is a long-lived global routing layer that handles human interaction from every entry point. All information and decisions spanning tasks are consolidated in this layer, which serves as the system’s global sequence point, coordination point, and memory. To prevent this global node from becoming a performance bottleneck, the Router layer is designed not to execute specific tasks itself. It handles only human interaction and task assignment, and may not even be equipped with a Bash tool.
At first glance, a central node assigning work to multiple execution nodes resembles a conventional Agent Team, but the two have different emphases. A conventional Agent Team primarily decomposes a single complex task into steps and coordinates roles within it. Because those steps are usually tightly coupled, the Team Lead often needs a deep understanding of task details, must plan subtasks, and must coordinate members frequently, taking on a substantial reasoning workload itself. In a Super-agent, by contrast, the Router layer handles only high-level relationships and assignments across tasks; it need not become involved in decomposing an individual task. Conversely, if an Agent Team’s main Session is constrained through prompts to refrain from executing specific tasks, to handle only external interaction, and to assign different tasks to members who advance them independently, it can also be regarded as this kind of two-layer architecture. In our experience, Router-layer tasks are often less complex than one might expect, and a relatively lightweight model can often provide both speed and effective results.
The Router layer’s internal implementation likewise need not be confined to a single Session, and some of its logic may not require LLM calls at all. We chose the most straightforward implementation—a single long-lived LLM Session—as the core of the Router layer. We found that it does not become a throughput bottleneck as readily as it might appear. Environmental events arriving during one round of inference—the Triggers introduced in Section 3—accumulate and are processed together in the next round. This produces batching, with little additional overhead from processing the events together:
When the external event stream is steady, Triggers enter the Router Session one at a time, and individual response latency is low.
When events arrive in a burst and a queue begins to build up at the Router Session, the Triggers accumulated during the previous round of inference are automatically combined and injected together in the next LLM call. The Router Session performs only lightweight interaction and assignment, so each step typically has a long input and a short output. Combining multiple queued Triggers into one LLM API call allows them to be processed in parallel during prefill, and the duration of a request grows much more slowly than the batch size. Thus, within a certain range, a larger backlog reduces the inference time amortized over each decision. The upper limit depends on context length and on how many Triggers the model can process accurately in one round.
Section 7.2 quantifies the effects of this batching mechanism experimentally. Combined with the subscriptions and direct delivery mechanism and Chain of Recall introduced later (Sections 3.2 and 3.3), a single long-lived Router Session is already sufficient at our current team size while preserving continuity of context.
If the scale grows further and a single Session truly becomes insufficient, the Router layer can be organized internally into multiple filtering stages or sharded across several Sessions. At that point, the layer’s internal design is fundamentally a trade-off between continuity and throughput. Finer-grained sharding increases concurrent throughput in the Router layer, but reduces continuity of memory and context across shards. This trade-off remains until the global memory problem is solved.
The Worker layer consists of Sessions responsible for actual execution. Each Worker has a context isolated from those of the other Workers, is equipped with the full set of execution tools, and focuses on completing a single task in its own context. Because Worker Sessions directly determine task outcomes and code quality, they usually need to be configured with the most capable model.
Workers do not interact with humans directly. Their reasoning and tool calls are not sent directly to external channels. Instead, they report their status to the Router layer, which provides a unified response to users. This preserves concurrency and delivery quality while avoiding the confusion caused by several Sessions responding independently.
When multiple tasks run concurrently, each Worker advances its task independently, and Workers at the same layer usually do not need to communicate directly. Conflicts during execution often arise in shared work environments, such as the same Pull Request. As long as the Workers all subscribe to the corresponding Thread, they receive the same event notifications (Section 3.2), giving them an opportunity to detect and resolve conflicts themselves. The occasional need for coordination across tasks is handled through the Router layer.
Like the Router layer, each Worker Session need not be limited internally to a single Session. When executing a complex individual task, a Worker can create Subagents or can itself be an Agent Team. The Router layer above need not be aware of these internal arrangements. This structure suits both collaborative coding—where multiple independent bug reproductions, Pull Request reviews, and feature-development tasks can proceed without blocking one another—and personal assistants. Although a personal assistant typically presents a single-Session chat page, a user may discuss several different topics in the same chat box. The single chat page maintains continuity of interaction, while the underlying system can assign a separate Worker to each topic, advancing tasks and drafting replies in parallel.
3. Event-Driven Operation
To make a Super-agent proactive, we first need to change what drives the system. Its primary inputs are no longer prompts typed one by one by humans into a Session, but semi-structured events from its environment. In a Super-agent, environmental events such as group-chat messages, email and calendar reminders, code-review comments, and CI results are called Triggers. By listening for and responding to Triggers, an agent no longer needs to wait passively for a human instruction each time before executing work, as it does in the single-Session model.
Following the lifecycle of an environmental event from arrival to processing, the sections below address four successive questions: how to filter large amounts of noise using a two-level policy that combines code and a model (Section 3.1); how to route events to Workers through subscriptions and direct delivery (Section 3.2); how to use Inline & Spill and Chain of Recallto inject context densely and retrieve it on demand (Section 3.3); and how to use speculative execution to act in advance in the background, based on signals from the environment (Section 3.4).
Once an agent is connected to real group chats and code platforms, the environmental event stream has a pronounced “high noise, low activation rate” character: the vast majority of everyday messages do not require agent intervention. Calling a large model to make a fresh judgment about every event would impose prohibitive latency and compute costs. Drawing on the Fast Path / Slow Path idea from computer systems, large-model inference can be treated as a flexible but expensive Slow Path. Encoding frequent judgments whose criteria are already clear and stable as deterministic code creates a low-latency, low-cost Fast Path.
The first step after an event enters the system is therefore filtering. The aim is to use deterministic policies to remove noise before calling the model, passing on only candidate events that require semantic understanding. We use a two-level filteringmechanism combining programmatic policies with a large model:
Programmatic policy layer, serving as the Fast Path: Code performs fast admission checks on deterministic conditions such as event sources, the set of groups in scope, and user or bot allowlists. Different sources can, for example, be configured to “respond only to explicit requests,” “treat as candidate events,” or “ignore outright.” This filters out most irrelevant messages before any model call.
Semantic policy layer, serving as the Slow Path: Candidate events that pass the programmatic admission checks go to the LLM, which determines whether action is needed based on policies written as prompts and the available context. The semantic layer also provides a natural-language extension point for people, making it easy to enable, disable, or add policies through prompts at any time, as shown below:
The global Router layer introduced in Section 2 maintains continuity across channels. But if it must still forward every follow-up event for tasks that have already been assigned, this global node will continue to bear a substantial load, increasing the system’s response latency. The Fast Path / Slow Path distinction therefore also applies to routing after filtering. The global Router layer handles only the initial setup of new tasks and coordination across tasks. Once ownership is established, code sends subsequent events directly to the corresponding Worker Session, without forwarding them through the Router layer.
In real workflows, successive events associated with the same GitHub Pull Request, IM topic, or email conversation form an event stream called a Thread:
After the Router layer creates a Worker Session in response to the initial event in a Thread, that Worker subscribes directly to the corresponding Thread. Event routing then follows the two paths shown below:
Subscribed, or Fast Path: Code delivers subsequent events in the same Thread directly to the subscribed Worker, without the Router layer needing to invoke a tool to forward them again. If a new event falls outside the current task’s scope, the Worker can unsubscribe or return it to the Router layer for reassignment.
Unsubscribed, or Slow Path: The Router layer can still observe all events to maintain an overall view of the system’s state, but it is responsible for judging and assigning only new events that are not yet covered by a subscription.
Subscriptions between Threads and Workers are also many-to-many. A Worker can subscribe to several related Threads at once, and several Workers can subscribe to the same Thread. When Workers’ activities intersect in a shared work environment or discussion, new events in that Thread are delivered directly to all its subscribers. This gives them an opportunity to learn about one another’s actions and resolve conflicts themselves, without point-to-point communication. On the output side, Workers still report their key conclusions to the Router layer, which provides a unified response to users and keeps global memory in sync.
Once an event has been filtered and routed to its target Session, the next question is how much information to inject into the model’s context window. As the system’s inputs shift from a limited number of human prompts to a continuous stream of semi-structured environmental events, the structure of tool calls and event injection becomes more important. Injecting too much information consumes the window and dilutes the model’s attention. Injecting too little forces the model to make repeated tool calls to read more, increasing the number of execution steps. Wasting the context window means wasting the model’s intelligence.
We can therefore manage the limited context window as a cache. Borrowing concepts from compiler optimization and computer systems, context injection can be described in terms of two basic operations. Inline means placing information likely to be needed soon directly into the current context window, avoiding extra tool-call round trips. Spill means retaining the full information outside the context window when it exceeds the window’s budget or is used infrequently, leaving only a reference or summary inside the window for the model to follow on demand.
Combining this with the classic computer-systems principle of locality, we can progressively optimize event injection and tool calls using Inline & Spill:
Start with minimal information: Initially, provide only the current object’s ID and a summary of its contents.
Use locality to progressively Inline related information: Inline information likely to be needed soon. First include the IDs of closely related objects, then add information nearby in space or time—for example, the first 50 characters of the contents, the messages immediately before and after an IM message and the message it replies to, or adjacent comments in the review discussion containing a code comment.
Spill anything beyond the limit: Set a modest length limit for long content that cannot be fully inlined, and Spill the excess outside the window. A straightforward approach is to truncate the excess while retaining a way to continue reading. The model can then call a tool if it needs the full contents.
In addition, once many follow-up events are delivered directly to Workers and the system has accumulated a substantial history of tasks over a long period, the Router layer cannot keep the complete history of every task in its own context window. Yet it still needs to recover context when a user brings up an old task through a different channel. Applying Inline & Spill consistently to the various objects in the system produces an on-demand, progressively expandable, multi-hop retrieval mechanism: Chain of Recall. This process mitigates the Router layer’s loss of earlier information over long periods, as shown below:
Specifically, the system assigns unique IDs to objects such as Triggers, Threads, and Worker Sessions. When injecting an object, it inlines the IDs of closely related objects, forming an underlying graph of references. Every object retrieved through a tool call follows Inline & Spill in the same way: the returned result includes summaries and IDs of related objects at the next hop. Starting from the current event, the model can follow these references to retrieve context progressively as needed.
For example, it can read the Thread containing a current message, follow an ID inlined in that Thread to a related Worker Session, and then find another code-review Thread associated with that Worker.
Drawing on speculative execution in computer systems, an agent can use signals from the environment to begin trying things in the background before knowing whether the results will be used. It spends additional background compute to reduce the time humans must wait and the effort they must spend intervening. If the results are valuable, it delivers them; otherwise, it discards them.
For a personal assistant, receiving a meeting invitation email or a to-do message can prompt the agent to check for calendar conflicts, gather relevant background information, and prepare a draft reply in the background. Once the user has reviewed it, they can confirm and send it immediately. The same applies to collaborative development. For example, in our company’s internal DeepSeek Harness user group, we configured a “silently reproduce and fix” policy. When someone reports a problem or discusses a proposed change in the group, the agent first tries to reproduce the issue and find a fix in the background. It delivers the result to the user only after confirming the problem and finding a simple fix; otherwise, it remains silent throughout.
4. Human-Oriented Interaction
The two-layer architecture in Section 2 ensures cross-channel continuity at the context level. But achieving both continuity and efficiency in the actual human–agent interaction experience requires solving two further problems in how and where interaction takes place. First, how can an asynchronous ReAct Loop prevent time-consuming background operations from blocking the foreground conversation, so that the conversation can accept new instructions at any time without waiting for the previous command or task to finish (Section 4.1)? Second, when interaction takes place across the different work channels familiar to users, how can the system adapt its output to each channel’s bandwidth and people’s habits of using it (Section 4.2)?
4.1 Full-Duplex Interaction
In a classic ReAct Loop, after the model initiates a synchronous run() tool call, the loop blocks until the tool finishes executing and returns its final result. During this period, the conversation cannot respond to any new user input. Eliminating this blockage requires changing the conversation from a half-duplex, question-and-answer mode to a full-duplex mode, as shown below:
To achieve this, we replace time-consuming command and subtask tool calls with asynchronous start() and stop()calls, 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. When the background tool finishes executing, the system delivers its final result to the conversation as a new event message. The model can also call stop(), based on the context, to proactively terminate a background command that has been running too long.
This decouples responses in the foreground conversation from task execution in the background, allowing the Agent to respond to human input while running time-consuming tasks. New input is processed as soon as the current inference step ends, without having to wait for the background tool to finish.
This asynchronous task mechanism has already been implemented in DeepSeek Harness, but it is not yet enabled by default.
4.2 Multi-Channel Interaction
Different work channels have different information densities and interaction conventions, and the system’s output needs to match them. Simply transplanting an interaction style designed for a single user’s terminal into a group chat, reproducing lengthy reasoning and frequent tool calls in full, can easily cause information overload in collaboration among multiple people.
In Super-agent, the two-layer architecture already solves part of this problem: lengthy reasoning and frequent tool calls for specific tasks are isolated inside Worker Sessions and are not output directly to external channels. Instead, the Router layer handles external interaction centrally. Building on this, the system also needs to connect to the various work environments users rely on every day and use prompts to tailor interaction conventions to different channels:
IM and other instant-messaging channels: Emphasize lightweight communication with minimal interruption. Like a human colleague, send notifications only when a decision or acceptance of results is needed; ask direct questions and provide brief conclusions. One simple, effective hard rule we have tested is that a single reply must not exceed 100 words.
Asynchronous channels such as GitHub, email, and documents: Emphasize structured, information-dense asynchronous delivery. For example, when creating or updating a Pull Request, provide a complete account of the problem background, changes, and verification results in accordance with the project’s conventions. In a personal-assistant setting, directly draft structured emails and document summaries.
5. Separating Computation, State, and Environment
By default, existing local Agents tie together, on a single device, the computation that advances the Agent Loop, the conversation state that must be persisted, and the execution environment, such as the code repository and local toolchain. Once the device sleeps or goes offline, the Agent stops running, and it cannot access environments on other devices. To keep Super-agent persistently online while flexibly connecting it to different real-world work environments, we can draw on Compute-Storage Separation from computer systems and decouple these three components in two steps. First, separate the computation that advances the Agent Loop from persistent conversation state, freeing the Agent from the lifecycle of a single machine and allowing it to stay online persistently in the cloud (Section 5.1). Second, decouple the cloud-based Agent Loop from the execution environment, which contains substantial state, leaving real work environments where they are while supporting access across devices (Section 5.2).
5.1 Separating Computation from State
The computation that advances the Agent Loop can be made stateless; it is the conversation state that needs to be persisted. The first layer of decoupling therefore places the computation that advances the Agent Loop in stateless, elastic compute containers in the cloud, while storing persistent state, such as Sessions, in a database. Stateless compute containers can be scaled horizontally, restarted, or replaced, while persistent storage ensures continuity for conversations and tasks. This frees the Agent from the lifecycle of any single local device and allows it to stay online persistently in the cloud.
5.2 Separating Computation from the Execution Environment
Once the Agent Loop and conversation state reside in the cloud, the next question is how to access the execution environment a task requires. Much of the context the model needs for its work must be obtained through tool calls to execution environments such as code repositories, local files, and services on which the task depends. In this sense, context in the broader sense includes the execution environment itself.
There are two common approaches to this problem. One is to launch a sandbox in the cloud, fetch the code, and attempt to reconstruct and synchronize the environment. However, real work environments often contain uncommitted local changes, private credentials, dependencies on internal-network services, and specific hardware or toolchains. Synchronizing such an environment is not only technically costly but also prone to leaving information out. The other approach is simply to require users to abandon their local environments and move their work to the cloud, but for many users the migration cost is too high.
Since the environment itself is what is difficult to replicate and synchronize, there is no need for the execution environment to follow the Agent Loop into the cloud. The second layer of decoupling lets the Agent Loop run in the cloud while leaving the execution environment, with its substantial state, where it is. Only a lightweight daemon that does not store conversation state is deployed on the device. Its sole responsibilities are to execute commands and return results. In effect, this keeps the execution environment outside the cloud, with the Agent reading context from it on demand.
This approach is consistent with Anthropic’s proposal of “Decoupling the brain from the hands”: both keep the harness stateless, store conversation logs outside the harness, and connect to execution environments on demand through a unified interface. The difference lies in the setting. That article describes a managed service, focusing on sandboxes created on demand and resources inside customers’ VPCs. Here, our first priority is to connect users’ everyday personal machines, which may be online only intermittently and contain uncommitted changes and local credentials. Accordingly, this design supports both BYOM (Bring Your Own Machine)—connecting the development machine or personal computer a user works on every day to a cloud-based Agent—and connections to cloud-hosted machines or compute environments created on demand.
As a result, an Agent is no longer restricted to a single machine. It can switch among different execution devices, choosing an environment according to the task’s needs to execute commands and obtain context from that environment. It can even support devices that are online only intermittently. For example, when one of a user’s personal devices comes back online, the cloud-based Agent can automatically trigger and complete tasks that need to run on that device. The diagram below shows the structure after computation, persistent state, and the various execution environments have been decoupled in these two layers:
To remain persistently online, the system needs not only the compute-storage separation described in Section 5 but also the ability to recover automatically from abnormal conditions over long periods of operation. A distributed system that stays online continuously can hardly ensure reliable long-term operation through the main system’s internal logic alone. It needs an independent external Control Loop outside the main system.
At the same time, traditional process-liveness checks or monitoring scripts alone are insufficient in an Agent system. Many abnormal conditions are not process crashes: they arise when the model falls into unproductive loops or strays from its goal during execution. A long-running Agent system therefore needs to monitor not only whether its infrastructure is alive but also whether the tasks themselves are making progress.
We have configured an independent Watchdog Session outside the main system and drive it with scheduled messages, forming this external Control Loop. In addition to handling infrastructure failures such as API errors and failed state recovery, the Watchdog uses the model to judge whether individual Workers are making substantive progress and whether their direction has deviated from the overall goal. When it detects an abnormal condition, it intervenes promptly to fix it; when an occasional external failure occurs, it continues checking until normal operation resumes.
Because the Watchdog itself is an Agent Session with a full set of tools, maintainers can ask it about the cause of a failure in natural language. They can also have it adjust the main system’s behavior while it is running, for example by adding or removing prompts or modifying trigger rules.
7. Preliminary Experiments
To evaluate the core scheduling and routing designs discussed above, we conducted preliminary experiments at two levels. First, end-to-end experiments compared the two-layer architecture and subscription-based direct delivery with single-Session approaches (Section 7.1). We then tested batching in the Router layer separately (Section 7.2). Because the experiments use synthetic workloads and simplified environments, some aspects of the setup could be made more rigorous. The results below should therefore be regarded only as preliminary reference points.
We used streams of group-chat and GitHub CI messages to drive four end-to-end approaches simultaneously. Each experimental run contained approximately 300 messages, of which approximately 20 were work requests; the remainder were casual conversation, follow-ups, stop requests, and CI messages. Coding work was replaced with a tool that merely consumed time, so the experiments measured the system’s scheduling and collaboration capabilities, rather than its ability to execute an individual task. Each approach was run five times.
The four approaches compared were Super-agent, Super-agent without direct delivery, and a single Session with a Subagent tool under two different prompt configurations.
The neutral prompt read: “Use a subagent for a piece of work when appropriate…”
The delegation-first prompt read: “Every message of the chat reaches you, so work you run yourself keeps stopping for new messages. Prefer handing each piece of work to a subagent of its own, and do only small things yourself…”
In terms of task completion time, Super-agent’s p50 and p95 were 12.4 minutes and 15.7 minutes respectively, substantially better than those of a single Session equipped with a Subagent tool. The reason is that, in this experimental setting, the single Session with a Subagent tool was strongly influenced by its prompt. The main Session often decided to carry out tasks itself, resulting in long overall completion times and inconsistent performance. Under the neutral prompt, the model did not invoke a Subagent even once across the five runs. All work took place in the main Session and was repeatedly interrupted by new messages, with p95 reaching 29.5 minutes. After changing to the delegation-first prompt, the model delegated in four of the five runs. Completion times became shorter but remained slower overall than Super-agent. In the remaining run, the model judged the work to be “small” and chose to execute it itself, producing the purple long tail in the figure. Compared with relying on prompt engineering and the model’s judgment at the time to decide whether to delegate within a single Session, the two-layer architecture alleviates this problem at the system level: the Router does not execute specific work directly, and Workers receive only messages from the Threads to which they subscribe.
In terms of system overhead, maintaining multiple independent conversations means that Super-agent uses more cache-read tokens per experimental run than a single Session. It trades greater token consumption for shorter and more consistent completion times. Removing the direct-delivery mechanism from Super-agent leaves task completion times essentially unchanged from the full version, but increases the number of decisions the Router must make per experimental run by approximately 30%. Total cache-read tokens rise from 23.23 million to 31.77 million, an increase of approximately 37%. This indicates that, under the experimental workload, direct delivery does not improve task-completion quality or speed, but saves the Router Session substantial token usage and inference overhead.
7.2 Batching in the Router Layer
To test the throughput limit and batching mechanism of the single long-lived Router Session described in Section 2.1, we stress-tested the Router layer separately. The Router called a real model, while Workers used a mock model. We gradually increased the arrival rate of Triggers requiring a decision from approximately one per minute to approximately 40 per minute, observing the average batch size, time per request, and inference time amortized per decision.
As the figure shows, when the arrival rate of Triggers requiring a decision rises from approximately one per minute to approximately 40 per minute, the average batch size increases from 1.0 to 2.8, while time per request rises only from 2.5 seconds to 3.9 seconds. Because request time grows more slowly than batch size, inference time amortized per decision falls from 6.4 seconds to 1.6 seconds. This means that when bursts of external events create a backlog, the Router layer can improve its effective throughput by automatically combining queued events into batches. It also explains why, in Section 7.1, removing direct delivery increased the Router’s peak load without reaching the throughput bottleneck of a single Router. At our current team size, there is therefore no need to partition the Router layer horizontally prematurely and sacrifice the continuity of the global context.
8. Open Questions
The five modules introduced in Sections 2 through 6 form the basic architecture that supports Super-agent’s operation. The experiments in Section 7 also validate the effectiveness of the core scheduling and routing mechanisms when multiple tasks run concurrently. This system can operate with relatively low complexity largely because we have made a series of engineering and scenario simplifications at this stage. Beyond the scope in which those simplifications apply, questions remain about scaling the two-layer architecture (Section 8.1), human–agent collaboration beyond the Session (Section 8.2), context boundaries and A2A (Section 8.3), and security and privacy (Section 8.4).
8.1 How to Scale the Two-Layer Architecture
The simplified combination described above—“one long-lived Router Session + subscription-based direct delivery + no direct communication between Workers”—covers most of our current day-to-day tasks at relatively low engineering cost. But when tasks increase in scale and become more tightly coupled, exceeding what a single Router Session can handle, the internal structure of each layer is not settled. When the Router layer needs to be partitioned horizontally, how finely it should be partitioned, when direct communication should be introduced between Workers at the same level, and what collaboration topology they should use all remain to be tested in more scenarios. At the same time, system–model co-design is another direction worth exploring. Specialized training for tasks such as event classification, batch dispatch, and context recall in the Router layer could further improve its throughput and decision-making performance.
Meanwhile, the long-lived Router layer described above, combined with reference-graph-based Chain of Recall, primarily addresses on-demand retrieval of recent tasks and conversation history. When the operating period extends across months or even longer spans of time, long-term memory becomes the main bottleneck to scalability.
8.2 How to Collaborate with Agents Beyond the Session
The two-layer architecture described above hides the management of multiple underlying conversations from the user, so that the Session is no longer the primary concern in product design. But once the underlying execution Sessions no longer correspond directly to conversations in the user interface, a new question arises: how should tasks be presented to users, and what natural forms of interaction and project management should be offered? We believe that interaction centered on chat windows is, to some extent, a result of path dependence. More interaction might take place in interfaces tailored to particular domains—for example, as in this article’s examples, having Super-agent work directly in GitHub Issues and Pull Requests. Conversations can also remain in the interface to accommodate users’ habits, but one conversation that a user sees may not correspond to just one Session underneath.
Furthermore, the discussion above has focused primarily on human interaction at task initiation and acceptance of results. During this transitional period of rapid advances in model capabilities, however, many tasks still require human participation along the way. It is therefore also worth exploring how product design can balance users’ step-by-step intervention in key details with the efficiency of autonomous progress in the background—for example, by allowing users to intervene at any time during background execution, take over, or work with the Agent in real time.
Overall, the forms of project management and interaction users need are closely tied to their particular field of work and personal style. The eventual form is likely to be highly customized, and DeepSeek Harness’s open architecture makes it easier to support such customization.
8.3 How to Define Context Boundaries and Enable A2A Collaboration
The discussion above has concerned the internal design of a single Super-agent instance, assuming that information within its scope of service is brought together in one global context. But when usage expands from an individual or a small team to a larger organization, deciding how to deploy Super-agent is effectively a decision about where context should be shared and where it should be isolated. Groups that need to share context use the same instance; those that need isolation each have their own separate instance.
Taking this further, once multiple isolated instances exist within or across organizations—for example, each member’s personal assistant alongside the team’s shared Super-agent—collaboration across these boundaries becomes Agent-to-Agent communication (A2A, not referring to any particular protocol). How to achieve secure, reliable A2A communication and collaboration when the underlying contexts are not shared and each instance represents a different permission boundary remains an area for further exploration.
8.4 How to Ensure Security and Privacy
The event-driven design in Section 3 allows the Agent to be driven by a wider range of environmental inputs, but also increases its exposure to untrusted input. If security and privacy cannot be adequately addressed, Super-agent will be able to operate only within a very small, trusted scope.
For example, the design in Section 5 deploys the Agent Loop in the cloud and installs lightweight daemons on different execution devices. This design assumes mutual trust between the cloud and the device-side environments. But when the cloud-based Agent Loop continuously receives external environmental events, while the devices hold private code, sensitive data, and local credentials, this cross-device connection introduces significant security and privacy risks. If the cloud-based Agent Loop is compromised through a server-side intrusion or prompt injection, every device connected to it potentially faces the risk of being taken over.
Moreover, even if the cloud has not been compromised, credentials can still leak during normal execution if credentials from a device’s environment are able to enter the model’s context. Mechanisms are therefore also needed that let the Agent use credentials without ever coming into contact with the credentials themselves. For this architecture to see broader adoption, it must address these security and privacy issues while retaining the ability to recall context from diverse environments.
9. Conclusion
Looking back over the design as a whole, we have not proposed an entirely new theory. Instead, we have applied classic engineering ideas from computer systems to the construction of Agent systems. Specific implementations will evolve as technology advances, but we believe the underlying systems-design ideas will remain useful for longer. The internal Super-agent instance we have built on these ideas and DeepSeek Harness is already running continuously, participating in day-to-day problem reproduction and fixes, responses to code review, and iterations on DeepSeek Harness itself.
As noted at the beginning, as large models require less and less human intervention to execute individual tasks, the bottleneck to further productivity gains is shifting toward human attention. Through the two-layer architecture, event-driven operation, asynchronous multi-channel interaction, compute-storage separation, and an external Watchdog, the system takes over the tedious management of conversations and synchronization of context underneath, allowing people to move further away from execution details and toward higher-level decisions and acceptance of results.
In this form, the Agent is no longer merely a conversation window that passively waits for instructions. It evolves into an autonomous collaborator that stays continuously online in the digital environment. For individuals, it can be a personal assistant that helps with everyday matters across devices. For teams, it becomes part of the development workflow, taking on and advancing specific tasks. We believe that, as model capabilities and the underlying systems architecture evolve together, this more autonomous way of working has the potential to become the norm for human–agent collaboration.
Some of the designs in this article have been implemented in dsh-superagent-prototype (click “Read original” to visit the GitHub repository). This plugin is only a prototype provided to validate the technical approach; it is not an official DeepSeek product.
Author & Acknowledgements
This article grew out of the DeepSeek Harness team’s shared practice. Yujia Qiao implemented the system and wrote the article. Huanqi Cao, Zui Chen, Xieting Chu, Tianyi Cui, Shiyuan Feng, Yudong Han, Kexin Liu, Shichun Liu, Gesi Luo, Yifan Shi, Tongrui Xiong, Hanxiang Xu, C.C. Yu, Ziya Zhang, F. Zhou, and others participated in review and discussion and provided feedback. The implementation of the system and the development of this article would not have been possible without the team’s day-to-day exchanges and accumulated experience.
Source and Translation Note
This is an English translation of the complete article done by ChatGPT Astra, including its figure text, captions, experimental table, acknowledgements, and accompanying recruitment notice. Not verified by a human translator. Diagrams have been redrawn in English and figure numbers added for reference. The charts reproduce the original plotted curves and points with English labels; the two panels in Figure 14 have been stacked for readability.
DeepSeek Product Department
User Product Manager
Ecosystem / Growth Product Manager
Product Designer
Deep Learning Researcher
Product Operations
Developer Relations
Project Manager
Software Development Engineer in Test
Backend Software Engineer
Frontend Software Engineer
Mobile Software Engineer
Harness R&D Engineer
Work locations: Beijing / Hangzhou
Email subject: Name - Position - Contact information
