DeepSeek open-sources Super-agent prototype: Router-Worker design hits 15.7-minute P95 in simulation

DeepSeek has published an architecture write-up titled "Super-agent: Toward More Autonomous Agent Systems" and released a prototype on GitHub (deepseek-ai/dsh-superagent-prototype). In DeepSeek's simulated multi-task test, Super-agent had a median task completion time of 12.4 minutes and a 95th-percentile time of 15.7 minutes. The details were reported on October 31, 2026 by Chinese tech outlet QbitAI (量子位), in a Chinese-language article.

The problem DeepSeek targets

DeepSeek says that, by its observation, a person can follow only 3 to 5 active sessions at once. As models get better at single tasks, it argues, multi-task throughput is increasingly limited by human attention. Traditional coding agents spread work across separate sessions, so users must track where each one stands and re-supply context.

According to the write-up, in an instance running inside DeepSeek's team, one development task can continue from an IM group chat through to a GitHub PR review. If a user picks option A in chat and then asks for option B in a GitHub comment, the agent treats both messages as the same piece of work and changes course.

Architecture

DeepSeek describes a two-layer design:

• Router: receives messages, assigns tasks and maintains global context.
• Worker: a set of agent sessions that execute tasks in parallel without interfering with each other.
• Subscription and pass-through: a Worker that takes a GitHub PR can subscribe to later comments, so follow-up feedback goes directly to it without passing back through the Router.

DeepSeek lists four target properties: continuous (context kept across sessions and platforms), efficient (parallel execution, with long tasks not blocking new interactions), proactive (watches the environment and acts when needed) and persistent (long-running, with automatic recovery attempts).

Autonomy mechanisms

• Speculative execution: when the agent spots something that may need handling, such as a bug discussed in a group, it starts reproducing it and looking for the cause in the background. It surfaces a result only if it finds a workable fix, and stays quiet otherwise.
• Two-level event filtering: programmatic rules first drop irrelevant messages, then an LLM decides whether the remaining events need action, to cut token use.
• Async ReAct Loop: the agent can respond to new instructions while a long task runs. DeepSeek says this is implemented in DeepSeek Harness but not enabled by default.
• Compute, state and execution separation: agent logic can run in the cloud with session state stored independently, while the local device keeps its working environment. If the computer goes offline, the cloud agent keeps task state and resumes when the device returns.
• Watchdog: a separate supervising agent that detects program faults and judges whether a task is stuck in an ineffective loop or off target, then attempts intervention.

Test results

DeepSeek simulated a collaboration environment with about 300 messages and 20 work requests. It compared Super-agent with a traditional single-session plus Subagent setup, running each configuration 5 times.

Configuration	Median completion	95th percentile
Super-agent	12.4 min	15.7 min
Single-session, neutral prompt	not stated	29.5 min

The efficiency gain carries token overhead. With the event pass-through mechanism removed, Router decisions rose by about 30% and cache-read tokens by about 37%, which DeepSeek presents as evidence that event routing lowers running cost.

The results are DeepSeek's own preliminary experiments in a simulated setting, and the write-up does not report third-party replication.

What this means

The release is an engineering design and a prototype, not a new model, and no model version, context window or pricing is attached. The notable content is how DeepSeek splits responsibilities: a Router that holds global context, Workers that hold task state, and direct subscriptions so follow-up events skip the Router. The reported figures suggest that routing design affects both completion time and token consumption. The roughly 30% and 37% increases when pass-through is removed are the clearest data point on that cost. Because the experiment is small (5 runs per configuration, simulated messages), teams evaluating the approach will want to test the open prototype against their own workloads before relying on the timing numbers.