The DeepSeek Harness team publishes a technical article on Super-agent design exploration

Main text

On the evening of October 31, the DeepSeek Harness team published a technical article on its official WeChat account titled "Super-agent Design Exploration: Toward a More Autonomous Agent System."

DeepSeek stated that improvements in model capabilities have given rise to new application forms, with personal assistants (Personal Agents) beginning to emerge in concentrated numbers. However, existing mainstream Agent designs still struggle to support this model at the scale of multitasking and team collaboration, where the multitasking ceiling depends on human attention. Through approaches such as a dual-layer architecture, event-driven design, asynchronous multi-channel interaction, separation of storage and compute, and an external Watchdog, the DeepSeek team has overcome these limitations; the system takes over tedious session management and context synchronization at the underlying level, allowing humans to move further up from concrete execution details to higher-level decision-making and acceptance.

DeepSeek calls this Agent form and its system architecture Super-agent. The article notes that, at present, an internal Super-agent instance built on this approach is already running continuously, participating in day-to-day issue reproduction and fixing, code review responses, and iteration on DeepSeek Harness itself. When team members report software issues in a group chat, even if no one actively @-mentions the AI, it can identify potential defects and attempt in the background to reproduce the issue and find a fix.

Full text

Super-agent Design Exploration: Toward a More Autonomous Agent System

This article is an architecture discussion aimed at engineering practice, not an introduction to the existing product features of DeepSeek Harness.

1. Super-agent

Over the past year, single-task Agents represented by Coding Agents have proven that models can use tools to solve complex problems and increasingly require less continuous human monitoring and step-by-step intervention. At the same time, models' multi-Agent collaboration capabilities are also improving, making cross-session organization and scheduling feasible. As human involvement in underlying execution decreases, the human role is gradually moving up to higher-level decision-making and acceptance.

This improvement in model capabilities has also given rise to new application forms. Recently, personal assistants (Personal Agents) have begun to emerge in concentrated numbers, directly connecting to everyday messaging, calendar, email, and work platforms, continuously observing information flows and assisting with tasks. This continuously online, event-driven working mode is not limited to personal scenarios; personal assistants are just one category of application. In commercial scenarios such as software development, it is equally valuable.

However, existing mainstream Agent designs still struggle to support this model at the scale of multitasking and team collaboration. The Agent's working mode is still based on a single Session as the basic unit, and different Sessions are independent of one another. When users advance multiple tasks in parallel, they must manually switch between and remember the context of each Session, and based on our observations, a person can typically follow only 3 to 5 active Sessions at the same time. Under this design, the ceiling for a single task depends on model capability, while the ceiling for multitasking depends on human attention.

If one simply extends existing local single-session Agents through CLI, MCP, or external connectors, the Agent can connect to external messages, but it remains constrained by problems such as synchronous blocking within a single session, chaotic multitasking context, and stopping when the local device goes offline, requiring extensive manual maintenance.

To break through these limitations, it is necessary to break the binding between the Agent and a single manual session, making it a continuous entity that can maintain context across sessions and advance multiple complex tasks simultaneously without interfering with one another. We call this Agent form and its system architecture Super-agent.

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

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

Specifically, we believe a Super-agent has the following four basic characteristics:

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

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

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

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

A single ReAct Loop cannot simultaneously support the four characteristics above; the underlying system requires a corresponding architecture. Similar design constraints lead to similar architectural choices. We believe that whether for a personal assistant or an Agent for commercial scenarios such as software development, if the goal is to build a system that is continuously online and responds concurrently to environmental events, then similar architectures are likely to be adopted at the underlying level. At the same time, many of the problems encountered in this process are highly similar to problems long discussed in traditional computer systems, so many classic design ideas from computer systems also apply here.

In concrete implementation, this architecture will have different variants, but we believe the following five modules constitute the basic framework that supports the four foundational characteristics above: through a two-layer architecture (Section 2), it balances continuous interaction and efficient concurrency; through event-driven design (Section 3), it achieves proactive response; through human-oriented interaction (Section 4), it achieves both continuity and efficiency during interaction; and through the separation of computation, state, and environment (Section 5) and the Watchdog (Section 6), it achieves persistent online operation across devices and automatic recovery from anomalies.

The figure below shows the overall system architecture of Super-agent. The module labels [2] to [6] in the figure correspond respectively to Sections 2 to 6 below:

Overall system architecture of Super-agent, with labels [2] to [6] corresponding to Sections 2 to 6 below

2. Two-Layer Architecture

To simultaneously achieve continuous interaction across channels and efficient concurrency of multiple tasks, the system faces a fundamental trade-off between continuity and throughput in its underlying session organization.

If every event is handled by the same Session, then although the context is the most continuous, it is limited by the serial execution speed ceiling of a single ReAct Loop: tasks take a long time to complete, throughput is low, and the intermingled intermediate details of multiple tasks also affect completion quality.

Conversely, if every event directly opens an independent Session for handling, then although concurrent throughput is highest, once tasks are not fully independent, the lack of global context causes the results of different Sessions to be fragmented from one another, and multiple Sessions each responding to the user also causes interaction chaos.

To balance continuity and throughput, we can split "maintaining global continuity" and "high-concurrency execution" into two different layers: a resident Router layer (Section 2.1) uniformly handles human interaction and global coordination, while a context-isolated Worker layer (Section 2.2) executes concrete tasks concurrently, as shown in the figure below:

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

Through this two-layer architecture, the system takes over context management and concurrent execution at the underlying level, thereby de-emphasizing the existence of Sessions on the user side, so that what the user faces is always the same Super-agent. From this perspective, having users manually manage Sessions is largely a design inertia inherited from the underlying LLM API; Sessions should be an implementation detail of the system, not a cognitive burden for users.

In existing designs, Sessions simultaneously carry technical context management and user-facing project management. After decoupling the product form from the underlying Session, user-facing project management is no longer constrained by Sessions, and what kind of interaction and task management to expose to users becomes an independent product question. We will discuss this question later.

The "two layers" here are a logical division of responsibilities; in implementation, each layer need not be limited to a single Session and can have its own internal structure. Below we introduce the designs of the Router layer and the Worker layer respectively.

2.1 Router Layer

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

This structure, in which a single central node dispatches to multiple execution nodes, superficially resembles a common Agent Team, but the two have different emphases. A common Agent Team is mainly used for step decomposition and role collaboration within a single complex task; because the sub-steps are usually tightly coupled, the Team Lead often needs to deeply understand task details, plan sub-tasks, and coordinate members at high frequency, thus bearing a heavy reasoning load itself. In a Super-agent, by contrast, the Router layer only handles high-level associations and dispatch among tasks and does not need to intervene in decomposition within a single task; conversely, if prompts are used to constrain an Agent Team's main session not to personally execute concrete tasks but only to handle external interaction and dispatch different tasks to members to advance independently, then it too can be regarded as this two-layer architecture. In our practice, the tasks at the Router layer are often less complex than imagined, and a lighter-weight model is often enough to balance speed and effectiveness.

In terms of internal implementation, the Router layer likewise need not be limited to a single Session, and some logic may not even require calling an LLM. We chose the most direct approach—a single resident LLM Session—as the core implementation of the Router layer, and found that it is not as likely to become a throughput bottleneck as it superficially appears, because environment events arriving during the previous round of inference (i.e., the Triggers in Section 3) accumulate and are processed together in the next round, forming batching, and the extra overhead of merged processing is very small:

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

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

We will quantitatively demonstrate the effect of this batching mechanism through experiments in Section 7.2. Together with the subscription and pass-through mechanisms and chained recall to be introduced later (see Sections 3.2 and 3.3), a single resident Router Session, while maintaining context continuity, is already sufficient at our current team scale.

When the scale expands further and a single session is truly insufficient to carry the load, the Router layer can also be designed internally as a multi-layer filtering structure, or horizontally sharded into multiple sessions. In this case, the internal design of the Router layer is essentially a trade-off between continuity and throughput. The finer the sharding granularity, the higher the concurrent throughput of the Router layer, but the lower the memory and context continuity between shards. Before the global memory problem is solved, this trade-off will always exist.

2.2 Worker Layer

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

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

When multiple tasks are executed concurrently, each Worker advances its task independently, and Workers at the same layer usually do not need to communicate directly with one another. Conflicts among multiple Workers in concrete execution often arise in shared working environments such as the same Pull Request; as long as they have all subscribed to the corresponding Thread, they will receive the same event notifications (see Section 3.2), giving them the opportunity to discover and resolve conflicts on their own, while the few cross-task coordinations are relayed through the Router layer.

Similar to the Router layer, each Worker Session need not be limited internally to a single session: when executing a complex single task, a Worker can internally create Subagents, or can itself be an Agent Team, and these remain transparent to the Router layer above. This structure applies both to code collaboration scenarios (advancing multiple independent problem reproductions, Pull Request reviews, and feature development simultaneously without blocking one another) and to personal assistant scenarios: although a personal assistant usually provides only a single-session chat page in the interface, when the user discusses multiple different topics simultaneously in the same dialog box, the single front-end chat page maintains the continuity of interaction, while the underlying layer can dispatch a separate Worker for each topic to advance tasks and draft replies in parallel.

3. Event-Driven

To make a Super-agent proactive, the first step is to change how the system is driven. The main input driving the Agent is no longer prompts typed one by one by a human within a Session, but rather semi-structured events in the environment. In a Super-agent, environmental events such as group chat messages, email and calendar reminders, code review comments, and CI run results are called Triggers. By listening for and responding to Triggers, the Agent no longer has to passively execute once only after a human issues a command, as in single-Session mode.

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

3.1 Event Filtering

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

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

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

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

Two-level filtering: program-layer strategies first screen out most irrelevant messages, which are then judged by semantic-layer strategies

3.2 Event Routing

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

In actual workflows, consecutive events under the same GitHub Pull Request, the same IM topic, or the same email thread constitute an event stream, i.e., a Thread:

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

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

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

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

3.3 Context Organization

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

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

Combining the classic Locality idea from computer system design, we can use Inline & Spill to progressively optimize event injection and tool calls:

Start with minimal information: initially provide only the ID and content summary of the current object.

Use locality to progressively Inline related information: Inline information likely to be used in the near term into the context, first attaching the IDs of closely related objects, then attaching spatiotemporally adjacent content, such as the first 50 characters of the content, the preceding and following messages of an IM message and the message it replies to, or adjacent comments in the review discussion where a code comment resides.

Spill when exceeding the limit: set a smaller length limit for long content that cannot be fully Inlined, and Spill the excess outside the window. A simple and direct approach is to truncate the excess and retain an entry point for continued reading, so that the model can call a tool to read it when the complete content is needed.

In addition, after a large number of subsequent events pass directly to Workers and the system has accumulated many historical tasks over long-term operation, the Router layer can neither put the full history of all tasks into its own context window nor fail to retrieve context when a user mentions an old task across channels. By consistently applying Inline & Spill to various objects in the system, we obtain an on-demand unfolding multi-hop retrieval mechanism, namely Chain of Recall. This chain-of-recall process alleviates the problem of the Router layer losing prior information over the long range, as shown in the figure below:

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

Specifically, the system assigns unique IDs to objects such as Triggers, Threads, and Worker Sessions, and inlines the IDs of closely related objects at injection time, so that these objects form a reference graph at the underlying level. Since objects recalled by each tool call also follow Inline & Spill, their returned results in turn inline the summaries and IDs of next-hop related objects, so the model can start from the current event and progressively recall context on demand along reference relationships.

For example, read the Thread containing a current message, then trace from the ID inlined in the Thread to the related Worker Session, and further find another code review Thread associated with that Worker.

3.4 Acting in Advance

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

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

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

4. Human-Oriented Interaction

The two-layer architecture in Section 2 ensures cross-channel continuity at the context level, but to achieve both continuity and efficiency in the actual human-computer interaction experience, two issues still need to be solved in interaction methods and interaction channels: first, how to eliminate the blocking of foreground conversation by time-consuming background operations through an asynchronous ReAct Loop, so that a session can accept new instructions at any time without waiting for the previous command or task to complete (Section 4.1); second, when interaction occurs in different work channels familiar to the user, how to make the system's output method match the bandwidth of the corresponding channel and people's usage habits (Section 4.2).

4.1 Full-Duplex Interaction

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

Comparison of the classic ReAct Loop and the asynchronous ReAct Loop: an asynchronous call immediately returns a Started notification, and new messages can still be responded to while the background tool is running.

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

As a result, foreground conversation responses and background task execution are decoupled, and the Agent can respond to human input while running time-consuming tasks in the background. New input is processed as soon as the current reasoning step ends, without waiting for the background tool to complete.

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 habits, and the system's output needs to match them. If interaction methods designed for a single-person terminal are directly carried over into group chats, outputting lengthy reasoning processes and dense tool calls as-is, it is very easy to cause information overload in multi-person collaboration.

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

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

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

5. Separation of Compute, State, and Environment

Existing local Agents by default bind the computation that advances the Agent Loop, the session state that needs to be persistently stored, and the execution environment such as code repositories and local toolchains to the same device. Once the device sleeps or goes offline, the Agent stops running and cannot access environments on other devices. To enable Super-agent to stay persistently online and flexibly connect to various real work environments, we can draw on the idea of Compute-Storage Separation in computer systems and decouple these three bindings in two steps: the first step is to separate the computation that advances the Agent Loop from the persistent session state, freeing the Agent from the lifecycle constraints of a single machine and achieving persistent cloud-based online operation (Section 5.1); the second step is to decouple the cloud-based Agent Loop from the state-heavy execution environment, leaving the real work environment in place and supporting cross-device access (Section 5.2).

5.1 Separation of Compute and State

The computation that advances the Agent Loop can be made stateless; what needs to be persistently stored is the session state. Therefore, the first layer of decoupling is to place the computation that advances the Agent Loop into stateless elastic compute containers in the cloud, while storing persistent state such as the Session in a database. Stateless compute containers can be horizontally scaled, restarted, or replaced, while the continuity of sessions and tasks is guaranteed by persistent storage, thereby freeing the Agent from the lifecycle constraints of a single local device and achieving persistent cloud-based online operation.

5.2 Separation of Compute and Execution Environment

After the Agent Loop and session state reside permanently in the cloud, the further question is how to access the execution environment required by tasks. A large part of the context needed for the model's work must be obtained through tool calls from execution environments such as code repositories, local files, and dependent services. In this sense, context in the broad sense also includes the execution environment itself.

Around this issue, there are two common approaches: one is to start a sandbox in the cloud, pull the code, and try to rebuild and synchronize the environment; however, because real work environments often contain uncommitted local changes, private credentials, intranet service dependencies, and specific hardware or toolchains, technically synchronizing such an environment is not only very costly but also prone to information omissions; the other is to directly require users to abandon their local environment and move to working in the cloud, but for many users the migration cost is too high.

Since what is difficult to replicate and synchronize is the environment itself, there is no need to make the execution environment follow the Agent Loop into the cloud. The second layer of decoupling is to let the Agent Loop run in the cloud while leaving the state-heavy execution environment in place, deploying only a lightweight daemon on the device side that does not store session state; it is responsible only for executing commands and returning results, which is equivalent to leaving the execution environment outside the cloud, with the Agent reading the context within it on demand.

This approach is consistent with the "Decoupling the brain from the hands" proposed by Anthropic, which likewise keeps the harness stateless, stores session logs outside the harness, and connects to execution environments on demand through a unified interface. The difference between the two lies in the scenario. That article describes a managed service, mainly discussing sandboxes created on demand and resources within the customer's VPC; here, what must first be connected are the personal machines that users use daily and that may be intermittently online, which hold uncommitted changes and local credentials. Therefore, this design supports both BYOM (Bring Your Own Machine), that is, connecting the development machine or personal computer that a user uses daily to a cloud Agent, and also supports connecting to cloud-hosted machines or compute environments created on demand.

As a result, an Agent is no longer limited to a single machine, but can switch between different execution devices, choosing an environment according to task needs to execute commands and obtain context from that environment. It can even support intermittently online devices; for example, after one of the user's personal devices comes back online, the cloud Agent can automatically trigger and complete the tasks that need to be executed on that device. The figure below shows the structure after compute, persistent state, and various execution environments are decoupled into two layers:

Separation of storage and compute and decoupling of execution environments: the Agent Loop and persistent state are separated in the cloud, and various execution environments are connected on demand through a device-side daemon

6. Watchdog

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

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

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

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

7. Preliminary Experiments

To evaluate the core scheduling and routing design described above, we conducted preliminary experiments at two levels: first, an end-to-end experiment comparing the two-layer architecture, subscription passthrough, and the single-Session approach (Section 7.1), followed by a separate test of batching at the Router layer (Section 7.2). Because the experiments are based on synthetic load and a simplified environment, some settings could be made more rigorous; the following results serve only as a preliminary reference.

7.1 Ablation Experiment

We used a group chat and a GitHub CI message stream to simultaneously drive four end-to-end approaches: a single experiment contains about 300 messages, of which about 20 are work requests and the rest are chitchat, follow-ups, stop requests, and CI messages. Coding work is replaced by a tool that only consumes time, so the experiment measures the system's scheduling and collaboration capabilities rather than its ability to execute an individual task. Each approach was run 5 times.

The four compared approaches include Super-agent, Super-agent with passthrough removed, and single Session + Subagent tool under two prompt configurations.

Among them, the neutral prompt reads "Use a subagent for a piece of work when appropriate..."

The prompt for preferring delegation reads "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...".

The cumulative arrival curve of work requests and the cumulative completion curves of the four approaches (mean of 5 experimental runs; message intervals and work durations scaled by 1/4, model call latency at real values)

Note: each approach was run 5 times; task completion time refers to the time from a work request to the result message.

In terms of task completion time, Super-agent's p50 and p95 are 12.4 minutes and 15.7 minutes, respectively, significantly better than a single Session with the Subagent tool. The reason is that, in the experimental setting, the single Session with the Subagent tool is heavily influenced by the prompt, and the main Session often decides to execute tasks itself, resulting in long total completion times and unstable performance. Under the neutral prompt, the model did not call the Subagent even once across 5 runs; all work was carried out in the main Session and was constantly interrupted by new messages, with p95 reaching 29.5 minutes. After switching to the prompt that prefers delegation, the model delegated in 4 of the 5 runs, and completion time was somewhat shortened but still overall slower than Super-agent; in the remaining run it judged the work to be "small" and chose to execute it itself, forming the long purple tail in the figure. Compared with relying on prompt engineering and the model's on-the-spot judgment of whether to divide work within a single Session, the two-layer architecture alleviates this problem at the system level by having the Router not directly execute concrete work and having Workers receive only messages from the Threads they subscribe to.

In terms of system overhead, because multiple independent sessions are maintained, Super-agent's read-cache tokens per experiment are higher than those of a single Session; it trades more token consumption for shorter and more stable completion times. Within Super-agent, after removing the passthrough mechanism, task completion time is essentially the same as the full version, but the number of decisions the Router needs to make per experiment increases by about 30%, and total read-cache tokens rise from 23.23 million to 31.77 million, an increase of about 37%. This shows that under the experimental load, the passthrough mechanism does not improve task completion quality or speed, but it saves considerable token and inference overhead for the Router Session.

7.2 Batching at the Router Layer

To verify the throughput ceiling and batching mechanism of a single resident Router Session described in Section 2.1, we stress-tested the Router layer separately: the Router called the real model, Workers used a Mock model, and the arrival rate of Triggers requiring decisions was gradually increased from about 1 per minute to about 40 per minute, while observing the average batch size, per-request latency, and inference time amortized per decision.

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

As shown in the figure above, when the arrival rate of Triggers requiring decisions rises from about 1 per minute to about 40 per minute, the average batch size rises from 1.0 to 2.8, while per-request latency increases only from 2.5 seconds to 3.9 seconds, growing more slowly than the batch size, so that the inference time amortized per decision drops from 6.4 seconds to 1.6 seconds. This means that when external events suddenly congest, the Router layer can increase effective throughput by automatically merging backlogged events. This also explains why in Section 7.1, even though removing passthrough increased the Router's peak load, it still did not hit the throughput bottleneck of a single Router. Therefore, at our current team size, there is no need to prematurely horizontally partition the Router layer at the cost of sacrificing the continuity of global context.

8. Open Questions

The five modules introduced in Sections 2 through 6 constitute the basic architecture that supports Super-agent's operation, and the experiments in Section 7 also verified the effectiveness of its core scheduling and routing mechanisms under multi-task concurrency. The reason this system can operate with relatively low complexity is largely that at the current stage we made a series of engineering and scenario simplifications. Beyond the applicable scope of these simplifications, there remain some problems to be solved in scaling the two-layer architecture (Section 8.1), human-agent collaboration after leaving 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 preceding sections used a simplified combination of "a single persistent Router Session + subscription passthrough + no direct communication between Workers" to cover most of our current daily tasks at a relatively small engineering cost. However, when task scale expands and coupling increases, exceeding the capacity of a single Router Session, the specific intra-layer structure remains undetermined: when the Router layer needs horizontal partitioning, how granularity should be divided, and when direct communication between Workers in the same layer should be introduced and what collaboration topology should be adopted all still need to be tested in more scenarios. At the same time, co-design of the system and the model is also a direction worth exploring; targeted training for tasks such as event discrimination, batch dispatch, and context recall at the Router layer may further improve the Router layer's throughput and decision-making performance.

At the same time, the persistent Router layer described above, together with chain-style recall based on a reference graph, mainly addresses on-demand retrieval of recent tasks and session history. When the operating cycle extends to a time span of months or even longer, long-range memory becomes the main bottleneck constraining scalability.

8.2 How to Collaborate with Agents After Leaving the Session

The preceding sections used a two-layer architecture to hide underlying multi-session management from users, so that the Session is no longer the primary issue in product design; however, once the underlying execution sessions no longer directly correspond to the sessions in the user interface, how to present tasks to users and provide natural forms of interaction and project management becomes a new problem. We believe that chat-window-centric interaction is to a certain extent the result of path dependence. Interaction may be able to occur more in domain-specific interfaces; for example, as in the instance in this article, letting the Super-agent work directly in GitHub Issues and Pull Requests; Sessions may also be retained in the interface out of users' usage habits, but what the user sees as one session may not necessarily correspond to only one Session underneath.

At the same time, the preceding sections mainly discussed human interaction at the stages of task initiation and result acceptance; however, during the transition period of rapid model capability evolution, many tasks still require human participation midway. How to balance, in product design, users' gradual intervention in key details with the efficiency of autonomous background progress—for example, allowing users to intervene at any time during background execution, take over, or collaborate with the Agent in real time—is likewise worth exploring.

Overall, the project management and interaction forms users need are closely related to specific work domains and personal styles, and the final form is likely to be highly customized; because DeepSeek Harness adopts an open architecture design, it is also easier to support such customization.

8.3 How to Divide Context Boundaries and Carry Out A2A Collaboration

The preceding discussion has always been about the design inside a single Super-agent instance, assuming by default that all information within its service scope is aggregated in the same global context. But when the scope of use expands from an individual or small team to a larger organization, the organization, in deciding how to equip Super-agents, is in fact drawing the boundaries of context sharing and isolation. Scopes that need to share context use the same instance, while scopes that need isolation are each equipped independently.

Looking further, once there are multiple mutually isolated instances within or across organizations—for example, between each member's personal assistant and a team-shared Super-agent—collaboration across boundaries is agent-to-agent communication (A2A, not referring to any specific protocol). On the premise of not sharing the underlying context and each representing different permission boundaries, how to achieve secure and reliable A2A communication and collaboration still requires 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 broader environment, but it also increases the risk of exposure to untrusted input. If security and privacy issues cannot be well solved, then the Super-agent can only work within a very small and trusted scope.

For example, Section 5 deploys the Agent Loop in the cloud and installs lightweight daemons on various execution devices; this design is by default built on the premise that the cloud and device-side environments trust each other. But when the cloud-side Agent Loop continuously ingests external environment events while device-side devices store private code, sensitive data, and local credentials, this cross-device connection introduces significant security and privacy risks. Once the cloud-side Agent Loop is compromised through server intrusion or prompt injection, all connected device-side devices face the potential risk of being controlled.

Moreover, even if the cloud is not compromised, as long as credentials in the device-side environment can enter the model's context, there is likewise a risk of credential leakage during normal execution; therefore corresponding mechanisms also need to be designed so that the Agent can use credentials without touching the credentials themselves at all. If this architecture is to move toward broader application, it is necessary to solve the above security and privacy problems while being able to recall context from diverse environments.

9. Conclusion

Looking back at the entire design, we did not propose an entirely new theory, but applied classic engineering ideas from computer systems to the construction of an Agent system. The specific implementation will evolve with technological development, but we believe the underlying system design approach has longer-term reference value. At present, the internal Super-agent instance we built based on this approach and DeepSeek Harness has been running continuously, participating daily in problem reproduction and fixing, code review responses, and DeepSeek Harness's own iteration.

As stated at the beginning, as large models increasingly require less manual intervention to execute a single task, the bottleneck limiting further productivity improvement is shifting to human attention. Through the two-layer architecture, event-driven design, asynchronous multi-channel interaction, storage-computation separation, and external Watchdog, the system takes over tedious session management and context synchronization at the underlying level, allowing humans to move further up from specific execution details to higher-level decision-making and acceptance.

In this form, the Agent is no longer just a chat window passively waiting for instructions, but evolves into an autonomous collaborator that is continuously online in the digital environment: for individuals, it can be a personal assistant that assists with daily affairs across devices; for teams, it integrates into R&D workflows, taking on and advancing specific tasks. We believe that, with the joint evolution of model capabilities and underlying system architecture, this more autonomous way of working is expected to become the norm for human-agent collaboration.

(Source: Yicai) Mid-article embedded advertisement