On October 31, 2026, DeepSeek published the design of "Super-agent," an AI agent that runs multiple tasks in parallel, along with research code for a resident coding agent. The agent is assigned to a single GitHub repository and works through individual tasks while receiving requests and notifications. It is not an official product and differs from the version DeepSeek uses internally, but the release reveals a design for delegating work without a human supervising every conversation, rather than simply running multiple AIs in parallel. At its core is the idea of separating the authorization to start new work from the handling of information added to work already in progress. For example, even if a CI (continuous integration) result arrives, that notification alone does not authorize new fix work.
A research prototype that resides in a single repository
"dsh-superagent," which DeepSeek published on GitHub, is a resident coding agent that targets a single GitHub repository. It can optionally connect to the business chat tool Feishu, and it starts work in response to requests from authorized users or according to rules the team has defined in advance. It reports results, such as pull requests (PRs), back to the original conversation where the request was made. The code is released under the MIT license, but the README states clearly that it is neither an official product nor a production-ready implementation. It is code adapted for public release, and some of the concepts described in the design article have not yet been implemented.
The system is broadly divided into a "coordinator" and "workers." The coordinator receives requests and notifications from sources such as GitHub, assigns tasks, and handles interaction with people. The workers, by contrast, are independent sessions allocated to individual tasks and carry out concrete work such as code changes. By separating the role of grasping the overall situation and managing tasks from the role of doing the actual work, the system is structured to process multiple requests in parallel.
A distinctive feature is that it does not manage the state of work solely through conversations with the AI. A work ticket, called a "Ticket" in the design documents, records the authorized scope of work and the version of the policy that was applied when the authorization decision was made. The relationships among tickets, assigned workers, and execution sessions are managed separately, so the state of the work itself is preserved independently even after a conversation or session ends. This makes it possible to check what was requested and how far authorization extended when adding information midway through a task or recovering processing after a restart.
In an approach that simply hands the continuation of a conversation to another AI, the content of a request and the state of the execution session tend to become tightly coupled. DeepSeek's design, by contrast, makes the ticket independent so that the content and authority of the work can be tracked even if the session in charge changes. It can be described as a mechanism that prioritizes continuously managing individual tasks over merely distributing conversations among multiple AIs.
Separating authorization for new work from adding information to work in progress
In DeepSeek's design document on authorization, the decision to start new work is clearly separated from the process of delivering information to existing work. The latter is handled by a mechanism called "Subscription." When a new message arrives in a thread a worker is subscribed to, the worker can receive its content. This covers not only human messages but also notifications from bots and CI. However, the arrival of information does not signify permission for new work, and workers can proceed only within the scope originally approved.
For example, if a CI failure notification reaches an AI that is handling a code fix, it can incorporate that information into its current work. If, on the other hand, a request to modify a different feature is posted in the same thread and it exceeds the original authorized scope, the worker cannot simply take it on as new work. The worker sends the request back to the coordinator, which re-evaluates authorization as needed. Supplementary information sent from the coordinator likewise does not grant new authority, and when resuming finished work, the system rechecks whether the authority is still valid. By separating the route through which notifications are received from the authority to take on work, the design prevents an AI's scope of work from expanding without limit as a conversation continues.
A ticket records not only the authorized scope but also the version of the policy used in that decision. As a result, rather than re-deciding authority based solely on messages that arrive later, the system can respond by referring to the original authorization. Even for messages arriving in the same thread, the handling differs depending on whether the content is information needed for work in progress or a request that requires new authorization.
For accepting new work, three modes are provided: off, observe, and auto, with observe as the default. In this mode, the AI evaluates and records whether work candidates it finds on its own meet the conditions to start, but does not actually begin the work. In off, automatically inferred work candidates are not accepted, and in auto, candidates that meet the conditions can be started automatically. However, explicit requests from authorized users are accepted in every mode, so observe is not a setting that halts all work. Also, even when work starts automatically in auto, it must match at least one valid rule defined in advance.
This kind of authorization management is separate from the mechanism that restricts the operations an AI can perform on a machine. Accepting new work, adding information to existing work, executing commands on the machine, and bringing in deliverables each have different safety boundaries. Based on DeepSeek's documents on authorization, execution control, and deployment and operations, the roles and constraints of each can be summarized as follows.
| Area | What the public prototype manages | What requires separate safeguards |
|---|---|---|
| Accepting new work | Checks the requester and predefined rules, and records the authorized scope of work | Restricting the files and credentials accessible on the machine |
| Adding information to existing work | Sends messages from subscribed threads and CI results to the worker | Authority to perform new work or operations outside the authorized scope |
| Executing commands on the machine | Runs commands with the OS user privileges of the execution process | OS-level isolation. A dedicated directory or command wrapper alone cannot provide isolation |
| Bringing in deliverables | Specifies auto-merge conditions through a prompt | A merge-specific enforcement mechanism in the execution platform. Branch protection settings on the GitHub side are required |
This distinction organizes the division of responsibilities in the public prototype's design and does not mean the safety of the overall system has been demonstrated. Restricting which users can assign work to the AI does not restrict the access privileges of the process in which the AI runs. The authority to start work and the range of operations permitted in the execution environment each need to be managed appropriately.
Commands move to the background after 5 seconds, with a slot reserved for human intervention
Under DeepSeek's specification for execution control, a shell command run by the coordinator or a worker moves to background processing if it runs in the foreground for more than 5 seconds. This is not a performance target that work finishes within 5 seconds; it is a mechanism that lets the AI keep receiving new messages while waiting for long-running commands to finish. The aim is to avoid a situation where waiting on processes such as builds and tests blocks other interactions as well.
Each ticket is assigned a dedicated execution session and directory, so individual tasks proceed in independent environments. However, even when a command moves to the background, the concurrency slot used by the worker is not released. Increasing background processes does not let the system get around the configured concurrency limit. Even when work is resumed by an automatic notification from CI or similar, it waits until a normal execution slot opens up.
In contrast, messages from people and status-check requests have one additional slot, separate from the normal concurrency limit. Even when all normal slots are full, the design secures room for a person to intervene in work in progress. Even if a large amount of work can be processed at the same time, management becomes harder if people cannot stop work midway or check its status. This extra slot is meant to avoid such situations, but it does not guarantee an immediate response at all times.
What matters here is that waiting on long-running commands, the number of tasks that can run at once, and room for human intervention are each managed by separate mechanisms. Moving a command to the background does not free a slot, and adding an intervention slot does not shorten the processing time of individual tasks. Beyond a simple number of parallel executions, the design extends to which processes to make wait and which requests to prioritize.
Continuously managing multiple tasks also requires a mechanism to reliably record the state of processing. According to the internal architecture specification, state changes related to tasks and decisions are consolidated in a processing unit called the "Engine" and saved using SQLite transactions. Rather than having each worker directly rewrite the overall state, the route for committing changes is centralized. This makes it easier to maintain the consistency of records even when multiple tasks proceed at once.
For operations on external systems as well, the structure first saves an internal record and executes the operation after the transaction is committed. This makes it possible to trace what operations the system decided on and what it tried to execute. However, being able to restore internal state is a separate matter from being able to safely re-execute operations on GitHub and the like. Even if a record remains, an external operation is not necessarily executed exactly once.
For that reason, after a restart the system gives workers recovery information and instructs them to check the working directory, Git history, and results on GitHub before repeating external operations. There is also a mechanism to hold automatic-notification input for tasks that failed or can no longer continue because of problems. A stopped task is not resumed unconditionally just because of a notification that CI succeeded. A resident agent needs not only the ability to continue processing but also the ability to distinguish tasks it can recover from those that should wait for human confirmation.
In simulated tests, median time to completion was 12.4 minutes
In the Super-agent design article published by DeepSeek's product department, different approaches to managing multiple agents are compared in experiments using synthetic workloads. In the experiments, about 300 messages were processed per run, of which about 20 were actual work requests. Each approach was run five times, with coding work replaced by a simulated tool that consumes a fixed amount of time. The arrival intervals of messages and the work durations were compressed to one quarter of the assumed real-world values, while measured values were used for the time taken by AI model calls. The experiment therefore measures the time taken for task assignment and coordination, not actual coding ability.
According to the results, Super-agent's time from request to completion was 12.4 minutes at the median and 15.7 minutes at the 95th percentile (p95). By contrast, in an approach that calls subagents from a single session as needed, the p95 was 29.5 minutes when given neutral instructions. In this comparison baseline, subagents were never called across the five runs, and all tasks were handled in the main session.
When the mechanism that forwards notifications directly to work in progress was removed, time to completion barely changed, but the number of coordinator decisions increased by about 30%. The number of tokens read from cache also rose by about 37%, from 23.23 million to 31.77 million. However, this is the increase rate for cache-read tokens and does not mean that total token consumption or actual billed costs rose by the same proportion. The experiment used limited synthetic workloads and does not indicate superiority in code quality or work speed in actual development settings.
Practical use requires OS-level isolation and GitHub-side protection
The public prototype has no built-in OS-level isolation mechanism, and DeepSeek's documentation on deployment and operations recommends measures such as running it under a dedicated OS account. Commands executed by workers run with the OS user privileges of the execution process and do not ask for approval each time an operation is performed. Even if a dedicated directory is provided for each task, access to files outside it is not restricted. Files and credentials made available to an AI agent therefore need to be managed, including the privileges granted to the execution process.
A wrapper that restricts specific commands also does not become an enforced safety boundary by itself, because specifying an executable by its absolute path can launch a command without going through the wrapper. Both the authorization management that records what the AI may do and a mechanism on the OS side that restricts what it can actually access need to be in place.
The same distinction applies to bringing in deliverables. In the public prototype, auto-merge conditions are specified through a prompt called "Delivery requirements," but the execution platform has no enforced decision mechanism dedicated to merging. DeepSeek recommends configuring branch protection on the GitHub side, requiring the necessary approvals, and invalidating old approvals when the content of a change is updated. Beyond instructing the AI to follow merge conditions, it is necessary to ensure that changes that do not meet the conditions cannot be merged on the GitHub side either.
DeepSeek's stated design philosophy is to minimize the attention and time people spend managing the AI. A mechanism that maintains the authorized scope while delivering necessary information, and that manages human intervention and recovery from failures, could reduce the burden of checking notifications and assigning work. However, the performance evaluation presented so far relies on synthetic workloads, and it remains unclear how much it would improve success rates, total operating costs, or human review time in real development work. Whether these effects can be confirmed in real environments, and whether a safe execution environment and appropriate approval procedures can be put in place, will be key challenges for bringing resident AI agents into practical use.