DeepSeek Super-Agent: The Always-On Router and Worker Design
TL;DR
DeepSeek open-sourced dsh-superagent, an always-on coding agent built on a router and worker split. What the design says, what the code ships, and the safety debate.
On October 31, 2026 the DeepSeek Harness team open-sourced dsh-superagent, a coding agent that lives on one GitHub repository, waits for allowed people to ask for work, and opens pull requests in its own worker sessions. It shipped with a design article, "Exploring Super-agent Design: Towards a More Autonomous Agent System", that argues the unit of agent work should stop being the session. If you searched "deepseek super-agent", this is what the repo contains, the idea underneath it, and the part the discussion keeps circling: how much autonomy to hand an always-on agent.
What DeepSeek published#
The dsh-superagent-prototype repo is MIT licensed, TypeScript, and packaged as a bundle for DeepSeek Harness. Its README is blunt about status: a research prototype for reference only, not an official DeepSeek product, adapted for publication, and not identical to the internal version. It also says some designs in the article are future directions that are not implemented.
What it does, per the README: it listens to GitHub and, optionally, Feishu. When someone allowed asks for work, it opens a work item, runs it in its own agent session and directory, and answers in the original conversation, for example with a pull request. A web panel shows what needs a person. Setup is delegated to your own coding agent: you ask it to read SETUP.md and set the project up with you.
For background on the runtime underneath, see our read of the DeepSeek Harness code and the agent harness explainer.
The core idea: sessions are an implementation detail#
The design article (a translation of the original Chinese post, so treat wording as approximate) starts from a complaint. Agents use one session as the basic unit of work, and when you run several things in parallel you switch sessions and remember what each one knows. The authors say one person can usually track three to five active sessions, so for a single task the ceiling is the model, and for many tasks the ceiling is human attention.
Their answer is a two-layer split:
- Router. A persistent session that handles every human entry point and assigns work. The article says it may not even have a Bash tool, and that a lighter model often suffices.
- Workers. Isolated sessions with the full tool set, one per task. They never talk to humans directly; they report to the router, which replies on their behalf, so you never get several agents answering at once.
Events that arrive while the router is mid-inference are queued and injected together on the next call. In their stress test (a real model for the router, a mock model for workers), going from about 1 to about 40 trigger events per minute raised average batch size from 1.0 to 2.8, request time from 2.5 to 3.9 seconds, and cut amortized inference per decision from 6.4 to 1.6 seconds. That is vendor-reported and a synthetic setup, but it explains why they argue one router session is enough at team scale.
The part worth copying: attention as the budget#
The repo's philosophy doc sets one principle: take as little human attention as possible and give as much value as possible. Every message, notification, setting and panel element has to earn its cost. The agent acts only when asked or when a written rule allows it, and it speaks only when a person must act or can use a result.
The authorization doc turns that into mechanics you can adopt even if you never run the project:
- Accept modes.
off,observe(the default) andauto. Inobserve, an inferred candidate that passes assessment is recorded as "would accept" and nothing is accepted. The docs say to start there and move toautoafter reviewing the recorded decisions. - Explicit versus inferred. A person on the allowed list who addresses the agent is an explicit request. Anything the agent notices on its own is inferred and needs a matching written rule.
- Bots cannot make requests. A bot on the source's list can produce an inferred candidate, never an explicit request, and cannot stop tickets.
- Policy is versioned. Each work item records the policy version it was accepted under, and weakening a rule can revoke it before it resumes.
If you run agents on a schedule today, the shadow-mode pattern is the Monday task: run the proactive path in record-only for a week, read what it would have done, then widen it. Our autonomous hours post covers the unattended-run side of the same problem.
Where it gets uncomfortable#
The execution doc says worker sessions run commands without approval as the operator's OS user. Its blocked-command list and wrappers are described as defaults, not a security boundary: a worker can still run a program by absolute path. Auto-merge is off by default for the agent account, and the default instructions only allow it for small pull requests (under 200 changed lines) with approvals covering the head commit.
The design article is candid too. Its security section says that unless the problems are addressed, a super-agent can operate only inside a small trusted scope, and that a cloud agent loop fed external events and connected to devices holding credentials is exposed to prompt injection. If you are weighing that exposure, read our sandbox architecture guide and Claude Code permissions guide before pointing any always-on agent at a repo with real secrets.
What people are actually saying#
The reaction is thinner than the star count suggests. The repo had about 3.9k stars and 367 forks when we read it, and it appeared on the GitHub new-repo trending list within a day.
- The Hacker News submission had 9 points and no comments when we checked, so there is no real HN debate yet.
- A r/DeepSeek post announcing the release and a r/singularity thread carry the news; the excerpts we could read were summaries, not analysis.
- The counter-case is a r/DeepSeek post titled as a claim that the super-agent direction is not safe, written by someone who says they use DSH with full access. We could read only the title and opening lines, so we are not summarizing its arguments. It lines up with the repo's own caveats above.
Our take: the novelty is the packaging, not the pieces. Router plus workers, event queues and ticketed work are familiar. What is new is shipping a policy layer where "stay quiet" is a first-class outcome. The weakness is that the same permission model that makes it quiet gives workers a full shell.
What to do this week#
- Read
000-philosophy.mdand002-authorization.md, about ten minutes, even if you never deploy it. - If you run your own triage or fix bots, add an
observemode that logs the action it would take before it is allowed to take it. - Separate "who may ask" from "what may run". An allowed-list check is not a sandbox.
- If you try the bundle, treat it as research code, use a throwaway repo, and run it as a user that cannot reach your real credentials.
For cost, the project is model-agnostic in principle, but DeepSeek's own 4.1 Flash daily coding model is the obvious cheap worker to try. Our loop engineering guide covers designing the loops these workers run.
FAQ#
What is DeepSeek's super-agent?#
It is an architecture, described in DeepSeek's design article, for an always-on agent that keeps one continuous identity across chat and GitHub while running tasks in parallel in isolated worker sessions. dsh-superagent is the open-source research prototype of it.
Is dsh-superagent production ready?#
No. The README calls it research code, warns it may contain bugs, and says some designs in the article are not implemented.
Does it need DeepSeek models?#
It is packaged as a bundle for DeepSeek Harness. We did not verify other model backends, so check the setup docs before assuming support.
Is it safe to give it write access to a repo?#
The docs say workers run commands without approval as the operator's OS user, and that blocked commands are defaults, not a security boundary. Start with a throwaway repository and a short allowed list.
Continue Reading#
- We Read DeepSeek Harness - the code-level read of the runtime this bundle runs on
- What Is an Agent Harness? - the layer between the model and your repo
- Claude Code Autonomous Hours - running agents unattended without losing control
- Agent Sandbox Architecture Guide - isolation options when workers get a shell
- Claude Code Permissions Guide - allow lists and approval modes in practice
Sources#
Get the next deep dive like this in your inbox
One email a week on DeepSeek and the rest of the AI dev stack. Free.
Read next on AI coding tools
We Read DeepSeek Harness: What 453K Lines of Agent Runtime Actually Say
DeepSeek Harness (dsh) code read: a 453K-line plugin runtime on a vendored Cordis fork, three patterns worth stealing, and the gaps the launch does not mention.
9 min readWhat Is an Agent Harness? A Developer's Map for 2026
An agent harness is everything around the model: loop, tools, context, sandbox. How Pi, DeepSeek, Codex and Claude Code differ, and how to choose.
5 min readThe Ralph Loop: Running Claude Code For Hours Autonomously
The Ralph Loop uses Claude Code stop hooks to keep an agent working autonomously for hours. How stop hooks, completion promises and max iterations fit together.
10 min readNew here? Start with
Technical content at the intersection of AI and development. Building with AI agents, Claude Code, and modern dev tools - then showing you exactly how it works.
