Chinese artificial intelligence developer DeepSeek has released dsh-superagent, an open-source research prototype designed to take software-development requests from approved people, work on them in separate agent sessions and return results through the conversation where the request began.
The MIT-licensed repository is intended to run with DeepSeek Harness and currently focuses on one GitHub repository. It can also listen to Feishu for chat-based requests. DeepSeek describes the code as a reference prototype rather than an official product and warns that it is not production-ready.
A router assigns work to separate agents
The project separates intake and execution. A main session receives requests and routes accepted work, while each task receives its own worker session and directory. The worker can create a reviewable result such as a pull request and report back to the original GitHub or chat thread.
A web panel is designed to show items that need human attention, including questions, reviews and failures. The project documentation says healthy work should remain out of the way rather than generate constant status messages.
That approach reflects the project’s stated operating principle: minimize the attention required from people while delivering useful results. In its philosophy document, DeepSeek says the agent should act only when asked or when a written team rule permits it. Proactive work starts in an observation mode that records what the system would have done before teams enable automatic action.
The release gives developers a public example of an always-on coding-agent workflow rather than only another command-line assistant. Independent coverage by On The Wire highlighted the project’s use of a routing session, isolated task sessions and explicit rules governing who can authorize work.
Authorization is central to the design
The authorization model distinguishes explicit requests from inferred candidates. Teams configure approved users, sources and rules, while the host enforces those limits. Messages, comments and quoted documents can inform a decision but cannot expand the agent’s permissions.
DeepSeek recommends that teams begin with a narrow allowed list and keep inferred work in observe mode until they are satisfied with the recorded decisions. Human follow-ups can continue an existing task when they remain within its scope, while broader requests return to the routing layer for a fresh decision.
The design is aimed at reducing two risks that emerge when coding agents run continuously: accepting instructions from the wrong person and turning every piece of activity into more agent work. The documentation also warns operators against mass pull requests, broadcast messages and other volume that costs more team attention than it saves.
The prototype carries material security caveats
The release is not a managed service with production guarantees. DeepSeek says the public code differs from its internal version, may contain bugs and does not implement every idea discussed in the associated design work.
The deployment guide says both the routing and worker presets run with broad system access as the operator’s operating-system user. A worker can execute programs and read the operator’s home directory. DeepSeek therefore recommends a dedicated operating-system account containing only the agent’s credentials.
Deployment also requires a separate GitHub account for the agent, a model provider configured in DeepSeek Harness and, for chat requests, an optional Feishu or Lark bot. GitHub Enterprise Server is not supported by the current setup.
dsh-superagent builds on DeepSeek Harness, which the company also labels a developer preview and says may introduce compatibility-breaking changes. Those warnings make the new repository most useful today as an inspectable reference architecture for authorization, task isolation and human review, rather than a turnkey enterprise product.
The release extends DeepSeek’s open-source push from models and computing tools into the orchestration layer around software agents. Adoption will depend on whether teams can contain the prototype’s system access, define workable authorization policies and keep its output useful without creating a new coordination burden.