DeepSeek Open-Sources a Super-Agent That Works for a Whole Team and Tries to Stay Quiet
DeepSeek has open-sourced a prototype coding agent designed to work for a whole development team, not just one programmer in one chat window. The project, called dsh-superagent, appeared on GitHub on October 31, 2026, and it is built around a simple idea: when agents can do more of the work, human attention becomes the scarce resource, so a good team agent should stay quiet unless it has a result, a question, or a failure to report.
The release is a research prototype, and DeepSeek says so plainly. Its README calls the code a research prototype for reference only, not an official DeepSeek product. It also warns that the published code is not identical to the version DeepSeek runs internally, and that some designs in its design article are future directions rather than features in this prototype. This is not a hosted service, a new model launch, or a finished product. It is a readable, MIT-licensed codebase that other teams can inspect and adapt.
The prototype is packaged as a bundle for DeepSeek Harness, DeepSeek’s open-source agent program. It is a proactive coding agent for one GitHub repository. It listens to GitHub and, optionally, to Feishu, the workplace chat app from ByteDance. When an allowed person asks for work, the agent opens a work item, does the job in its own session and directory, and answers in the original conversation, for example with a pull request.
The design splits the work into two roles. A single long-running router session talks to people and hands out jobs. Each job then goes to its own worker session, with its own tools and clean context. Workers do not talk to people directly. They report back to the router, and the router replies. The reasoning is that one session for everything mixes jobs together, while a new session for every event leaves nothing with an overview and lets several sessions talk to the user at once. The router and worker split is meant to avoid both problems.
Attention discipline shows up in the details. The agent confirms a request once, then stays silent while it works. Chat replies default to one sentence, with a hard limit of 100 words. It asks one concrete question at a time. Every GitHub message starts by default with a line stating that it is by an automated agent, not a human.
Access control is equally strict, at least on paper. A request counts as explicit when someone on the allowed list tags the agent, and explicit requests always work. Anything else is only a candidate for work. Bots can only generate candidates, never ask for work outright or stop a job. Work that nobody asked for starts in observe mode by default. In that mode, the agent records that it would accept the work, but does nothing, so a team can see what it would have done before granting permission to act on its own. Quoted messages, comments, and documents are treated as data, never as permissions.
DeepSeek also published test results, with clear limits. In one test, the super-agent finished requests in 12.4 minutes at the median and 15.7 minutes for the slowest 5 percent, compared with 20.4 and 29.5 minutes for a single session using a subagent tool. The trade-off was token use: the super-agent read 23.23 million cached tokens per run, against 6.05 million and 10.82 million for the single-session setups. DeepSeek describes the results as preliminary. Each run involved about 300 messages and about 20 real work requests, coding was replaced by a tool that simply waits, and timing was scaled to a quarter, while the model calls were real. The test therefore measures scheduling, not code quality.
Trying the prototype today is still an expert exercise. It requires DeepSeek Harness 0.2.1 alpha, Node.js 22.19 or later, pnpm, git, tmux, Python 3.8 or later, and GitHub CLI, plus a configured model provider. It also requires a dedicated GitHub account for the agent, never a personal account, since everything the agent writes appears under that account. The practical advice is to start with a short allowed list, keep proactive work in observe mode, and use a test repository first.
Why does this matter beyond one repository? Coding agents are moving from personal assistants that help one developer finish one task to services that watch shared channels, triage requests, and open work for a team. That shift raises different questions from raw model quality: who is allowed to ask for work, what counts as permission, how much noise the agent creates, and who owns what it posts. DeepSeek’s prototype does not settle those questions, but it makes its answers checkable. The rulebook is in the repository, in nine numbered design documents, alongside the prompts the agent runs.
That openness is also the limit of the release. There are no benchmarks for code quality, no acceptance rate for its pull requests, and no cost estimate per work item. Several ideas in the design article, including a separate watchdog session, are described as future work. The right way to read this release is as a design proposal with working code attached: interesting, usable in a small and trusted setup, and best judged by how little it interrupts the team it serves.
