DeepSeek Super-agent (dsh-superagent): how the Router–Worker coding agent works, and how to run it safely

On 31 October the DeepSeek Harness team published dsh-superagent, an MIT-licensed prototype of a proactive coding agent: it watches one GitHub repository (and, optionally, Feishu chats), decides which requests are work, does that work in its own agent session and directory, and answers in the original thread, usually with a pull request. Bloomberg framed it as DeepSeek's move against Anthropic's Claude Code; the code itself is more modest and more interesting than that headline.

This article reads the prototype's own documentation rather than the press coverage. You will see how its Router–Worker design turns a GitHub mention into a ticket and a pull request, who is allowed to make it work, what DeepSeek's preliminary numbers do and do not show, how to install it, and the part that matters most before you point it at a real repository: it runs commands with full access as your OS user, and its documentation says so plainly.

What is DeepSeek's Super-agent (dsh-superagent)?

dsh-superagent is a long-running orchestrator that sits between your team's conversations and a set of coding-agent sessions. Instead of waiting in a terminal for someone to type a prompt, it listens to the places where work is asked for, decides what deserves action, and dispatches it. The README states the goal as taking as little human attention as possible while giving as much value as possible.

It is built on DeepSeek Harness, DeepSeek's open-source coding agent, published on npm as @deepseek-ai/dsh. Super-agent is a plugin bundle for one Harness profile, not a separate model or service. The repository is written in TypeScript and had about 3,300 stars on GitHub two days after release. A companion design essay, Exploring Super-agent Design (in Chinese), describes a larger system; the README warns that the published code differs from DeepSeek's internal version and that some designs in the essay are not implemented.

How the Router–Worker architecture works

One resident Router session talks to people and decides; many Worker sessions, one per ticket, do the work in isolation and report back to the Router rather than to users. In the shipped code these are two Harness presets: dsh-superagent-router, with a smaller routing tool set, and dsh-superagent-worker (execution doc).

Three ideas from the design carry most of the weight. First, events are filtered twice: cheap program rules first, then a model judgement only for what survives. Second, after a ticket starts, later messages on the same thread are delivered directly to the subscribed worker, so the Router is not re-reading every pull-request comment. Third, every side effect (launching a session, delivering input, posting a reply) is written to a durable queue inside the same SQLite transaction as the decision, then executed after commit and retried with backoff. A crash between "decided" and "did it" resumes rather than duplicates; the architecture doc describes a single Runtime process holding a lock on the state directory for exactly this reason.

How a GitHub mention becomes a pull request

A request goes through six steps, all recorded in the store. The names below are the ones the architecture doc uses, so you can follow them in the source.

1. A Source calls receive(trigger). Intake stores it once and answers stored, duplicate or filtered.
2. The trigger goes to tickets already subscribed to its thread, or queues an Eval on its primary thread.
3. An assessment effect hands the candidate to the Router session, which calls decide.
4. An accept creates the Ticket, its Mandate, an Assignment, the thread subscriptions and an acknowledgement in one transaction.
5. A launch effect starts the worker session worker-<ticket id> in its own directory; delivery effects pass it further input.
6. Worker reports return through relay effects; replies go out through the Outbox and the source's CLI.

A ticket is done when none of its pull requests remain open. A pull request belongs to a ticket when the last path segment of its branch matches the ticket's short name, which is why the recommended prepare command names branches agent/$DSH_SUPERAGENT_NAME (execution doc).

Who can make the agent work: explicit, inferred and auto

Only allowed people can start work explicitly; everything else is at most a candidate, and by default candidates are only observed. Each source has a policy table that marks every combination of sender and message as explicit, inferred or ignore, plus an accept mode that decides what happens to inferred candidates (authorisation doc).

Two details are worth knowing before you widen the policy. Bots on a source's bot list can only produce inferred candidates; they cannot make explicit requests or stop tickets. And automated reviewers that use ordinary GitHub accounts count as people, so your team prompt has to say which accounts they are, or a review bot's comment can look like a human instruction.

The merge rule is softer than it looks. The default worker instructions never enable auto-merge from the agent's own account, because GitHub attributes the merge to whoever enabled it, and allow it only for a ready pull request with approvals covering the head commit and fewer than 200 changed lines. The execution doc is explicit that these are instructions to the model, not enforced rules. Enforce approvals with branch protection, not with the prompt.

Is a Router–Worker agent faster than one session?

In DeepSeek's own simulation, yes, but the test measures scheduling, not code quality. The design essay replays about 300 messages containing about 20 work requests, replaces the coding work with a tool that only consumes time, and runs each setup five times; the authors call the results preliminary (summary of the essay).

The striking number is the tail. A single session with a subagent tool reaches a similar median once it is told to delegate first, but its 95th percentile stays near 29 minutes, because one busy conversation still serialises the decisions. With a neutral prompt, the model never called the subagent tool in five runs. The cost moves the other way: the Super-agent read 23.23M cached tokens per run against 6.05M for the single neutral session, and turning off direct delivery to subscribed workers pushed it to 31.77M.

How to install dsh-superagent

Install DeepSeek Harness at the version the guide pins, build the bundle, create a dedicated superagent profile and link the plugin. These commands are verbatim from the deployment guide; run them once, on a machine that has no superagent profile yet, because re-running the profile command replaces the profile and deletes its cordis.patch.yml.

npm install -g @deepseek-ai/dsh@0.2.1-rc.3git clone https://github.com/deepseek-ai/dsh-superagent-prototype.git dsh-superagentcd dsh-superagentpnpm install && pnpm builddsh superagent --from-default-profile web --dump-config > /dev/nulldsh plugin --profile superagent add "link:$PWD"

The agent needs a regular GitHub user account with write access: the guide says a GitHub App cannot serve, because Super-agent reads the account's notifications. Give that account its own gh configuration so it never sees your personal token:

mkdir -p ~/.local/bincat > ~/.local/bin/gh-agent <<'EOF'#!/bin/shGH_CONFIG_DIR="$HOME/.config/gh-agent" exec gh "$@"EOFchmod +x ~/.local/bin/gh-agentgh-agent auth logingh-agent api user --jq .login

Then copy examples/profile.cordis.patch.yml to ~/.dsh/profiles/superagent/cordis.patch.yml, fill in every placeholder (the only required key is stateDir, an absolute path), and give each ticket its own checkout with a prepare command in the panel's Execution settings. This is the guide's example, with /home/me/src/widgets standing for your local clone:

git -C /home/me/src/widgets fetch --no-tags "https://github.com/$DSH_SUPERAGENT_GITHUB_REPOSITORY.git" "${DSH_SUPERAGENT_GITHUB_PR_HEAD:-HEAD}:refs/dsh-superagent/$DSH_SUPERAGENT_TICKET" &&git -C /home/me/src/widgets worktree add -b "agent/$DSH_SUPERAGENT_NAME" "$DSH_SUPERAGENT_DIR" "refs/dsh-superagent/$DSH_SUPERAGENT_TICKET"

Start it with scripts/dsh-superagent start, which runs dsh --profile superagent inside a tmux session called dsh-superagent and refuses to start a second copy; scripts/dsh-superagent status exits with 3 while setup is incomplete. Requests arrive by polling the agent account's notifications, once a minute by default. The guide notes one trap: a mention added by editing an existing issue body is never received, so ask in a new comment.

What breaks: dsh-superagent is not a sandbox

Every worker can run any program the operator's account can run. Both presets run with danger-full-access as the operator's OS user, commands run without approval, and the deployment guide says outright that the wrappers "establish defaults, not a security boundary": a worker can run a program by absolute path and read the operator's home directory.

Setup does reduce the obvious leaks. It strips environment variables whose names contain KEY, PASSWORD, SECRET or TOKEN, replaces your git configuration, removes GH_TOKEN and GITHUB_TOKEN, and makes names listed in DSH_SUPERAGENT_BLOCKED_COMMANDS fail. None of that stops cat ~/.aws/credentials or /usr/bin/curl. A prompt-injected issue comment from someone on your allow list, or an inferred candidate in auto mode, executes with whatever that account holds.

So follow the guide's own advice literally: run it under an account that owns nothing but the agent's credentials, on a machine or VM you can throw away, and keep personal CLIs out of its path.

# A user that owns only the agent's credentials and the repository clonesudo useradd --create-home --shell /bin/bash dsh-agentsudo -iu dsh-agent# as dsh-agent: install dsh, clone the repo, create ~/.local/bin/gh-agent,# and point stateDir at a path inside this home directory

Keep the policy narrow while you learn its behaviour: a short allow list, the default observe mode so inferred candidates are logged but never acted on, and required reviews in branch protection so that nothing the agent opens can merge without a person.

Super-agent compared with a single coding-agent session

The difference is who drives. A terminal agent session is reactive and holds one conversation; Super-agent is resident, owns many conversations and decides for itself which messages are work. That buys parallelism and a shorter tail, and costs tokens, setup and a much larger blast radius.

For most teams the useful output today is the design, not the daemon: durable effects, a gate before the model, thread subscriptions and a Router that never touches a shell are good patterns for any agent you build. The docs folder is numbered and short, and reading 000-philosophy.md through 007-architecture.md is worth an afternoon even if you never run it.

The one thing to remember: dsh-superagent is an orchestrator that decides when to act and then acts with everything its Unix account can reach. Give it an account that can reach very little, and let branch protection, not instructions, decide what merges.

Sources and further reading

• dsh-superagent-prototype on GitHub: README, authorisation, execution, deployment, architecture, philosophy
• DeepSeek Harness team, Exploring Super-agent Design: Towards a More Autonomous Agent System (Chinese), and the English walkthrough by AgentsPulse
• DeepSeek Harness on GitHub and deepseek.com/en/harness
• News coverage: Bloomberg, 1 November 2026 and AICoder, 31 October 2026
• GitHub Docs: about protected branches