DeepSeek Super-agent · Research Prototype · October 2026

DeepSeek Super-agent Prototype: A Router, Parallel Workers, and Pull Requests — Not a Product Launch

On October 31, 2026, DeepSeek's Harness team open-sourced dsh-superagent-prototype, an MIT-licensed research prototype that lets one coding agent serve a whole team's GitHub repository: a resident Router listens, and isolated Workers do the coding in parallel and answer with pull requests. The important sentence is in the README itself: this is a research prototype for reference only, not an official DeepSeek product, and not production-ready. This page separates what the prototype actually ships from what the accompanying design essay only proposes, and puts the safety gate first — because that is the part most coverage skips.

Last updated: November 2, 2026. Facts checked against the repository deepseek-ai/dsh-superagent-prototype (created October 31, 2026, 09:32 UTC, MIT license) and secondary reporting of its README and deployment guide. Star counts below are dated snapshots, not live totals; the simulation figures are DeepSeek's own and are not independent measurements.

At a Glance

The Three Pieces: Router, Workers, Pull Requests

1. A resident Router that does not code. The Router stays on, receives human interactions, keeps information shared across tasks, and assigns work. It avoids doing the coding itself, so coordination stays available while Workers are busy. A lighter, faster model is often enough for this role, according to the design essay.

2. Workers that each own one job. Every accepted request becomes a work item with its own agent session and directory. A bug investigation, a code-review response, and a feature change can therefore proceed in parallel instead of queueing behind one agent conversation. Workers report results to the Router, which is the single voice back to people — separate sessions do not reply independently.

3. Answers that land where the work started. Results go back to the original issue or chat thread, for example as a pull request. Drafts are marked unfinished, and the web panel lists only what needs a person — the concrete form of the “as little human attention as possible” principle. If a result needs no human, it should not demand one.

Prototype vs. Article: Do Not Merge Them

This is the most common error in coverage of this release, and the README warns against it directly. The design essay describes a Super-agent with a Router plus Worker pool, speculative execution, and 24/7 persistence, plus a Watchdog that recovers from failures. The shipped prototype is narrower: one repository, GitHub plus optional Feishu input, and work items answered with pull requests. Some designs in the essay are future work, and the prototype differs from DeepSeek's internal version. When you read a claim about Super-agent, ask first: is this in the released code, or only in the essay?

The same discipline applies to performance. DeepSeek's simulated runs (about 300 messages, about 20 real work requests each, five repeats per scheme) reported a same-caliber p95 of 15.7 minutes versus 29.5 minutes for the comparison setup. That is a simulation result from the team that built the prototype — useful as a design signal, useless as a purchase or adoption argument. There is no independent benchmark here, and the prototype's own README says it may still contain bugs, with much of its engineering done by coding agents.

The Safety Gate: Check This Before Any Real Repository

A third-party code reading of the prototype reports a sharp asymmetry: by default, only one kind of message can start work — an explicit request from an allowed person who @-mentions the agent — but once a pull request exists, every comment on that thread reaches the Worker, whoever wrote it, and some message kinds can wake a finished ticket after merge. Treat that reading as a warning to verify, not as a guarantee: open the policy file in your own checkout and confirm exactly which messages can start work, which can reach a running Worker, and which can wake a finished one, before the agent ever touches a repository you care about.

The minimum safe pilot, in order: a dedicated GitHub account for the agent with minimal privileges; a throwaway repository, never production code; human review of every pull request before merge; and the agent's runtime kept up to date — secondary reporting notes a recently fixed sandbox-escape flaw in DeepSeek Harness, so never run a stale preview build and never expose its local control port through a tunnel or proxy. Unrequested work, where enabled at all, should start in observe mode — logged, not executed — until the team has written an explicit rule for it.

Try It: Prerequisites, Honestly Stated

The deployment guide lists a dedicated GitHub account, Node.js 22.19 or later, GitHub CLI 2.48 or later, plus git, pnpm, Python, and tmux, with a model provider configured in DeepSeek Harness. It supports github.com only — other GitHub hosts are not in scope. If any of that sounds like overhead for a weekend experiment, that is the point: this prototype is built for teams that already live in GitHub and are comfortable on the command line, not for a casual tryout. The transferable idea for everyone else is the pattern itself — one coordinator, isolated parallel workers, results returned to the conversation that asked — which you can reuse in your own agent workflow without installing this prototype at all.

Related guides on this site: HackerTube — the agent-built feed pipeline, Cindy — a multi-harness agent that switches tools mid-task, and Mistral Large 4 — a large open-weight model guide.

Official sources: deepseek-ai/dsh-superagent-prototype on GitHub. Secondary reporting used for the dated star snapshots and the policy-file reading is cited in the FAQ where it matters; anything not confirmed in the repository itself is marked as such above.

FAQ