Super-agent design exploration: moving towards a more autonomous Agent system.
This article is an exploration of architectural approaches to engineering practice, not an introduction to the existing product functionality of DeepSeek Harness.
1. Super-agent
Over the past year, the single-task Agent, represented by the Coding Agent, has demonstrated that models are capable of solving complex problems using tools that increasingly require continuous human monitoring and gradual intervention. At the same time, the model's multi-agent collaboration capabilities are also improving, making organization and scheduling across sessions feasible. As human involvement in underlying execution decreases, human roles are gradually shifting to higher levels of decision-making and acceptance.
This improvement in model capability has also led to a new form of application. Recently, personal assistants have begun to emerge, accessing daily messages, schedules, emails and work platforms directly, continuously observing information flows and assisting in managing tasks. This continuous online, event-driven work model is not limited to personal situations, personal assistants are just one of them; it is equally valuable in commercial situations such as software development.
However, the current mainstream Agent design still fails to support this model at the scale of multi-tasking and team collaboration. Agents' work patterns remain in a single Session as a basic unit, independent of each other between different Sessions. When the user simultaneously advances multiple tasks, it is necessary to manually switch and remember the context of each Session, whereas we observe that a person can usually follow only 3 to 5 active Sessions at a time. In this design, the upper limit of a single task depends on the ability of the model, the upper limit of multiple tasks depends on the attention of the person.
If you simply extend it with CLI, MCP, or external connectors only on an existing local session agent, the agent can access external messages, but it still suffers from single session synchronous blocking, contextual confusion on multiple tasks, local device offline shutdown, and a lot of artificial maintenance.
To overcome these limitations, it is necessary to break the link between the Agent and a single manual session, making it a continuous entity that can stay in context across sessions while advancing complex tasks without interfering with each other. We call this form of Agent and its system architecture Super-agent.
For example, in our internal instance of Super-agent running on the basis of DeepSeek Harness, the same development task can be continuously pushed between IM and GitHub; this instance will also continue to observe feedback in public chat, actively locate the root cause in the absence of an @, and submit a Repair Pull Request:
The same task continues to progress between IM group chat and GitHub Pull Request review.
Continue to pay attention to public chat, actively identify defects in the absence of @ and submit a Pull Request to repair
Specifically, we believe that Super-Agents have the following four basic characteristics:
Continuity: Users can interact with it directly in familiar work interfaces such as IM chat, GitHub reviews, and feel that there is always only one Agent, without having to worry about "whether there is Y information in the context of Session X". For example, the user first adopts Schedule A on IM, then changes it to Schedule B in GitHub Pull Request reviews, which can understand and adjust the execution direction.
Efficiency: interaction responds quickly while simultaneously performing multiple complex tasks in a high-quality manner. You don't have to wait for the last order or task to be completed to accept the next order.
Active: without having to wait for the user's instructions to come down step by step, to be able to continue to observe environmental events and proactively promote things worth dealing with, and to remain silent when no intervention is needed.
Durable: Always online, direct access to the user's real work environment, and automatically recover when encountered with abnormalities in long-term operation.
A single ReAct Loop cannot simultaneously support all four of the above features, and the bottom needs a corresponding set of architectures. Similar design constraints will lead to similar architectural choices. We believe that if the goal is to build a system that is continuous online and responds to environmental events simultaneously, then a similar architecture may be used at the bottom. At the same time, many of the problems faced in this process have a high similarity to the problems that traditional computer systems have long explored, so many classic design ideas in computer systems apply here as well.
The architecture varies from place to place, but we think the following five modules constitute the basic framework that supports the four basic characteristics mentioned above: continuous interaction and efficient synchronization through two-tiered architecture (section 2) event-driven (section 3) active response (section 3) continuous and efficient interaction through human-facing (section 4) interaction (section 4) and computational state-to-environment separation (section 5) and watchdog (section 6) to achieve durable online and abnormal improvement across devices.
The following table shows the overall system architecture of Super-agent, with symbol numbers [2] to [6] for each module in the chart, respectively, in paragraphs 2 to 6 of the context:
Super-agent overall system architecture, codes [2] to [6] corresponding to sections 2 to 6 below
2. Two-tiered architecture
In order to achieve efficient simultaneous cross-channel continuous interaction and multi-tasking, the system faces a fundamental balance between continuity and throughput (Trade-off) in the organization of underlying sessions.
If each event is handed over to the same Session processor, although most continuous in the context above, but limited to the maximum speed at which a single ReAct Loop sequentially executes, task completion takes time, throughput is low, and the intermediate details of multiple tasks are mixed together to affect completion effect.
Conversely, if each event is directly dealt with by a newly independent Session, even though the simultaneous throughput is highest, but once the tasks are not completely independent, the lack of a global context will cause the results of each Session to fall apart, while the interaction of multiple sessions with each user will be chaotic.
In order to reconcile continuity and throughput, we can divide "maintaining global continuity" and "high concurrent execution" into two different levels: from the permanent Router layer (Section 2.1) to the unified human interaction with global coordination (Section 2.2) and from the Worker layer (Section 2.2) to execute specific tasks, as shown below:
Dual-layer architecture: Router layer unified routing with diplomatic interaction, multiple Worker Session isolation and simultaneous execution of tasks
Through this two-tiered architecture, the system takes over context management and concurrent execution at the bottom, thus belittling the presence of the Session on the user side, with the user always facing the same Super-agent. From this point of view, allowing the user to manually manage the Session is largely a design inertia that continues from the underlying LLM API; the Session should be the implementation detail of the system and not the cognitive burden of the user.
In the existing design, Session simultaneously carries technical context management and user-oriented project management. Once the product form is unleashed with the underlying Session, user-oriented project management is no longer restricted by Session and becomes an independent product issue about how the user exposes interaction with task management.
The "double layer" here is a logical division of tasks, with each layer not necessarily confined to a single Session in implementation, but having its own internal structure.
2.1 Router layer
The Router Layer is a permanent global routing layer responsible for all human interactions. All information and decision-making across missions are summarized in the Router Layer, where it serves as the global starting point, sequence point, and memory. In order to prevent this global node from becoming a performance bottleneck for the system, the Router Layer is not designed to directly execute specific tasks and is only responsible for human interaction task assignments, and may not even be equipped with Bash tools.
This structure, where multiple execution nodes are allocated by a single central node, is similar on the surface to the common Agent Team, but differs in focus. The common Agent Team is primarily used for step-by-step decomposition and role-playing collaboration within a single complex task, since the sub-steps are usually closely coupled, and Team Lead often requires a deep understanding of task detail, sub-tasks planning and high-frequency coordination of each member, which itself carries a heavy logical load. In Super-agent, the Router layer only handles the high-level division between tasks, with no need to intervene in the internal decomposition of the single task; on the contrary, if a regular Agent Team speaker is not personally responsible for executing the specific task by prompting a binding term, and is solely responsible for diplomacy and assigning tasks to different independent members, it can also assume this double-vision architecture.
In the internal implementation, the Router layer does not have to be confined to a single Session, nor does it have to be partly logical to call the LLM. We chose the most direct single permanent LLM Session as the core implementation of the Router layer, and found that it did not appear to be so superficially easy to swallow as the environmental events that arrived during the previous round of reasoning (i.e. Section 3 Trigger) would accumulate in the next round and then process, forming batch processing (batching), and the extra expense of combining the processing was very small:
When the external event flows smoothly, the Trigger enters the Router Session in stages, with a lower single-response delay.
When event density flows in, the Router Session begins to experience queue congestion, multiple Triggers that are loaded during the previous round of reasoning are automatically merged and injected into one of the next LLM calls. The Router Session does only light interactions with the partitions, each step is usually long input, short output. Combining multiple Triggers of the load into a single LLM API call is calculated in parallel at the Prefill phase, with a slow increase in batch size.
We will demonstrate the effects of this batch processing mechanism through experimental quantification in Section 7.2. In addition to the subscription and direct communication mechanisms and chain recall mechanisms that will be introduced later (see Section 3.2·3.3), a single permanent Router Session is sufficient in our current team while maintaining continuity in the context.
When the scale is further expanded, when a single session is indeed insufficient to handle, the interior of the router layer can also be designed as a multi-layer filtering structure, or sharding into multiple sessions. At this point, the internal design of the router layer is essentially a balance between continuity and throughput. The thinner the split particle size, the higher the concurrent throughput of the router layer, but the lower the memory between bits and the context continuity. This balance always exists until the overall memory problem is solved.
2.2 Worker level
The Worker layer consists of sessions that are responsible for specific execution, with each Worker isolating each other from the context, mounting complete execution tools, and focusing on completing a single task in a separate context. Because the Worker Session directly determines the outcome of the task and the quality of the code, it usually requires the most configurable model.
Worker does not interact directly with humans, and its reasoning processes and tool calls do not directly output to external channels, but instead report to the Router Layer status and respond to the user from the Router Layer uniquely, thus avoiding the confusion of multiple sessions responding respectively while ensuring synchronization and delivery quality.
When multiple tasks are simultaneously executed, multiple workers advance tasks independently, and there is usually no direct communication between the same level of worker. Multiple worker conflicts in specific executions often occur in the same shared work environment, such as Pull Request; as long as they subscribe to the corresponding thread, they receive the same event notification (see section 3.2), giving them the opportunity to discover and resolve conflicts themselves, and a few cross-task collaborations are transferred through the router layer.
Similar to the Router layer, each Worker Session does not have to be confined to a single session internally: when performing complex single tasks, the Worker can recreate Subagent internally, or it can itself be an Agent Team, which is transparent to the upper Router layer. This structure applies both to the code collaboration scenario (which simultaneously promotes multiple independent problem iterations, pull request review and feature development without interlocking) and to the personal assistant scenario: Although the assistant typically provides only one single session chat page on the interface, a single chat page on the front end is responsible for maintaining the continuity of interaction when the user discusses several different topics in the same dialog box, while the bottom end can assign the Worker to each topic and push the task back to the drawing board.
3. Events Driven
To make the Super-agent dynamic, it is necessary to first change the way the system drives. To drive the Agent, the main input is no longer the prompts that humans type in the Session, but semi-structured events in the environment. In the Super-agent, environmental events such as chat messages, emails and calendar reminders, code review reviews, CI run results are known as Trigger. By listening to and responding to Trigger, the Agent no longer needs to passively execute human-derived commands as in the Single Session mode.
Around the lifecycle of an environmental event from entering to processing, the following four progressive questions will be discussed: how to filter large amounts of noise through a two-stage strategy combined with the program and model (section 3.1); how to route the event to the Worker (section 3.2) through subscription and direct communication mechanisms; how to use Inline & Spill to inject high density chain-based recalls into the model (section 3.3); and how to use speculation to execute premature actions based on environmental signals in the background (section 3.4);
3.1 Events filtered
After accessing real chat rooms and code platforms, the environmental event stream has significant "high noise, low trigger rate" characteristics, and the vast majority of everyday messages do not require Agent intervention. If large models are called to each event from scratch, the delay and computational costs will be difficult to bear. Drawing on the idea of Fast Path / Slow Path in computer systems, large model reasoning can be seen as a flexible but high-cost Slow Path, whereas already clear and stable high-frequency judgment will solidify as a certainty code, constituting a low-latency, low-cost Fast Path.
Thus, the first step after the event enters the system is filtering, with the goal of eliminating the noise with a definitive strategy before calling the big model, and handing over only candidate events that require a semantic understanding to the model.
A program-level strategy (as Fast Path): for certainties such as event sources, group ranges, user or robot whitelisting, to perform quick access checks directly through the code, such as setting "only respond to explicit requests" for different sources, "as a candidate event" or "directly ignore" to remove most unrelated messages before calling the model.
Semantic Layer Strategy (also known as the Slow Path): A candidate event accessed through the procedural layer is assigned to an LLM to determine whether action is needed based on a strategy written using a cue word and the context above. Semantic Layer is also a natural language extension point for humans, and can be accessed at any time by switching on or adding a cue word strategy, as shown below:
Two-Level Filtering: Most unrelated messages are removed first by the program-level strategy and then judged by the semantic strategy.
3.2 Event routing
The Universal Router layer introduced in Section 2 is responsible for maintaining cross-channel continuity, but if each subsequent event of the assigned task still needs to be forwarded by the Router layer, the Universal node will still be subject to a large amount of load, pushing up system response delays. Thus, the Fast/Slow Path also applies to post-filtering event routing. The Universal Router layer is solely responsible for the cold start of the new task and the cross-task coordination, while the subsequent events of the assigned relationship should be sent directly by the program to the corresponding Worker session, without having to be forwarded by the Router layer.
In the actual workflow, the same GitHub Pull Request, the same IM theme, or a sequence of events in the same incoming email string constitutes an event stream, the Thread:
Thread Example: A thread is a continuous trigger under the same IM theme or the same GitHub Pull Request.
After a Worker Session is created on the Router Layer based on the initial event of a Thread, the Worker subscribes directly to the corresponding Thread, thus dividing the event path into the following two paths:
Fast Path: Subsequent events under the same Thread are sent directly by the program to the subscribed Worker, without requiring the Router layer to call the tool again. If the new event exceeds the scope of the current task, the Worker can also cancel the subscription or return the Router layer redistribution.
Slow Path: The router layer is still able to observe all events to gain global status, but is solely responsible for judging and allocating new events that have not yet been subscribed.
Subscription and Direct Connection: The initial event creates the Worker through the Router layer and builds the subscription, and the subsequent events of the same Thread are sent directly to the Worker.
Additionally, subscriptions between Thread and Worker are multi-relationships. 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 interact in the same work environment or discussion, the new events under Thread will be directed to all its subscribers at the same time, giving them the opportunity to learn about each other's operations and resolve conflicts on their own. While on the output side, the Worker will still report key conclusions to the Router layer, which is unified by the Router layer to respond to and synchronize the overall memory of the user.
3.3 In the context of UNESCO
After the event is filtered and routed into the target Session, the next question is how much information should be injected into the upper context window of the model. Because system input is shifted from limited human pronouns to semi-structured events that occur continuously in the environment, the structural design of tool calls and event injections becomes more important. Too much injection will clutter the window, dilute model attention, and inject too little will force the model to repeatedly call tools to read and increase the number of execution steps.
To do this, we can manage limited context windows as a Cache. Using the concept of compilation optimization and computer systems, the design of context insertion can be divided into two basic operations. Inline refers to directly connecting up-to-date information that is likely to be used to the current context window to save additional tool calls back and forth.
Combining the classic Locality idea in computer system design, we can use Inline & Spill to gradually optimize event inputs and tool calls:
1. Starting with the least information: Initially only provide the ID and content summary of the current object.
2. Using localized incremental Inline associative information: Inline information that is likely to be used in the near future into the context above, first by attaching the ID of closely related objects, and then by attaching adjacent content, such as 50 words before the content, adjacent messages before and after the IM message with the message being answered, or adjacent comments in the review discussion where the code comment is located.
Spill: Set a smaller length limit for long content that cannot be completed inline and will go beyond the Spill section to the window. A simple, straightforward approach is to cut off the spill section and retain the continuous input, so that the model calls the tool to read when the full content is needed.
In addition, after a large number of subsequent events directed to Worker, and the system accumulated many historical tasks over a long period of time, the Router layer could not put the entire history of all tasks in its own context window, but needed to look for context when the user raised an old task across the channel. After applying Inline & Spill consistently to all types of objects in the system, an on-demand multi-jump detection mechanism was developed, the Chain of Recall. This chain-based recall process alleviated the problem of the Router layer losing previous information over a long period of time, as shown in the following diagram:
Chain recall: Each recalled object is internally linked to the next jump associated object ID, supporting jumps along the reference relationship to the context.
Specifically, the system assigns unique IDs to objects such as Trigger, Thread, and Worker Session, and when injected the IDs of closely related objects, making these objects form a reference graph at the bottom. Since the object itself follows Inline & Spill each time the call tool is recalled, the result of its return is that the abstract of the associated object is interconnected with the ID of the next jump, so the model can proceed from the current reference event and recall the relationship step by step to the context.
For example, a thread is read from a current message, tracked from the thread's internal ID to the relevant Worker Session, and then found another code that reviews the thread associated with the worker.
3.4 Action in advance
Based on the idea of speculative execution in a computer system, the Agent can attempt to reduce the cost of human waiting and intervention by using additional backward computing power based on environmental signals in the background, even when it is not yet certain whether the results will be adopted.
In the personal assistant scenario, when we receive a conference invitation email or pending message, the Agent can check the scheduling conflict in the background, collect relevant background information and respond to the draft, which can be confirmed directly by the user after the review. Similarly, in the R&D collaboration scenario, for example, we set up a "silent replay and repair" strategy in the company's DeepSeek Harness internal user group: When people in the group are giving feedback or discussing a change plan, the Agent tries to replay and look for a repair plan in the background, only after confirming and finding a simple repair plan, to deliver the results to the user, otherwise the entire process is silent.
Examples of speculative execution: While discussing the solution within the group, the Super-agent has submitted a Pull Request Repair in the background.
4. Interactions with people
Section 2's two-tiered architecture ensures cross-channel continuity from an upper-contextual level, but to be both continuous and efficient in a real human-to-human interaction experience, two issues need to be addressed in an interactive manner and in an interactive channel: how to eliminate the time-consuming obstruction of back-to-back conversations through the asynchronous ReAct Loop, so that the session does not have to wait for a command or complete a new command (section 4.1); and how to make the system's output patterns match the bandwidth of the channel to the user's usage habits (section 4.2);
4.1 Interaction between workers
In the classic ReAct Loop, the model starts a synchronized run () tool call and the loop is blocked until the tool is executed and returns the final result, during which time the session cannot respond to any new user input. To remove this block, the conversation needs to be changed from a one-question half-duplex to a full-duplex mode, as shown below:
Classic ReAct Loop versus Asynchronous ReAct Loop: Asynchronous calls instantly return to Started notifications, while the backend tool is still responsive to new messages
To do this, we convert the time-consuming commands with the subtasking tool to start () and stop () calls that are asynchronous, forming an asynchronous ReAct Loop. The model receives a return of "start () " immediately after the start () call, and the loop no longer waits for the tool; once the back-end tool is executed, the system delivers the final result as a new event message to the session; at the same time, the model can also call a stop () command based on the above context to actively stop the execution time.
As a result, the front-end dialog response and back-end tasks can be unlocked, and the agent can respond to human inputs while running time-consuming tasks in the back-end. New inputs are processed after the current reasoning step is completed, without having to wait for the back-end tool to complete.
This asynchronous mission mechanism has been implemented in DeepSeek Harness, but has not been enabled by default.
4.2 Multicultural interaction
Different work channels have different information densities and interaction habits, and the output of the system needs to be matched. If the method of interacting with the single-person terminal is moved directly into the group chat, the redundant reasoning process and the intensive tools call for the same output, which is very easy to cause information overload in multi-person collaboration.
In the Super-agent, the two-layer architecture has solved part of the problem: the elaborate reasoning process and intensive tool calls in specific tasks are isolated within the Worker Session, not directly output to external channels, and the Router layer is uniquely responsible for the diplomatic interaction. On this basis, the system also needs to access the various working environments that users use on a daily basis, and to specify custom interactions for different channels through hints:
Instant messaging channels such as IM: focusing on low-interference light communication, sending notifications only when decisions or receipts are needed, asking direct questions only, giving short conclusions. One simple and effective hardness rule we've verified is that no more than 100 words are answered at a time.
Asynchronous channels such as GitHub, Mail and Documents: focused on structured, high information density asynchronous delivery, such as writing a complete problem context according to project specifications when creating or updating Pull Requests, modifying explanations and verification results, or directly drafting structured mails and document summaries in a personal assistant scenario.
5. Calculation, separation of state from environment
By default, the existing Local Agent will advance the computation of the Agent Loop, the session state that requires persistent storage, and execution environments such as code warehouses and local tool chains that are tied to the same device. Once the device is dormant or offline, the Agent stops running and cannot access the environment on other devices. To enable the Super-agent to stay online and have flexible access to all types of real work environments, we can borrow the idea of Compute-Storage Separation from the computer system, which is a two-step breakdown of these three bindings: the first step is to advance Agent Loop computing from the persistent session state, freeing the Agent from the single-machine lifecycle, achieving cloud persistence in section 5.1; the second step is to disconnect the Cloud from the execution environment of the Agent Loop, allowing access to the real-world environment and maintaining real-world support.
5.1 Separation of computation from state
Advanced Agent Loop computing can be rendered stateless, requiring persistent storage of the session state. Therefore, the first layer of decryption is to move Agent Loop computing into a resilient computing container in the cloud that is stateless, while storing a persistent state such as Session in a database.
5.2 Separation of computing and execution environments
After Agent Loop and the cloud-based session status, further questions arise as to how to access the execution environment required for the task. Much of the context required for model work is to be accessed through tool calls from execution environments such as code repositories, local files, dependency services, in this sense, the broad context also includes the execution environment itself.
There are two common ways of thinking about this: one is to launch sandboxes in the cloud, drag code and try to reconstruct and sync environments, but because real work environments often include unsubmitted local modifications, private credentials, intranet service dependence, and specific hardware or toolchains, sync environments are not only technically costly but also prone to missing information; the other is to directly require users to abandon the local environment to work in the cloud, but for many users, the cost of migration is too high.
Since the environment itself is difficult to copy and sync, there is no need for the execution environment to follow Agent Loop in the cloud. The second layer of decryption is to let Agent Loop run in the cloud, while keeping the high-status execution environment in place, deploying a lightweight daemon that does not save session status only on the end, which is only responsible for executing commands and returning results, which is equivalent to leaving the execution environment outside the cloud, where the agent reads the above context as requested.
This is consistent with Anthropic's "brain separation" ("Decoupling the brain from the hands"), which also keeps the harness idle, keeps session logs outside the harness, and executes on-demand environments through a unified interface. The difference between the two is in the scenario. The article describes hosting services, mainly discussing on-demand sandboxes and the resources within client VPCs; the first step is to access personal machines that users use on a daily basis, possibly offline, with unsubmitted modifications and local credentials.
As a result, an Agent is no longer limited to a single machine, but can switch between different execution devices to execute commands and obtain context from the environment depending on the task. It can even support intermittent online devices, such as after a user's personal device is rebooted, which are automatically triggered by the Cloud Agent and complete tasks that need to be executed on that device.
Decompression of storage and execution environments: Agent Loop is separated from the persistent state in the cloud and executes on-demand access to all types of environments via end-side daemon
6. Watchdog
To achieve lasting online, in addition to sections 5 and 5, it is necessary to allow the system to automatically recover from abnormalities in long-term operation. It is difficult for a lasting online distributed system to rely solely on the internal logic of the main system to ensure long-term reliable operation, and requires the introduction of an independent external control circuit outside the main system, the Control Loop.
At the same time, detecting or monitoring scripts for surviving traditional processes in an Agent system is not enough, as many exceptions are not process crashes, but models falling into an ineffective loop or deviation from the target in execution. Therefore, a long-running Agent system not only needs to monitor the survival of the infrastructure but also the progress of the task itself.
We configure a separate Watchdog Session on the outside of the main system, which is driven by a timely message, and forms an external Control Loop. In addition to dealing with infrastructure failures such as interface reports, error recovery failures, the Watchdog will also judge by the model whether the worker is making substantial progress or deviating from the overall goal.
Since the Watchdog itself is an Agent Session with full tool capabilities, the maintainer can ask it in natural language about the cause of the failure, or allow it to modify the behavior of the main system online, such as adding deleted prompts and adjusting the triggering rules.
7. Initial experiments
In order to evaluate the core scheduling and routing design of the preceding, we conducted preliminary experiments from two levels: first through end-to-end experiments against the two-tier architecture, subscription direct communication and single-session schemes (section 7.1), followed by separate testing of the batch processing of the Router layer (section 7.2). Since the experiment is based on synthetic loads and simplified environments, some settings can be more rigorous, the following results are only for initial reference.
7.1 Dissolution experiments
We run four end-to-end programs simultaneously using group chat and the GitHub CI message stream: A single experiment contains about 300 messages, of which about 20 are job requests, the rest are chat, follow-up, stop and CI messages. The coding work is replaced by a time-consuming tool, so the experiment measures the scheduling and collaboration capabilities of the system rather than the execution of a single task. Each program is repeated five times.
The four contrasting schemes include Super-agent, removing the directed Super-agent, and single Session + Subagent tools under two prompter word configurations.
Among them, the neutral tip reads "Use a subagent for a piece of work when appropriate"...
"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 the work request and the cumulative completion curve of the four programs ((5 times the average run time of the experiment; the message interval and the duration of the work are scaled by 1/4 and the call time of the model is the real value)
Each program is repeated five times; task completion time refers to the time taken from the job request to the result message.
In terms of task completion time, the p50 of the Super-agent is 12.4 minutes and 15.7 minutes, respectively, significantly better than the single Session with the Subagent tool. The reason is that the single Session of the Subagent is more affected by the prompting in the experimental scenario, and the main Session often decides itself to execute the task directly, leading to total completion time and unstable performance. The two-tier architecture mitigates this problem at the system level by preventing the Router from directly performing specific tasks, as opposed to relying on prompter engineering and model on-site judgment in a single Session.
From a system cost perspective, due to the maintenance of multiple independent sessions, Super-agent single-experiment reading cache tokens are higher than single Session, which is shorter and more stable completion times in exchange for more token consumption. When the Direct Mechanism is removed from within the Super-agent, the task completion time is basically consistent with the full version, but in single experiments, the decisions that the router needs to make increased by about 30%, the total cache token increased from 23.23 million to 31.77 million, an increase of about 37%. This indicates that the Direct Mechanism does not improve the quality and speed of the task completion under the experimental load, but saves significant token and reasoning costs for the Router Session.
7.2 Router layer batch processing
To verify the throughput upper limit and batch processing mechanisms of a single permanent Router Session in Section 2.1, we performed a separate pressure test on the Router layer: having the Router call a real model, Worker use a Mock model, and gradually increasing the required Trigger to reach the rate from about 1 point per minute to about 40 points, observing the average batch size, the time spent on a single request, and determining the reasoning time of a single allocation.
The batch size of the Router Session at different Trigger reaches the speed, the time it takes for a single request to be allocated to a single decision
8. The question of openness
The five modules presented in sections 2 to 6 constitute the basic architecture that supports the operation of the Super-agent, and the experiments in section 7 also validate the effect of the core scheduling and routing mechanisms on multitasking. This system is able to operate at a lower complexity, largely because we have done a series of engineering and scenario simplifications at this stage. Beyond these simplified scope of application, there are still some issues that need to be addressed in the expansion of the two-layer architecture (section 8.1), post-season human collaboration (section 8.2), the context with section A2A (section 8.3), and security and privacy (section 8.4).
8.1 How to expand a two-tiered architecture
A simplified combination of "single permanent Router Session + subscription direct communication + non-direct communication between Worker" covers most of our current day-to-day tasks at a lower engineering cost. However, when the task scale expands, combinations improve and exceeds the carrying range of a single Router Session, the specific layer internal structure is uncertain, when the Router layer needs level segments, how the granularity is divided, and when direct communication between the same layer Worker needs to be introduced; what types of collaborative topologies are still to be tested in more scenarios. At the same time, system and model co-design is a worth exploring direction, training for Router event differentiation, batch assignments and recalling tasks, and it is possible to further enhance the performance of the Router's catalytic functions.
At the same time, the router layers in the preceding text are accompanied by a reference graph-based chain recall, which mainly addresses the on-demand retrieval of recent task and session history. Long-range memory becomes a major bottleneck in limiting scalability when the run cycle extends to monthly or even longer time intervals.
8.2 How to collaborate with Agent after leaving Session
The introduction hides multi-session management from users through a two-tiered architecture, making Session no longer a priority issue in product design; however, how to present tasks to users and provide a natural form of interaction with project management becomes a new issue when the execution of Session is no longer directly related to sessions on the application user interface. We believe that interaction centered on the chat window is to some extent a path-dependent result. Interactions may occur more in domain-specific interfaces, such as in the example in this article, allowing the Super-agent to work directly on GitHub's Issue and Pull Request; Session may also occur due to user usage habits and be retained on the interface, but a session is not necessarily seen by the user in a single Session at the bottom.
At the same time, the foregoing mainly discusses the interaction between humans at the initiation of tasks and the acceptance of results; however, during the transition period of rapidly evolving model capabilities, many tasks still require human involvement in the middle, and it is equally worth exploring how to accommodate the efficiency of the user's gradual intervention in critical details in product design and autonomous advancement in the background, such as allowing the user to intervene, take over or collaborate with Agent in real time in the process of execution in the background.
In general, the form of project management and interaction required by users is closely related to specific areas of work and personal styles, with the ultimate form likely to be highly customized; and DeepSeek Harness is more likely to support this customization due to open architecture design.
8.3 How to break down contextual boundaries and A2A collaboration
The foregoing is always a design within a single instance of a Super-agent, whereby by default the information within the scope of its services is aggregated in the same global context. However, when the scope of use extends from individuals or small teams to larger organizations, the organization is actually dividing the boundaries between context sharing and isolation when deciding how to equip a Super-agent.
Furthermore, once there are multiple isolated instances within or between organizations, such as between each member's individual assistant and the team's shared Super-agent, cross-border collaboration is Agent-to-A2A communication (not specifically a protocol).
8.4 How to ensure security and privacy
Section 3's event-driven design enables the Agent to be driven by a broader environment, but also increases the risk of exposure to untrustworthy inputs. If there is no good way to address security and privacy issues, Super-agents can only work within a very small and credible range.
For example, Section 5 deploys Agent Loop in the cloud and installs lightweight daemons on various execution devices, based on the assumption of mutual trust between the cloud and the edge environment by default. However, when Agent Loop in the cloud continues to access external environmental events while the edge device retains private code, sensitive data, and local credentials, this cross-device connection introduces significant security and privacy risks. Once Agent Loop in the cloud encounters a service invasion or injection of hints, all of its connected edge devices face a potential risk of being controlled.
In addition, even if the cloud is not compromised, there is the same risk of credentials being leaked during normal execution as long as credentials in the edge environment are able to access the model's context; therefore, a corresponding mechanism needs to be designed to allow the Agent to use the credentials without any contact with the credentials themselves. If this architecture is to be applied more widely, the above security and privacy issues need to be addressed while being able to recall the context from a diverse environment.
What is the meaning of the words? 9.
Looking back at the design as a whole, we didn't come up with a whole new theory, but instead applied classic engineering ideas in computer systems to the construction of Agent systems. The specific implementations will evolve as technology develops, but we think the system design ideas behind it have a longer-term reference value.
As the introduction points out, the bottleneck that limits further productivity is shifting to people's attention as large models perform individual tasks that require less and less human intervention. Through a two-tiered architecture, event drive, asymmetric multi-channel interaction, and separation of storage from external Watchdogs, the system takes over the busy session management and synchronization of the context at the bottom, allowing humans to move further from specific execution details to higher decision-making and receiving levels.
In this form, Agent is no longer just a passive dialog window waiting for instructions, but has evolved into an autonomous collaborator that continues online in a digital environment: individual-oriented, it can be a personal assistant that assists with day-to-day operations across devices; team-oriented, it integrates into the R&D workflow, assumes and advances specific tasks.
Part of the design of this article has been implemented in the dsh-superagent-prototype. The plugin is only a prototype provided to verify technical routes and is not an official product of DeepSeek.
Author & Acknowledgements
The paper is based on the shared practice of the DeepSeek Harness team. Yujia Qiao completed the system implementation and wrote the paper, with Huanqi Cao, Zui Chen, Xieting Chu, Tianyi Cui, Shiyuan Feng, Yudong Han, Kexin Liu, Shichun Liu, Gesi Luo, Yifan Shi, Tongrui Xiong, C.C. Yu, Ziya Zhang, F. Zhou and others participating in the review discussion and providing feedback.
© THE