The DeepSeek Harness team has published a description of their project, which they named the Super Agent. This agent is designed as a continuously operating system that simultaneously advances multiple tasks, independently seeks work, and recovers from failures. The corresponding research prototype was released on GitHub under the MIT license, according to Chinese tech media.
The dsh-superagent-prototype repository is a package of a proactive coding agent intended to work with a single GitHub repository within the DeepSeek Harness ecosystem. The agent monitors activity on GitHub, and optionally on Feishu. When an authorized user requests a task execution, the agent creates a work item, processes it in its session and catalog, and then responds in the original dialogue, for example, by creating a pull request.
The accompanying documentation emphasizes that this code is for research purposes and is not an official DeepSeek product, and some concepts described in the document have not yet been implemented.
System Architecture
The core concept is built upon a two-layer architecture. The Router session receives all human activity from different channels but does not perform the work and may not even have a Bash tool. Tasks are delegated to isolated Worker agent sessions, which execute work in parallel using a full set of tools, and send reports back to the Router, bypassing communication with users.
Each Worker agent subscribes to branches of interest, such as chat discussions or pull requests, allowing subsequent events to go directly to it without passing through the Router. The system functions based on events: triggers include messages in chats, emails, review comments, and Continuous Integration (CI) results, which are first filtered by deterministic code and then by the model.
The team also separated the agent's state and the execution environment so that the agent can remain active in the cloud while interacting with the user's local machines. An external Watchdog session is also used to monitor whether the Worker agents are making real progress. Within the internal user group, the team established a rule: the instance must silently reproduce reported errors and only report them after finding a simple solution, sometimes opening a pull request before anyone flags the issue.
During preliminary tests on synthetic loads, including about 300 messages and approximately 20 work requests, the Super Agent completed half of the tasks in 12.4 minutes and 95% in 15.7 minutes. These figures surpassed the results achieved by a single session with a sub-agent tool, although they required more cached tokens. Without direct routing of subsequent events to the Worker agents, the Router's solutions increased by approximately 30%, and batch processing under high load reduced the time to output one Router solution from 6.4 seconds to 1.6 seconds. The team called these results a preliminary benchmark.
Among the unresolved issues listed by the team are scaling the Router, long-term memory, inter-agent communication, and the risk of prompt injection if the cloud agent gains access to credentials on local devices.



