DeepSeek's Super-agent Design Explained: Router, Workers, Event Triggers, the Cloud Split and the Catch
On November 1, 2026, the DeepSeek Harness team published "Exploring Super-agent Design", a blueprint for one always-on agent that works across chat, GitHub, email and CI, plus an MIT-licensed research prototype called dsh-superagent. Here is how the Router and Worker layers, event triggers, the cloud/state/machine split and the Watchdog fit together, what DeepSeek's tests showed and what is still unsolved.
What DeepSeek published on November 1, 2026
On November 1, 2026, the team behind DeepSeek Harness, DeepSeek's desktop agent app, published a long technical article on X titled Exploring Super-agent Design: Towards a More Autonomous Agent System. At the same time it released dsh-superagent, an MIT-licensed research prototype on GitHub. The idea: stop treating a single chat session as the unit of work, and instead run one continuous agent that listens to where a team already works, handles many tasks in parallel and keeps going without someone babysitting it. The South China Morning Post framed it as DeepSeek's move in the coding-agent race with OpenAI and Anthropic. This page is the long-form briefing behind the BSH Technologies Instagram carousel.
DeepSeek is careful to say the article "discusses architectural ideas" and is "not an introduction to existing features of DeepSeek Harness". It describes an internal Super-agent instance that already runs on Harness and helps the team with development work.
The four traits of a Super-agent
DeepSeek defines a Super-agent by four characteristics, and argues that no single ReAct loop can deliver all four, so they have to come from the system around the model:
- Continuous: you talk to it in IM chats or GitHub comments and it always feels like one agent. Ask for Plan A in chat, switch to Plan B in a pull request comment, and it adjusts.
- Productive: it responds quickly and runs several complex tasks in parallel, taking the next instruction before the last one finishes.
- Proactive: it watches events in its environment, acts on what is worth handling and stays quiet otherwise.
- Persistent: it is always online, connects to your real working environments and recovers from failures on its own.
That puts it in the same family as other always-on agent efforts we have covered, such as OpenAI's Dots always-on agents and Anthropic's proactive Claude Duet app, but DeepSeek's piece is an architecture paper rather than a product launch.
1. The two-level architecture: one Router, many Workers
Routing every event into one session gives perfect context but low throughput; giving every event its own session gives throughput but disconnected results. DeepSeek splits the difference:
- Router layer: a long-lived session that receives every human message, coordinates across tasks and acts as the system's memory. It is designed not to execute tasks, "and it can run without a Bash tool at all". When events pile up, it batches them into one model call.
- Worker layer: each Worker gets an isolated context, a full set of tools and exactly one task. Workers "usually need the most capable models", never talk to humans directly and report back to the Router, which writes every reply.
DeepSeek stresses this is not the same as an Agent Team: the Router only dispatches and tracks how tasks relate, it does not break tasks into steps. A Worker can still spin up subagents or its own team internally. Compare that with Microsoft's leaderless approach in Agensh, where 1,024 agents work with no boss.
2. Event-driven: it listens instead of waiting for prompts
Hooked up to real group chats, GitHub, email and CI, the agent sees a noisy stream in which most messages need nothing. Borrowing the fast path / slow path idea from computer systems, DeepSeek filters in two stages:
- Programmatic policies (fast path): code checks the source, group and allowlists and drops most noise before any model is called. Each source can be set to respond only to explicit requests, treat messages as candidates, or ignore them.
- Semantic policies (slow path): only candidate events reach the LLM, which decides whether to act based on policies written as prompts, which humans can change at any time.
Consecutive events on the same pull request, IM topic or email chain form a Thread. The Worker that picks up a task subscribes to its Thread, so follow-ups pass straight through to it without another Router decision. To fit all this into a context window, DeepSeek treats the window like a cache ("Inline & Spill") and links tasks, Threads and sessions by ID so the model can walk back through history ("Chain of Recall").
The most striking part is acting ahead, borrowed from speculative execution. In DeepSeek's internal user group, the agent was set to silently reproduce and fix reported bugs. When a user complained about a macOS click bug, nobody @-mentioned the agent, yet it reproduced the issue, found the Electron root cause and opened a pull request with before and after screenshots.
3. Full-duplex: it keeps talking while work runs
Long tool calls are replaced with asynchronous start() and stop() calls, so the agent can answer people while commands run in the background. DeepSeek says Harness already implements this, "but it is not yet enabled by default". Each channel also gets its own manners: short, low-interruption replies in IM (a hard cap of 100 words per reply worked well) and detailed, structured output in GitHub, email and documents.
4. Separating compute, state and machines
To be always online, the agent loop runs in stateless, elastic cloud containers and session state lives in a database. Instead of copying your environment into a cloud sandbox, each machine runs a lightweight daemon that only executes commands and returns results. DeepSeek calls this BYOM (Bring Your Own Machine): the agent can use your real dev machine, with its uncommitted changes and local setup, and finish device-specific tasks when an intermittently online laptop reconnects. DeepSeek notes Anthropic's "Decoupling the brain from the hands" takes a similar approach for managed sandboxes.
5. The Watchdog
An independent Watchdog session runs outside the main system on a schedule. It handles infrastructure failures such as API errors, uses the model to judge whether each Worker is making real progress or drifting, and fixes problems. Because it is itself an agent, maintainers can ask it in plain language why something failed or have it adjust prompts and trigger rules while the system runs.
What DeepSeek's tests showed
DeepSeek calls these preliminary experiments. Each run had about 300 group-chat and GitHub CI messages, about 20 of them work requests; coding was simulated by a tool that just consumes time, so the test measures scheduling and coordination, not coding ability. Each design ran 5 times.
- Super-agent: 12.4 min median (p50) and 15.7 min p95 task completion, using 23.2M cache-read tokens per run.
- Super-agent without pass-through: 12.6 / 15.5 min, but the Router made about 30% more decisions and tokens rose to 31.8M (about 37% more).
- Single session with a subagent tool, neutral prompt: 20.4 / 29.5 min. The model never delegated in any of the 5 runs.
- Single session, delegation-first prompt: 13.8 / 29.0 min.
The trade-off is explicit: Super-agent spends more tokens (6.1M to 10.8M for the single-session designs) to get shorter, more stable completion times.
In a separate Router stress test, raising decision-needing triggers from about 1 to about 40 per minute grew the average batch from 1.0 to 2.8 while time per request only rose from 2.5 s to 3.9 s, so the amortized time per decision fell from 6.4 s to 1.6 s.
The prototype: dsh-superagent
The dsh-superagent repository is a proactive coding agent for one GitHub repository, packaged as a bundle for DeepSeek Harness. It listens to GitHub and, optionally, Feishu; when an allowed person asks for work, it opens a work item, does it in its own session and directory and answers in the original conversation, for example with a pull request. A web panel shows what needs a human. Setup is done by asking your coding agent to follow the repo's SETUP.md. If you want the model side of DeepSeek's recent work, see our breakdown of DeepSeek V4.1-Flash-1017 and its search API.
The catch
- Not a product: the README calls it a "research prototype for reference only, not an official DeepSeek product", says it differs from the internal version and that some designs in the article are not implemented.
- Self-reported, preliminary numbers: the tests used simulated coding work and DeepSeek's own workloads.
- Security is unsolved: DeepSeek writes that if a server intrusion or prompt injection compromises the cloud agent loop, "every endpoint device connected to it could be taken over", and credentials on endpoints can leak into the model's context. For how vendors are approaching agent guardrails, see Nvidia's OpenShell and Sentry.
- Open questions: long-term memory, when to shard the Router, how to present work without sessions, and secure agent-to-agent (A2A) collaboration.
Sources
Frequently asked questions
What is DeepSeek's Super-agent?
It is an architecture published by the DeepSeek Harness team on November 1, 2026 for one continuous, always-online agent that works across IM, GitHub, email and CI, runs many tasks in parallel and acts on events without being prompted. DeepSeek runs an internal instance on DeepSeek Harness.
How does the Router and Worker design work?
A long-lived Router layer handles all human interaction and dispatches tasks without executing them (it can run without a Bash tool). Each Worker session gets an isolated context, full tools and one task, usually on the most capable model, and reports back to the Router, which writes every reply.
How much faster was it in DeepSeek's tests?
In preliminary tests with about 300 messages and 20 work requests per run (coding simulated, 5 runs), Super-agent completed tasks in 12.4 minutes at p50 and 15.7 at p95, versus 20.4 and 29.5 minutes for a single session with a subagent tool and a neutral prompt.
Can I use dsh-superagent?
Yes, the MIT-licensed prototype is on GitHub at deepseek-ai/dsh-superagent-prototype. It covers one GitHub repository plus optional Feishu, runs as a DeepSeek Harness bundle and is described as a research prototype, not an official DeepSeek product.
What are the risks?
DeepSeek says security and privacy are unsolved: a compromised cloud agent loop, through server intrusion or prompt injection, could take over every connected endpoint, and credentials on endpoints can leak into the model's context.
From the blog
View all posts
Apple Intelligence Is Coming to China With Alibaba's Qwen: Features, iOS 27.3 Dates, iPhones and the Catch
On October 31, 2026, Apple confirmed that the first Apple Intelligence features are coming to iPhone users in mainland China, with Alibaba's Qwen built into Siri, Writing Tools and Visual Intelligence. Testing starts November 4 in the iOS developer beta and the public launch comes with iOS 27.3 in December. Here is every feature, how the Qwen hand-off works, which iPhones qualify and what is still missing.
One robots.txt Line to Opt Out of AI Training: OpenAI, Google, Microsoft and Anthropic Back __usage_ai-training
On October 30, 2026, OpenAI, Google and Microsoft said they will honor a shared robots.txt token, __usage_ai-training, drafted at the IETF by Anthropic's Kevin Kelley. One group in robots.txt can now tell every participating AI lab not to train on your site. Here is the exact syntax, each company's timeline, Bing's new grounding controls and what the token cannot do.