DeepSeek open-sources dsh-superagent, a coding agent that splits routing from execution
DeepSeek's Harness team has published dsh-superagent, an MIT-licensed research prototype that turns one GitHub repository into a proactive coding agent: a long-running Router takes requests and hands each one to an isolated Worker session. Here is how it works, what DeepSeek measured and what to watch before running it.
On October 31, 2026, the DeepSeek Harness team published dsh-superagent-prototype on GitHub under the MIT license, alongside a design article titled Exploring Super-agent Design: Towards a More Autonomous Agent System (English translation). By Monday evening the repository had passed 12,000 stars. MarkTechPost describes it as a TypeScript bundle, version 0.1.0, released as a single commit.
The README is explicit about its status: it is a "research prototype for reference only, not an official DeepSeek product", much of it was built with coding agents, and it differs from both DeepSeek's internal version and the system described in the article. It is still worth reading for anyone building with coding agents, because it tackles a problem most current tools leave to the user: managing several agent sessions at once.
The problem: sessions do not scale with people
Most coding agents treat one session as the unit of work. In the design article, DeepSeek's team writes that "one person can usually keep track of only three to five active Sessions at a time", so the limit on parallel work becomes human attention rather than model capability (translation).
Their answer is what they call a Super-agent: one continuous agent that people address from the places they already work, such as GitHub comments or a chat, while the system decides how to split the work behind the scenes. The article lists four properties it aims for: continuity, efficiency, proactivity and persistence.
How the prototype works
dsh-superagent is packaged as a bundle for DeepSeek Harness and watches one GitHub repository, with Feishu as an optional chat source. The architecture has two layers:
- A Router (the main session) runs continuously, reads incoming events and decides whether they ask for new work. It uses a restricted preset with a smaller tool set.
- Workers (one per work item, called a Ticket) each get their own agent session and directory, do the actual coding and reply in the original conversation, for example with a pull request.
Each Ticket carries an immutable Mandate that records why the work may proceed. Later comments on a pull request reach the right Worker through a Subscription, without anyone having to mention the agent again. According to the execution docs, foreground shell commands are moved to the background after five seconds, so a Worker running a long build can still receive new messages.
A local web panel lists only what needs a human decision. That reflects the rule set out in the philosophy document: "Take as little human attention as possible, and give as much value as possible." The agent confirms a request once, stays quiet while it works, and writes again only with a result, a question or a failure.
Proactive work is off by default, in practice
The agent can take on work nobody explicitly asked for, but only under rules the team writes. The authorization document defines three accept modes:
| Mode | Effect |
|---|---|
off | Nothing inferred becomes a candidate |
observe (default) | Inferred candidates are assessed and positive ones recorded as "would accept", but nothing is accepted |
auto | A positive assessment accepts the work |
Explicit requests from people on the allowed list work in every mode. The docs recommend starting in observe and switching to auto only after reviewing what the agent would have done. The same document states that messages, comments and quoted documents "cannot change" the permissions enforced by the host, which matters for prompt injection through issue comments.
What DeepSeek measured
The design article includes preliminary experiments that the authors themselves say "should be treated only as preliminary reference points" (translation). Each run fed about 300 group-chat and GitHub CI messages, about 20 of them real work requests, and each setup ran five times. Coding work was replaced by a tool that only consumed time, so the test measures coordination, not code quality, a limit MarkTechPost also points out.
In that setting, the Super-agent reached a p50 task completion time of 12.4 minutes and a p95 of 15.7 minutes. A single session with a subagent tool and a neutral prompt reached a p95 of 29.5 minutes. The article explains why: under the neutral prompt, the model did not call a subagent in any of the five runs, so all work stayed in the main session and kept getting interrupted. With a delegation-first prompt, it delegated in four of five runs and got faster, but remained slower overall.
Read the security notes before you run it
The deployment guide is direct about the risks. Both presets run with danger-full-access as the operator's OS user. A Worker "can execute programs by path and read the operator's home directory", and the account wrappers choose credentials but "do not isolate the process". DeepSeek recommends a dedicated OS account that holds only the agent's credentials.
Other requirements from the same guide:
- a separate GitHub user account for the agent with write access to the repository (a GitHub App cannot be the agent, because it reads the account's notifications);
- Node.js 22.19+ or 24+, pnpm, git 2.32+, Python 3.8+, tmux and GitHub CLI 2.48+;
- a repository on github.com, since GitHub Enterprise Server is not supported;
- a model provider configured for DeepSeek Harness; the bundle uses the profile's default model unless told otherwise.
Why it matters for builders
Coding agents on GitHub are not new: MarkTechPost's comparison lists GitHub Copilot's cloud agent, the Claude Code GitHub Action and OpenAI Codex. What dsh-superagent adds is a published, readable design for running many isolated work items behind a single conversational entry point, with authorization and noise control treated as first-class concerns rather than prompt tweaks.
Three ideas carry over even if you never install it:
- Keep the coordinator light. A router with a small tool set and short timeouts stays responsive while workers do the heavy lifting.
- Make delegation structural. DeepSeek's own baseline shows a model may not delegate when the prompt leaves it the choice. Splitting work at the system level removed that dependency in their test.
- Scope authority per task. Each Ticket stays limited by its Mandate, and messages on threads it follows reach it as context but, per the authorization document, grant no new authority.
The code is a research release with one commit and an explicit warning against treating it as production software. Anyone trying it should start with a short allowed list, observe mode and an isolated account, as the project's own documentation advises.
