dsh-superagent is a proactive coding agent for a single GitHub repository, published by DeepSeek as a research prototype that runs as a bundle for DeepSeek Harness. It is aimed at small teams who already keep coding agents in their workflow and are tired of being the bottleneck for them: the people who spend the day answering a drip of small clarifying questions. The code is TypeScript under the MIT licence, published on 31 October 2026, and GitHub currently counts roughly 12,300 stars and 1,270 forks on it. The README is blunt about what this is: research code that grew out of the team's own day-to-day development work, much of the engineering done by coding agents, and not an official DeepSeek product.
What it does
The agent attaches to one repository and waits. It listens to GitHub and, optionally, to Feishu, a chat tool. When someone on the allowed list asks it for work, it opens a work item, does the work in its own agent session and its own directory, and then answers in the conversation where the request came from, for example by opening a pull request. A web panel sits on top of all of this and shows only what still needs a person.
The stated design principle, which the authors call a way of working rather than a feature, is to take as little human attention as possible and give as much value as possible. The reasoning in the README is that an agent able to act for a whole team can also waste a whole team's attention, so this one acts only when it is asked or when a rule the team wrote allows it, and speaks only when someone must act or can use a result. That argument is spelled out in docs/000-philosophy.md, along with what it asks of whoever operates the thing.
How it works
Because it ships as a bundle for DeepSeek Harness, Harness is the runtime: you are installing a configured agent into that harness, not a standalone server. Each request becomes a work item with its own session and its own working directory, which is what lets several requests run without stepping on each other and lets each answer go back to the thread that started it. Who may ask, and what the agent is allowed to do unasked, come from the allowed list and from rules the team writes. The panel is effectively an escalation queue rather than a dashboard.
Documentation is a numbered series meant to be read in order. One caveat the authors raise themselves: the published code has been adapted for release, so it is not identical to their internal version or to the implementation described in their article "Exploring Super-agent Design: Towards a More Autonomous Agent System", and some designs discussed there are future directions that this prototype does not implement. There are no benchmarks or performance figures in the material, only that design goal.
Getting started
The repository is github.com/deepseek-ai/dsh-superagent-prototype. The project does not list hardware requirements: no operating system, chip, memory or VRAM figures appear in the README. What it does need is DeepSeek Harness, access to the GitHub repository you point it at, and an LLM API key for the agent sessions; Feishu is optional.
On cost: the code itself is free and MIT licensed, but the intelligence is not. The agent sessions call a model, so somebody pays for that API key, and nothing in the material describes a local-model setup or states what DeepSeek Harness costs, so price that out before you commit a team to it.
Installation is not a plain clone. The README says setup has many steps and hands the job to an agent: you open your coding agent and ask it to "Read SETUP.md in this repository and set up dsh-superagent with me." It then asks one short question at a time, shows the full plan once, and installs and configures from there. No single install command is published.
When to use it / when not
The main catch is maturity. This is a days-old research prototype whose own README warns that it may still contain bugs and that its coding style and engineering practices may be inconsistent, and the published copy is not the version the team runs internally.
Use it instead of just opening a coding agent in your terminal when the work arrives as GitHub issues and comments from several different people and you want each request picked up, worked in isolation and answered in place without you relaying anything. Don't use it if you need a supported product, if nobody on the team has time to review an agent's commits, or if you want one agent across many repositories: this one is scoped to a single repo.
Take it seriously if you are a maintainer or a small team lead who already trusts coding agents with real work and whose actual problem is attention rather than capability. The code is worth reading even if you never deploy it, because the philosophy document and the work-item-per-session structure are a concrete answer to a question most agent setups dodge: when is an agent allowed to interrupt you. Treat it as a reference implementation to adapt, which is exactly what its authors ask, rather than as something to point at your main branch this week.