What Is DeepSeek Super-agent Design and How Does It Work?

This article explores architectural ideas from an engineering perspective. It is not an introduction to the existing product features of DeepSeek Harness.

Over the past year, single-task agents, particularly coding agents, have demonstrated that models can use tools to solve complex problems with less and less continuous human supervision 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, people’s role is gradually moving toward higher-level decisions and acceptance of results.

This improvement in model capabilities is also giving rise to new forms of applications. 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 always-on, event-driven mode of operation is not limited to personal use: personal assistants are just one application. It is equally valuable in commercial settings such as software development.

However, today’s mainstream agent designs still struggle to support this mode at the scale of multiple tasks and team collaboration. Agents continue to use a single Session as their basic unit of work, with different Sessions remaining 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 observation, one person can usually keep track of only three to five active Sessions at a time. Under this design, the ceiling for a single task is set by model capability; the ceiling for multiple tasks is set by 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 execution stopping whenever the local device goes offline. Considerable manual maintenance is still required.

To move beyond these limitations, we need to break the binding between an agent and a single manually initiated session. The agent should become a continuous entity that can retain context across sessions and advance several complex tasks at once without interference. We call this form of agent, and its system architecture, a Super-agent.

For example, in a Super-agent instance we run internally on DeepSeek Harness, the same development task can continue across instant messaging and GitHub. The instance also continuously monitors feedback in public group chats, proactively identifies root causes, and submits fix Pull Requests 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. It feels as though there is always just one agent, without users 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, the agent can understand the change and adjust its work accordingly.
• Efficiency: It responds quickly while completing multiple complex tasks in parallel and to a high standard. It can accept the next instruction without waiting for the previous command or task to finish.
• Proactivity: It continuously observes events in its environment and takes action on matters worth addressing, without waiting for users to issue every instruction. When no intervention is needed, it stays quiet.
• Persistence: It is always online, connects directly to users’ real working environments, and automatically recovers from exceptions encountered during long-running 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 an agent is a personal assistant or serves a commercial setting such as software development, building an always-on system that responds concurrently to environmental events may lead to similar underlying architectures. Many of the problems encountered along the way also closely resemble problems that traditional computer systems have studied for decades, making many classic systems design ideas applicable here as well.

Implementations of this architecture will vary. Nevertheless, we believe the following five modules form the basic framework supporting these four characteristics: a two-layer architecture balances continuous interaction with efficient concurrency (Section 2); event-driven operation enables proactive responses (Section 3); human-centered interaction provides both continuity and efficiency in communication (Section 4); and separation of compute, state, and environments (Section 5), together with a Watchdog (Section 6), enables persistent operation across devices and automatic recovery from exceptions.

The following diagram presents the overall Super-agent system architecture. Labels [2] through [6] correspond to Sections 2 through 6 below.

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.

Sending every event to the same Session provides the greatest continuity of context. But it is limited by the speed of a single ReAct Loop executing serially, resulting in long task completion times and low throughput. Mixing intermediate details from multiple tasks can also hurt the quality of the results.

Conversely, opening a new independent Session for every event maximizes concurrent throughput. But when tasks are not completely independent, the lack of global context leaves their results disconnected. Having multiple Sessions reply independently to the user also creates confusion.

To balance continuity and throughput, we can separate “maintaining global continuity” from “high-concurrency execution” into two different layers: a persistent Router layer handles human interaction and global coordination (Section 2.1), while a Worker layer executes specific tasks concurrently in isolated contexts (Section 2.2), as shown below.

With this two-layer architecture, the underlying system takes over context management and concurrent execution. Sessions become less visible to users, who always interact with the same Super-agent. From this perspective, making users manage Sessions manually is largely an inherited design habit from the underlying LLM APIs. Sessions should be an implementation detail of the system, not a cognitive burden for users.

In existing designs, a Session serves both technical context management and user-facing project management. Once the product experience is decoupled from the underlying Session, user-facing project management is no longer constrained by it. Deciding what interaction and task management experience to expose becomes a separate product question. We discuss this later in the article.

The “two layers” here describe a logical division of responsibilities. Neither layer has to be implemented as a single Session; each can have its own internal structure. We describe the Router and Worker layers below.

2.1 The Router Layer

The Router layer is a persistent global routing layer that handles human interaction from every entry point. Information and decisions spanning tasks are brought together here, making it the global sequence point, coordination point, and memory. To keep this global node from becoming a performance bottleneck, the Router layer is designed not to execute specific tasks itself. It only handles human interaction and task assignment; it may not even have a Bash tool.

This structure, in which a central node assigns work to multiple execution nodes, may look like a typical Agent Team, but the emphasis is different. A typical Agent Team is primarily used to break down steps and coordinate roles within a single complex task. Because those substeps are usually tightly coupled, the Team Lead often needs to understand the task in depth, plan subtasks, and coordinate team members frequently, taking on a substantial reasoning load. In a Super-agent, the Router layer handles only high-level relationships and assignments between tasks; it does not need to break down individual tasks internally. Conversely, if an Agent Team’s main session is constrained through prompting to avoid executing specific work itself, and instead only handles external interaction and assigns different tasks to members to advance independently, it can also be regarded as this kind of two-layer architecture. In our experience, the Router layer’s work is often less complex than it might appear. A lighter model can often provide both speed and good results.

Internally, the Router layer does not have to be a single Session either, and some of its logic may not require an LLM at all. We chose the most straightforward implementation: a single persistent LLM Session at its core. We found that it was less prone to becoming a throughput bottleneck than it might seem. Environmental events arriving during one round of inference—the Triggers introduced in Section 3—accumulate and are processed together in the next round. This creates batching, with little additional overhead from processing 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 bursts and queues start building up in the Router Session, multiple 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, with each step typically involving a long input and a short output. Combining queued Triggers into one LLM API call allows them to be computed in parallel during prefill. The duration of an individual request therefore grows much more slowly than the batch size. Within a certain range, the larger the backlog, the less inference time is amortized over each decision. The upper limit depends on context length and how many Triggers the model can accurately handle in one round.

Section 7.2 quantifies the effects of this batching mechanism through experiments. Combined with the subscription and direct-delivery mechanisms and Chain of Recall introduced later (Sections 3.2 and 3.3), a single persistent Router Session has been sufficient at our current team scale while preserving continuity of context.

If the scale grows further and a single session genuinely becomes insufficient, the Router layer could use a multilayer filtering structure or be horizontally partitioned—sharded—across multiple sessions. At that point, its internal design is fundamentally a trade-off between continuity and throughput. Finer-grained partitioning increases concurrent throughput in the Router layer but reduces continuity of memory and context across shards. Until the global memory problem is solved, this trade-off will remain.

2.2 The Worker Layer

The Worker layer consists of sessions responsible for execution. Each Worker is isolated from the others in terms of context and has a full set of execution tools, allowing it to focus on one task within its own context. Since Worker Sessions directly determine task outcomes and code quality, they usually need the most capable model available.

Workers do not interact directly with humans. Their reasoning and tool calls are not sent directly to external channels. Instead, they report their status to the Router layer, which replies to users on their behalf. This preserves concurrency and delivery quality while avoiding the confusion of multiple sessions replying independently.

When multiple tasks run concurrently, each Worker advances its task independently. Workers at the same layer generally 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 subscribe to the corresponding Thread, they receive the same event notifications (Section 3.2), giving them the opportunity to identify and resolve conflicts themselves. The Router layer relays the limited coordination needed across tasks.

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 itself be an Agent Team. These details remain transparent to the Router layer above it. This structure applies both to collaborative coding—where independent issue reproductions, Pull Request reviews, and feature development can proceed without blocking one another—and to personal assistants. Although a personal assistant’s interface usually presents a single-session chat page, a user may discuss several topics in the same conversation. The single chat page maintains continuity of interaction, while the system underneath can assign a separate Worker to each topic to advance tasks and draft replies in parallel.

For a Super-agent to be proactive, we first need to change what drives it. The main inputs driving the agent are no longer prompts typed by humans one at a time into a Session, but semistructured 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, the agent no longer has to wait passively for a human instruction before executing once, as it would in the single-Session model.

Following an environmental event through its lifecycle from arrival to processing, we discuss four successive questions: how to filter large amounts of noise with a two-stage strategy combining code and models (Section 3.1); how to route events to Workers through subscription and direct delivery (Section 3.2); how to use Inline & Spill and Chain of Recall to inject information-dense context and retrieve it on demand (Section 3.3); and how to use speculative execution to act in advance in the background based on environmental signals (Section 3.4).

3.1 Event Filtering

Once connected to real group chats and code platforms, the environmental event stream has a pronounced “high noise, low action rate” character: the vast majority of everyday messages do not require the agent to intervene. Calling a large model to assess every event from scratch would make both latency and compute costs difficult to sustain. Drawing on the Fast Path / Slow Path concept from computer systems, large-model inference can be treated as a flexible but expensive Slow Path. Encoding well-understood, stable, frequent decisions in deterministic code provides a low-latency, low-cost Fast Path.

The first step after events enter the system is therefore filtering. The goal is to remove noise using deterministic policies before invoking a large model, sending only candidate events that require semantic understanding to the model for judgment. We use a two-stage filtering mechanism combining programmatic policies with a large model:

• Programmatic policies—the Fast Path: Code performs quick admission checks against deterministic conditions such as event source, group scope, and user or bot allowlists. For example, different sources can be configured to “respond only to explicit requests,” “consider as candidate events,” or “ignore directly,” filtering out most irrelevant messages before the model is invoked.
• Semantic policies—the Slow Path: Candidate events admitted by the programmatic layer go to the LLM, which decides whether to act based on policies written in prompts and on context. The semantic layer also serves as a natural-language extension point for humans, making it easy to enable, disable, or add policies through prompts, as shown below.

3.2 Event Routing

The global Router layer introduced in Section 2 maintains continuity across channels. But if every follow-up event for an assigned task still has to be forwarded through it, this global node will remain heavily loaded, increasing system response latency. The Fast Path / Slow Path idea therefore applies to routing filtered events as well. The global Router layer is responsible only for starting new tasks and coordinating across tasks. Once ownership has been established, code sends subsequent events directly to the corresponding Worker Session, without forwarding them through the Router layer.

In real workflows, successive events under the same GitHub Pull Request, IM topic, or email conversation form an event stream: a Thread.

After the Router layer creates a Worker Session from a Thread’s initial event, that Worker subscribes directly to the Thread. Event routing is then divided into the two paths shown below:

• Subscribed—the Fast Path: Subsequent events in the same Thread are delivered directly by code to the subscribed Worker. The Router layer does not need to call a tool to forward them again. If a new event falls outside the scope of the current task, the Worker can unsubscribe or return it to the Router layer for reassignment.
• Unsubscribed—the Slow Path: The Router layer can still observe all events to maintain a global view, but it only needs to assess and assign new events that have not yet been subscribed to.

The subscription relationship between Threads and Workers is many-to-many. A Worker can subscribe to several related Threads, and a Thread can have multiple subscribed Workers. When Workers cross paths in the same work environment or discussion, new events in that Thread are delivered directly to all its subscribers. Without point-to-point communication, they can learn about one another’s actions and have the opportunity to resolve conflicts themselves. On the output side, Workers still report key conclusions to the Router layer, which replies to users and updates global memory.

3.3 Context Organization

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 system inputs shift from a limited set of human prompts to a continuous stream of semistructured environmental events, the structure of tool calls and event injection becomes more important. Injecting too much consumes the window and dilutes the model’s attention. Injecting too little forces repeated tool calls to retrieve information, 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 additional tool-call round trips. Spill means leaving complete information that exceeds the window budget or is used infrequently outside the window, retaining only references or summaries inside it so the model can read it on demand.

Combining Inline & Spill with the classic systems principle of locality, we can progressively optimize event injection and tool calls:

• Start with minimal information: Initially provide only the current object’s ID and a summary of its content.
• Gradually Inline related information using locality: Inline information likely to be needed soon. First attach the IDs of closely related objects, then content that is nearby in time or structure—for example, the first 50 characters of the content, messages before and after an IM message and the message it replies to, or adjacent comments in the review discussion containing a code comment.
• Spill when the limit is exceeded: Set a small length limit for long content that cannot be fully Inlined, and Spill the remainder outside the window. A straightforward implementation truncates the excess while retaining an entry point for continued reading. The model can call a tool to retrieve the full content when needed.

In addition, once many follow-up events are delivered directly to Workers and the system has accumulated a long history of tasks, the Router layer cannot keep the full history of every task in its own context window. Yet it still needs to recover context when a user refers to an old task through another channel. Applying Inline & Spill consistently to the system’s different object types gives us an on-demand, multihop retrieval mechanism: Chain of Recall. This process helps address the Router layer’s loss of earlier information over long periods, as illustrated 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 reference graph. Each object recalled through a tool call follows the same Inline & Spill approach, so its returned data includes summaries and IDs of related objects for the next hop. Starting from the current event, the model can follow these references to recall context progressively as needed.

For example, it can read the Thread containing a current message, follow an ID inlined in the Thread to the associated Worker Session, and then find another code review Thread associated with that Worker.

3.4 Acting in Advance

Drawing on speculative execution in computer systems, an agent can act in the background based on environmental signals before it is certain that the result will be used. It spends additional background compute to reduce human waiting time and intervention. If the result is valuable, it delivers it; otherwise, it discards it.

For a personal assistant, receiving a meeting invitation email or a to-do message could trigger background checks for calendar conflicts, collection of relevant background information, and preparation of a reply draft. Once the user reviews it, they can confirm and send it immediately. The same applies to collaborative development. For example, we configured a “silently reproduce and fix” policy in our company’s internal DeepSeek Harness user group. When someone reports a problem or discusses a proposed change, the agent first attempts reproduction and looks for a fix in the background. It delivers the result only after confirming the problem and finding a simple fix; otherwise, it remains quiet throughout.

The two-layer architecture in Section 2 ensures continuity of context across channels. But achieving both continuity and efficiency in actual human-agent interaction requires solving two further problems involving interaction methods and channels. First, an asynchronous ReAct Loop must remove the blocking effect of slow background operations on foreground conversation, allowing a session to accept new instructions without waiting for the previous command or task to finish (Section 4.1). Second, when interaction happens across familiar work channels, the system’s output must match each channel’s bandwidth and people’s usage habits (Section 4.2).

4.1 Full-Duplex Interaction

In a classic ReAct Loop, once the model makes a synchronous run() tool call, the loop blocks until the tool finishes executing and returns its final result. During that period, the session cannot respond to new user input. Removing this blockage requires moving conversation from a half-duplex, question-and-answer mode to a full-duplex mode, as illustrated below.

To achieve this, we replace time-consuming command and subtask tool calls with asynchronous start() and stop() operations, creating an asynchronous ReAct Loop. After calling start(), the model immediately receives a “Started” response, and the loop no longer waits for the tool. When the background tool finishes, the system delivers its final result to the session as a new event message. The model can also call stop(), based on context, to terminate background commands that have been running too long.

This decouples foreground conversation from background task execution. The agent can respond to human input while running time-consuming tasks in the background. New input is handled as soon as the current inference step ends, without waiting for background tools to finish.

This asynchronous task mechanism has already been implemented in DeepSeek Harness, but it is not yet enabled by default.

4.2 Interaction Across Channels

Different work channels have different information densities and interaction conventions, and the system’s output must match them. Moving an interface designed for a single-user terminal directly into a group chat—reproducing long reasoning traces and frequent tool calls verbatim—can easily overwhelm people collaborating in a group.

In a Super-agent, the two-layer architecture already solves part of this problem. Long reasoning traces and frequent tool calls for specific tasks are isolated inside Worker Sessions rather than sent directly to external channels. The Router layer handles external interaction centrally. On top of this, the system needs to connect to the work environments people use every day and use prompts to tailor interaction conventions to each channel:

• 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 to keep each reply to no more than 100 words.
• Asynchronous channels such as GitHub, email, and documents: Emphasize structured delivery with a high information density. For example, when creating or updating a Pull Request, write a complete account of the problem, changes, and validation results according to the project’s conventions. In a personal-assistant setting, draft structured emails and document summaries directly.

Existing local agents bind together, on the same device, the compute that advances the Agent Loop, the session 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 cannot access environments on other devices. To make a Super-agent persistently available and flexible enough to connect to different real working environments, we can borrow the idea of compute-storage separation from computer systems and decouple these three elements in two steps. First, separate the compute that advances the Agent Loop from persistent session state, freeing the agent from the lifecycle of a single machine and enabling continuous operation in the cloud (Section 5.1). Then decouple the cloud-based Agent Loop from state-heavy execution environments, leaving real working environments where they are while supporting access across devices (Section 5.2).

5.1 Separating Compute from State

The compute that advances the Agent Loop can be stateless; what needs to be persisted is session state. The first layer of decoupling therefore places this compute in stateless, elastic containers in the cloud, while storing persistent state such as Sessions in a database. Stateless compute containers can scale horizontally, restart, or be replaced. Persistent storage preserves continuity of sessions and tasks, freeing the agent from the lifecycle of any single local device and enabling it to remain continuously online in the cloud.

5.2 Separating Compute from Execution Environments

Once the Agent Loop and session state reside persistently in the cloud, the next question is how to access the execution environments tasks require. Much of the context a model needs for its work must be obtained through tool calls into code repositories, local files, dependent services, and other parts of an execution environment. In this broader sense, context includes the execution environment itself.

There are two common approaches. One is to launch a sandbox in the cloud, pull the code, and try to reconstruct and synchronize the environment. But real working environments often contain uncommitted local changes, private credentials, dependencies on internal network services, and specific hardware or toolchains. Synchronizing such environments is technically expensive and prone to omitting information. The other approach is to ask users to abandon their local environments and move their work to the cloud, but the migration cost is too high for many users.

If the environment itself is what is difficult to copy and synchronize, there is no need to move it to the cloud alongside the Agent Loop. The second layer of decoupling lets the Agent Loop run in the cloud while leaving state-heavy execution environments in place. A lightweight daemon on the device stores no session state and is responsible only for executing commands and returning results. In effect, the execution environment remains outside the cloud, and the agent reads context from it on demand.

This aligns with Anthropic’s idea of “decoupling the brain from the hands”: keeping the harness stateless, storing session logs outside it, and connecting to execution environments on demand through a unified interface. The difference lies in the setting. That article describes a managed service, mainly discussing sandboxes created on demand and resources inside customers’ VPCs. Here, the first environments to connect are the personal machines people use every day, which may be online only intermittently and contain uncommitted changes and local credentials. This design therefore supports both BYOM—Bring Your Own Machine, connecting a user’s everyday development machine or personal computer to a cloud agent—and cloud-hosted machines or compute environments created on demand.

An agent is consequently no longer limited to one machine. It can switch between execution devices, choosing an environment based on the task to execute commands and retrieve context. It can even support intermittently connected devices: after a user’s personal device comes back online, the cloud agent can automatically trigger and complete tasks that need to run there. The following diagram shows the two layers of decoupling between compute, persistent state, and different execution environments.

Persistent operation requires more than the compute-storage separation described in Section 5. The system also needs to recover automatically from exceptions over long periods of operation. It is difficult for an always-on distributed system to remain reliable over time using only its own internal logic. An independent external control loop is needed outside the main system.

In an agent system, traditional process-liveness probes or monitoring scripts are not enough. Many failures do not involve a process crashing; instead, the model gets stuck in an unproductive loop or drifts away from its objective. A long-running agent system must therefore monitor progress on the tasks themselves, not just infrastructure liveness.

We configured an independent Watchdog Session outside the main system, driven by scheduled messages to form an external control loop. In addition to addressing infrastructure failures such as API errors and failed state restoration, the Watchdog uses a model to judge whether Workers are making substantive progress and whether they have deviated from the overall objective. When it detects an exception, it intervenes promptly to repair it. For intermittent external failures, it keeps checking until normal operation resumes.

Because the Watchdog is itself an Agent Session with a full set of tools, maintainers can ask it about failures in natural language. They can also ask it to modify the main system’s behavior while it is running, for example by adding or removing prompts or adjusting trigger rules.

To evaluate the core scheduling and routing designs above, we conducted preliminary experiments at two levels. First, we used end-to-end experiments to compare the two-layer architecture and subscription-based direct delivery against 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, and some aspects of their setup could be made more rigorous, the results below should be treated only as preliminary reference points.

7.1 Ablation Study

We drove four end-to-end approaches with streams of group chat and GitHub CI messages. Each experiment contained roughly 300 messages, about 20 of which were work requests; the rest were casual conversation, follow-ups, stop requests, and CI messages. Coding work was replaced with a tool that only consumed time, so the experiment measured system scheduling and coordination rather than the ability to execute individual tasks. Each approach was run five times.

The four approaches 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...”

Note: Each approach was run five times. Task completion time is the elapsed time from the work request to the result message.

For task completion time, Super-agent achieved a p50 of 12.4 minutes and a p95 of 15.7 minutes, substantially better than the single Session with a Subagent tool. The reason is that, in this experimental setting, the single Session with Subagents was strongly affected by prompting. The main Session often chose to execute tasks itself, resulting in long overall completion times and unstable performance. Under the neutral prompt, the model did not invoke a Subagent in any of the five runs. All work took place in the main Session and was repeatedly interrupted by new messages, with p95 reaching 29.5 minutes. Under the delegation-first prompt, the model delegated in four of five runs, reducing completion times, though it remained slower overall than Super-agent. In the remaining run, it 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 moment-to-moment judgment about delegation within a single Session, the two-layer architecture alleviates this problem at the system level: the Router does not execute specific work, and Workers receive messages only from the Threads they subscribe to.

In terms of system overhead, maintaining multiple independent sessions meant that Super-agent used more cache-read tokens per experiment than the single-Session approach. It traded additional token consumption for shorter, more stable completion times. Removing direct delivery from Super-agent left task completion times essentially unchanged, but increased the number of decisions the Router had to make by approximately 30%. Total cache-read tokens per experiment rose from 23.23 million to 31.77 million, an increase of approximately 37%. Under this workload, direct delivery did not improve task completion quality or speed, but it saved the Router Session a considerable amount of token consumption and inference overhead.

7.2 Batching in the Router Layer

To evaluate the throughput limit and batching mechanism of the single persistent 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, duration of an individual request, and inference time amortized over each decision.

As shown in the figure, when the arrival rate of Triggers requiring a decision increased from approximately one to approximately 40 per minute, the average batch size rose from 1.0 to 2.8. Individual request duration increased only from 2.5 to 3.9 seconds, growing more slowly than batch size. As a result, inference time amortized over each decision fell from 6.4 to 1.6 seconds. This means that when external events arrive in bursts and queues build up, the Router layer can improve effective throughput by automatically combining queued events. It also explains why removing direct delivery in Section 7.1 increased the Router’s peak load without reaching the throughput bottleneck of a single Router. At our current team scale, there is therefore no need to shard the Router layer prematurely at the expense of global continuity of context.

The five modules introduced in Sections 2 through 6 form the basic architecture supporting Super-agent. The experiments in Section 7 also demonstrated the effects of its core scheduling and routing mechanisms under concurrent multitask workloads. The system can operate with relatively little complexity largely because of a series of engineering and scenario simplifications we have made at this stage. Beyond the scope of those simplifications, open questions remain about scaling the two-layer architecture (Section 8.1), human-agent collaboration beyond Sessions (Section 8.2), context boundaries and A2A (Section 8.3), and security and privacy (Section 8.4).

8.1 How Should the Two-Layer Architecture Scale?

The simplified combination of “one persistent Router Session + subscription-based direct delivery + no direct communication between Workers” covers most of our current everyday tasks at relatively low engineering cost. But as tasks grow in scale and become more tightly coupled, they may exceed the capacity of a single Router Session. There is no definitive answer for the internal structure of each layer: when to shard the Router layer, how finely to partition it, when to introduce direct communication between Workers at the same layer, and which collaboration topology to use all need to be tested in more settings. System-model co-design is also worth exploring. Targeted training for tasks such as event assessment, batch assignment, and context recall in the Router layer could further improve its throughput and decision-making performance.

Meanwhile, the persistent Router layer and reference-graph-based Chain of Recall described earlier primarily address on-demand retrieval of recent tasks and session history. When operation extends across months or longer, long-term memory becomes the main bottleneck to scalability.

8.2 How Should People Collaborate with Agents Beyond Sessions?

The two-layer architecture hides the underlying management of multiple sessions from users, so Sessions no longer need to be the primary consideration in product design. But once execution sessions no longer correspond directly to conversations in the user interface, a new question emerges: how should tasks be presented, and what interaction and project management experience would feel natural? We believe that chat-window-centered interaction is, to some extent, a result of path dependence. More interaction could happen in domain-specific interfaces—for example, a Super-agent could work directly in GitHub Issues and Pull Requests, as in the examples in this article. Sessions could also remain in the interface to accommodate users’ habits, but one conversation visible to a user need not correspond to just one underlying Session.

So far, we have mainly discussed human interaction when initiating tasks and accepting results. During this transitional period of rapidly evolving model capabilities, however, many tasks still need human involvement along the way. It is also worth exploring how product design can balance users’ incremental intervention in important details with the efficiency of autonomous background work—for example, by letting users intervene, take over, or collaborate with an agent in real time while it works in the background.

Overall, the project management and interaction experiences users need are closely tied to their domain of work and personal style. The eventual form is likely to be highly customized. DeepSeek Harness’s open architecture also makes it easier to support this kind of customization.

8.3 How Should Context Boundaries Be Defined, and How Should A2A Collaboration Work?

Our discussion so far has concerned the internal design of a single Super-agent instance, assuming that all information within its scope is brought together in one global context. But when use expands from an individual or small team to a larger organization, deciding how to deploy Super-agents is effectively a decision about the boundaries of context sharing and isolation. Areas that need to share context use the same instance; areas that need isolation use separate instances.

Taking this further, once multiple isolated instances exist within or across organizations—for example, members’ personal assistants alongside a shared team Super-agent—collaboration across those boundaries becomes agent-to-agent communication, or A2A, without referring to any particular protocol. How to achieve safe, reliable A2A communication and collaboration when agents do not share their underlying context and represent different permission boundaries remains an open question.

8.4 How Can Security and Privacy Be Protected?

The event-driven design in Section 3 lets the agent be driven by a wider range of environments, but it also increases exposure to untrusted inputs. Unless security and privacy problems can be adequately addressed, a Super-agent will be able to operate only within a small, trusted scope.

For example, deploying the Agent Loop in the cloud and installing lightweight daemons on execution devices, as described in Section 5, assumes mutual trust between the cloud and device-side environments. But when the cloud-based Agent Loop continuously receives external environmental events, while connected devices hold private code, sensitive data, and local credentials, these cross-device connections introduce significant security and privacy risks. If the cloud-based Agent Loop is compromised through a server intrusion or prompt injection, every connected device could potentially be taken over.

Furthermore, even if the cloud has not been compromised, credentials can still leak during normal execution if credentials from device-side environments can enter the model’s context. Mechanisms are therefore needed that allow the agent to use credentials without ever coming into contact with the credentials themselves. For this architecture to reach broader adoption, it must address these security and privacy problems while retaining the ability to recall context from diverse environments.

Looking back at the design as a whole, we have not proposed a new theory. Instead, we have applied classic engineering ideas from computer systems to building agent systems. Specific implementations will evolve with technology, but we believe the underlying systems design ideas will remain useful over a longer period. The internal Super-agent instance we built using these ideas and DeepSeek Harness is already running continuously. It participates in everyday issue reproduction and fixes, responses to code reviews, and development of DeepSeek Harness itself.

As noted at the beginning, large models increasingly need less human intervention to execute individual tasks, and the bottleneck to further productivity gains is shifting toward human attention. Through a two-layer architecture, event-driven operation, asynchronous interaction across channels, compute-storage separation, and an external Watchdog, the underlying system takes over tedious session management and context synchronization. This allows people to move further away from execution details and toward higher-level decisions and acceptance of results.

In this form, an agent is no longer merely a chat window passively waiting 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 handle everyday affairs across devices. For teams, it integrates into development workflows, taking on and advancing concrete tasks. We believe that as model capabilities and underlying system architectures evolve together, this more autonomous way of working could 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.

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 reviews and discussions and provided feedback. Both the implementation of the system and the development of this article depended on the team’s day-to-day exchanges and accumulated experience.