Most coding agents wait for instructions. DeepSeek's Harness team released something different on October 31, 2026. Super-agent 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 it for work, it opens a work item, works on it in its own agent session and directory, and answers in the original conversation, for example with a pull request (deepseek-ai/dsh-superagent-prototype, GitHub, retrieved 2026-11-02). The idea is simple and challenging: human attention, not the model, is the limit that keeps many tasks from moving at once.
Key Takeaways
DeepSeek released dsh-superagent-prototype on October 31, 2026, under the MIT License, as a research prototype rather than an official product.
One Router session coordinates conversations and dispatch, while separate Worker sessions carry out each task with their own context and directory.
Work starts only on an explicit request or under a written team rule. Unrequested proactive work is, by default, only recorded in observe mode.
Every accepted job is recorded as a Ticket with a Mandate, which limits what the Worker may do and who was allowed to ask for it.
Running it needs DeepSeek Harness, a dedicated GitHub account for the agent, and several local tools. GitHub Enterprise Server repositories are not supported.
Why does attention matter so much? Most agents treat one session as one unit of work, and sessions do not share context. A person running several tasks in parallel must switch between sessions and remember what each one knows. DeepSeek's team argues that a person can usually follow only three to five active sessions at once, so human attention caps how many tasks can move together, even when the model could handle more (MadRobot's coverage). Super-agent is designed to change that division of labour. One agent remembers context across conversations, tasks run in parallel, and a person is called in only for a result, a question, or a failure.
What Is dsh-superagent?
Super-agent is an always-on agent system that works across conversations. It is not a new model, and it is not a hosted product. It is a way of organising agents that already exist so they can handle many jobs at once without a person coordinating every session. dsh-superagent is the research prototype that shows one form of that idea. The form is deliberately narrow: one GitHub repository, one team, and one web panel that shows only what needs a person.
The repository page retrieved on 2026-11-02 lists an MIT License, one commit, and a creation date of October 31, 2026 at 09:32 UTC. At the same time it showed 6,983 stars and 697 forks (deepseek-ai/dsh-superagent-prototype, GitHub, retrieved 2026-11-02). Those numbers measure early attention, not code quality. The speed of that attention is worth noting, but attention is not evidence that the agent works reliably on a real repository.
Aspect | dsh-superagent |
|---|---|
Released | October 31, 2026 |
License | MIT License |
Built by | DeepSeek Harness team |
Scope | One GitHub repository, plus Feishu if chosen |
Form | A bundle for DeepSeek Harness, not a standalone product |
Status | Research prototype, not production-ready software |
How the Router and Workers Divide the Work
Router is the always-running main session. It takes human conversations, keeps the context shared across tasks, and hands out work. It does not do the coding work itself. That separation matters: the Router stays available to take a new request even while several Workers are busy. Worker is a separate agent session for one job. Each Worker has its own context and directory, so a bug investigation, a code review response, and a feature change can proceed at the same time without contaminating each other's context.
Ticket is an accepted work item. Each Ticket carries a Mandate, a record that explains why the work may proceed. The Mandate records the matching rules, the policy version in force, and the source of the request. The Worker works only inside that Mandate. When the work is done, the result returns to the original conversation. If that result is a pull request, later comments on that pull request can be routed to the same Worker while the Ticket remains relevant.
The principle behind the whole design is stated in one sentence in the project's philosophy document: take as little human attention as possible, and give as much value as possible (philosophy document). In practice, the agent confirms a request once and names what it will do. It stays quiet while it works. It writes again only when a result is ready, when it needs a decision, or when it cannot finish. The web panel follows the same principle: it lists first what waits for a person, and a healthy state takes no space.
The Rules That Keep the Agent Quiet
Proactive does not mean free to act. The project's authorization document draws a sharp line between two kinds of request. An explicit request comes from a person on the allowed list who addresses the agent directly, and it works in every mode. An inferred candidate comes from a person not on the list, from a follow-up on a thread that already has a Ticket, or from a bot on the source's bot list. An inferred candidate never becomes an explicit request (authorization document). Messages, comments, and quoted documents are inputs to a decision; they cannot change permissions.
The accept mode decides what happens to inferred candidates. In off mode, nothing inferred becomes a candidate. In observe mode, the default, a candidate is assessed, and a positive assessment is recorded as would accept, but nothing is accepted. In auto mode, a positive assessment accepts the candidate. That gives a team a safe learning path: start with a short allowed list and observe mode, review the recorded decisions, and only then consider auto mode.
One warning deserves attention before anything is switched on. Every message on a thread followed by a Ticket reaches that Ticket as context. That delivery bypasses the gate but grants no new authority, and each Ticket remains limited by its Mandate (authorization document). Extra context is therefore not extra permission. Still, teams should be careful: messages on an open pull request can shape work already in progress. A short allowed list and written rules are not formalities. They are the main controls.
What It Takes to Run It
Setup is not trivial, and the documentation is honest about that. Prerequisites include Node.js 22.19 or later, or version 24 or later, pnpm, Git 2.32 or later, tmux, Python 3.8 or later, GitHub CLI 2.48 or later, and DeepSeek Harness within the version range in the project's package.json. The operator must also configure a model provider for Harness (setup guide). Feishu is optional and needs a bot plus lark-cli. Repositories on github.com are supported; GitHub Enterprise Server repositories are not.
The setup flow is designed so a coding agent helps the operator, not the other way around. The operator asks their coding agent to read SETUP.md and set the project up with them. That agent asks one short question per message, collects every answer, then sends one complete plan. The operator confirms the plan before anything runs. Steps only the operator can do, such as creating the agent account and signing CLIs in, are collected in a separate message. The guide also sets sensible defaults: a profile named superagent, a panel port of 3082, a branch prefix of agent/, and observe mode (setup guide).
Isolation is the part most easily underestimated. The Router and Worker sessions run with full access as the operator's operating system user, so a Worker can run programs and read that user's home directory. The agent's GitHub identity does not limit the process's local permissions. Independent coverage recommends a dedicated operating system account containing only the agent's credentials (Blockonomi's coverage). That advice matches the philosophy document's instruction to start narrow: use a dedicated GitHub account for the agent, never the operator's own, because everything the agent writes appears under that name.
What Independent Coverage Says, and What It Cannot Prove
Independent coverage agrees on two points. First, the release is interesting because it pairs a blueprint with runnable code. Second, it is not a product. MadRobot notes that DeepSeek's team already runs its own internal Super-agent, which, according to the team's design essay, reads feedback in group chats, works out a root cause, and submits a fix pull request without being tagged (MadRobot's coverage). That claim comes from the team itself and describes the internal system, not the public prototype. The distinction must be kept: the public prototype is stated to differ from the internal version, and some ideas in the design essay are not implemented.
The only performance numbers circulating come from DeepSeek's own simulation, not an independent benchmark. Secondary reports say each test used about 300 simulated messages containing about 20 real work requests, with each configuration run five times. In that simulation, half the tasks completed within 12.4 minutes and 95% completed within 15.7 minutes, against a single-session 95th percentile of 29.5 minutes (Asia Daily's report). Those numbers describe completion speed on simulated messages. They do not measure code quality, they do not use a real repository, and they do not prove the agent matches Claude Code or Codex. Do not read them as a ranking.
There is also an open security question the release does not answer. The project makes no claim of a security audit, and its documentation asks operators to review and adapt the code before using it in their own environment. That is the right warning for research code. A team testing this prototype on a real repository should treat it as untrusted code: limit its permissions, review its pull requests carefully, and do not let it merge automatically until its record of work has earned that trust.
Who Should Try It, and Who Should Wait
This prototype fits best for:
Teams already using DeepSeek Harness that want to test multi-task coordination on one repository.
Repository maintainers who receive many small requests and want one orderly entry point for an agent.
Agent tooling researchers and builders who want to study a Router and Worker design from real code, not only from an essay.
Teams willing to start in observe mode, read the recorded decisions, and tighten the rules before enabling automation.
Wait if you need a finished product, GitHub Enterprise Server support, or a security guarantee for a production repository. Wait also if the team is not ready to manage a dedicated account, review agent pull requests carefully, and accept that some design ideas remain future directions. This prototype is strong learning material. It is not yet an operational promise.
Frequently Asked Questions
Is dsh-superagent free? The code is free under the MIT License. Costs come from the infrastructure that runs Harness and the model access you connect. There is no license or subscription fee for the prototype itself.
Is Super-agent an official DeepSeek product? No. The project's README states plainly that it is a research prototype for reference only, not an official DeepSeek product. It also states that it is not production-ready software and may still contain bugs.
How many repositories can the prototype handle? One GitHub repository. That is the limit stated in the README. For cross-repository coordination, this prototype is the wrong tool. Our GitHub Copilot Projects article covers a different, cross-repository approach.
How does the agent decide whether it may work? An explicit request from a person on the allowed list is always processed. An inferred candidate is assessed against the team's written rules. Observe mode only records that assessment, while auto mode accepts a positively assessed candidate. Every accepted job is recorded as a Ticket with a Mandate that limits its scope.
Can the agent merge into the main branch by itself? The setup guide recommends no for auto-merge. People should merge the agent's pull requests until its record of work has been right for a while. The agent itself never enables auto-merge as the agent account.
How This Article Was Checked
The methodology behind this article is simple and traceable. We checked all 90 existing blogPost entries in Contentful on 2026-11-02, and none covered DeepSeek Super-agent. The primary sources are the project's GitHub repository, its philosophy and authorization documents, and its setup guide, all retrieved on 2026-11-02. Independent coverage from MadRobot and Blockonomi was used as a second check, not as a substitute for the primary documents. Simulation numbers are labelled as DeepSeek's own, reported secondarily, because no independent benchmark accompanied the release.
For example, a team that allows only two people to request work keeps the allowed list short by design. For example, that same team can run observe mode for a week, read what the agent would have accepted, and only then decide whether auto mode is safe. Those two steps, a short list and a recorded trial, are the cheapest controls in the whole design.
The Bottom Line
Super-agent changes the question about coding agents. The question is no longer only how well one session does one task. It is how many tasks can move at once without draining human attention. DeepSeek's answer is a firm separation: the Router coordinates, Workers execute, Mandates limit, and the panel shows only what needs a person. That separation makes sense, and the released code lets anyone inspect it. But it has not been proven at production scale. The available tests use simulated messages, and the internal version and the public prototype are stated to differ. Start with the GitHub repository and its philosophy document, or read the Indonesian version of this article. For a different angle on evaluation, see our Microsoft Scope article.