dsh-superagent: What DeepSeek's Open-Source Super-Agent Actually Does

dsh-superagent is DeepSeek's newly open-sourced prototype of a proactive coding agent, released on GitHub under the MIT license as a bundle for the DeepSeek Harness agent runtime. It watches one GitHub repository, and optionally the Feishu chat platform, and turns allowed requests into parallel units of work, each running in its own isolated agent session. DeepSeek is explicit about what this release is: a research prototype for reference, not an official product, adapted from the team's internal tooling and published alongside a design article called Exploring Super-agent Design: Towards a More Autonomous Agent System. This post walks through what the prototype does, how its authorization model works, what DeepSeek's own performance numbers do and do not show, and what a team should check before running it. Source

What dsh-superagent is, from the README

The README describes dsh-superagent as a proactive coding agent for one GitHub repository, packaged as a bundle for DeepSeek Harness. It listens to GitHub and, optionally, Feishu. When someone on an allowed list 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. A local web panel lists only what needs a person. The README also carries an unusually direct disclaimer: the code is a research prototype for reference only, much of its engineering was done by coding agents, it may contain bugs, its style may be inconsistent, and readers should review and adapt it before using it in their own environment. Setup requires Node.js 22.19 or newer, pnpm, git 2.32 or newer, Python 3.8 or newer, tmux and the GitHub CLI, and the repository ships a SETUP.md designed to be followed by a coding agent together with the operator. Source

The philosophy: attention as the scarce resource

The project's first document states the core rule plainly: take as little human attention as possible, and give as much value as possible. Every message, notification, question, setting and panel element is treated as a cost that must pay for itself. From that rule the docs derive concrete behavior. The agent acts only when asked, or when a written rule the team authored allows it. It confirms a request once, stays quiet while it works, and writes again only when a result is ready, when it needs a decision, or when it cannot finish. It asks one concrete question at a time, in a structured form. It stops by impact rather than effort: a local change goes as far as a reviewable result, while a change that needs a design decision stops with a clear question. The same document puts responsibility on the operator: start with a short allowed list, keep proactive work in record-only mode at first, tune noisy prompts to be shorter and stricter rather than adding explanatory messages, do not use the agent to produce volume, and read what the agent posts in your name. Source

How the router-worker architecture works

The design splits the system into a long-running Router and disposable Worker sessions. GitHub or Feishu events become Triggers from a Source. An Eval decides whether a batch of Triggers asks for new work. Accepted work becomes a Ticket, a unit of authorized work carrying an immutable Mandate that states why it may proceed. Each Ticket runs in its own session and directory, and Subscriptions route later comments, for example on a pull request the agent opened, back to the right Worker without a fresh mention. The architecture document describes an Engine that is the single writer of Triggers, Threads, Decisions, Tickets and Assignments, with each command changing its records in one transaction, and a pass loop that processes due work every two seconds. Shell commands inside a Worker move to the background after five seconds so Workers keep receiving messages. DeepSeek's stated motivation is that mainstream agents treat one session as the basic unit, while a person can actively follow only three to five sessions at once, so human attention, not model capability, becomes the bottleneck for multitasking. Source

Authorization: who can start work, and what work may include

The authorization document is the part most worth reading before any trial. The host enforces allowed lists, rules and Mandates, and it states explicitly that messages, comments and quoted documents are inputs to a decision and cannot change permissions. A request counts as explicit only when a person on the allowed list addresses the agent directly, or follows up on a thread that already has a Ticket. Other people's follow-ups produce at most an inferred candidate, and messages from bots that are not on the Source's bot list are not admitted at all. Proactive work is gated behind three accept modes: off, observe and auto. Observe is the default, and in observe mode the agent only records what it would have accepted, which gives a team a rehearsal log before any real action is enabled. Follow-up messages on a subscribed thread reach the owning Ticket as context and grant no new authority; each Ticket stays limited by its Mandate, and a person can stop a Ticket at any time, which withdraws the Mandate. Source

The performance claims, and their limits

DeepSeek tested the prototype against a single-session baseline on simulated traffic: group chat and GitHub CI streams of about 300 messages each, of which about 20 were real work requests, with each configuration run five times. In those simulations, the super-agent configuration finished with a p50 task completion time of 12.4 minutes and a p95 of 15.7 minutes, against a p95 of 29.5 minutes for the single-session baseline. Under the neutral prompt used for the baseline, the single-session agent called a subagent zero times in five runs. An ablation that removed direct event pass-through raised Router decisions by about 30 percent and cache-read tokens by about 37 percent, from 23.23 million to 31.77 million. These figures are self-reported by DeepSeek and come from synthetic messages and simulated tools, and real coding quality was not measured, so treat them as evidence about routing overhead under noisy message streams, not as a benchmark of code output. Source

Security posture: full-access workers by default

The deployment document states that both the router and worker presets run with danger-full-access as the operator's OS user, and that the account wrappers choose the agent's credentials by default but do not isolate the process. A worker can execute programs by path and read the operator's home directory. The document's own recommendation is a dedicated OS account containing only the agent's credentials. That default matters more here than in a single-session tool, because dsh-superagent is designed to act on behalf of a whole team: it comments, opens pull requests and messages people under accounts the team sees every day. Combine the dedicated-account recommendation with the observe accept mode and a short allowed list, and the prototype's own philosophy document makes the same point in plainer language: the more the agent can do, the more care its operator owes the team. For a broader control set around what tools an agent may call and with what scope, see our earlier guide on AI agent tool permissions. Source

Where this fits, in our assessment

Everything above is what the sources say; this section is our read. dsh-superagent arrives in a week when the agent tooling map is moving fast, days after Google announced the Jules turndown we covered in our Google Jules shutdown post, and it represents the opposite bet: instead of a managed cloud agent, a self-hosted router that multiplexes many workers against one repository. The ideas most likely to outlive the prototype are the boring ones: an explicit allowed list, a record-only observe mode as the default for proactive work, an immutable mandate per unit of work, and a panel that shows only what needs a person. Those are design patterns any team can adopt without running DeepSeek's code. What remains unproven is whether the prototype's simulated speed advantage survives contact with real repositories, real CI failures and real review conversations, and DeepSeek's own disclaimer says the published code differs from the internal version and the designs described in the article. If you evaluate it, the honest starting configuration is the one the docs themselves recommend: observe mode, a dedicated OS account, a short allowed list, and a read of every message it sends in your name. Source