On the evening of October 31, the DeepSeek Harness team published a long post titled “Super-agent design exploration: toward more autonomous agent systems.” It proposes a two-layer agent architecture and puts a prototype, dsh-superagent-prototype, on GitHub. The team states in the post that the prototype exists to validate a technical direction and is not an official DeepSeek product.
The post starts from a plain observation: a model needs less and less human intervention to finish a single task, so the bottleneck on productivity has become human attention. By the team's account, one person can usually keep up with only three to five active sessions at a time, and once there are more tasks they have to switch back and forth by hand and remember the context themselves.
A session should be an implementation detail of the system, not a cognitive burden on the user.
The Router handles conversation, the Workers do the work
The architecture has two layers. An always-on Router layer receives human messages, maintains global context and assigns tasks. It carries no execution tools such as Bash and can be driven by a lightweight model. The Worker layer consists of multiple sessions with isolated contexts, each equipped with the full toolset and the strongest model, each focused on a single job and running concurrently. Workers do not reply to the user directly; status and results are reported to the Router first, and the Router speaks to the outside world on their behalf.
Several other design pieces revolve around keeping the agent always online:
- Event-driven: group chat messages, emails, calendar reminders, code review comments and CI results all count as triggers. Program rules filter out most of the noise first, and only what remains goes to the model to decide whether to act. For a thread that has already been assigned, later events are delivered by the program straight to the corresponding Worker without passing through the Router again.
- Asynchronous ReAct loop: time-consuming tool calls are split into start() and stop(). After a background task is launched it immediately returns Started, the foreground keeps taking the user's messages, and the result comes back to the session as a new event.
- Separation of compute, state and environment: the agent loop and its state live in the cloud, while the execution environment can stay on the user's own machine and run only a lightweight daemon, which supports bring-your-own-machine (BYOM).
- Watchdog: a separate session wakes up on a schedule. Besides checking whether processes are alive, it has the model judge whether each Worker is making substantive progress and whether its direction has drifted.
The post also gives an example of “speculative execution”: when someone in a group chat reports a bug, the agent first tries to reproduce and fix it in the background. It speaks up only if the fix works, and does not bother anyone if it doesn't.
The numbers come only from synthetic workloads
The team ran a comparison experiment with about 300 messages per round, of which about 20 were work requests and the rest chatter and noise, repeating each setup five times. The super-agent completed tasks with a p50 time of 12.4 minutes and a p95 of 15.7 minutes. The control group, a single session plus subagents, had a p95 of 29.5 minutes under a neutral prompt. With the event pass-through mechanism removed, the Router made about 30% more decisions and read about 37% more cache tokens.
In the Router stress test, triggers were raised from roughly 1 per minute to roughly 40. The average batch size rose from 1.0 to 2.8 and the time per request went from 2.5 seconds to 3.9 seconds, while the inference time spread across each decision actually fell from 6.4 seconds to 1.6 seconds.
The limitations are stated plainly. The experiments used synthetic workloads and a simplified environment, and measure only scheduling and collaboration, not how well any single task is done. The super-agent's token overhead is higher than a single-session setup, but the total has not been disclosed. The open-source prototype currently targets only a single GitHub repository, and cross-device operation, always-on cloud residency and the Watchdog are not fully implemented.
From dsh to the super-agent
Laying out the timeline, DeepSeek first released a framework on the agent track and is now releasing its thinking on orchestration. Around August this year it open-sourced the agent framework DeepSeek Harness (command-line name dsh) under the MIT license, with the file system, shell, model adapters, web UI and subagents all built as replaceable plugins. Over the following months models such as V4.1 Flash came online, and third-party coding tools began using it as their main model.
This post moves up a level. The question it discusses is how a single agent instance can keep an eye on dozens of things at once. The team revealed that the asynchronous task mechanism described in the post has already been written into DeepSeek Harness but is off by default. Internal instances built on the same idea have been running continuously, used to reproduce and fix issues, respond to code review, and iterate on the Harness itself.
The open problems the team lists include how the Router layer scales with task volume, long-range memory spanning months, and communication among multiple agent instances. The security item is the most specific: if a cloud agent loop is hit by prompt injection, the local devices connected to it could be taken over, and credentials placed in the model context could leak during normal execution. The post does not offer a complete answer on how to defend against these risks.
Sources: the DeepSeek Harness team's technical post and the dsh-superagent-prototype repository notes, ITHome, CocoLoop, Phoenix New Media Tech; experiment timings and stress-test figures follow the synthetic-workload results published by the team.