The DeepSeek Harness team released an MIT-licensed coding-agent prototype on 31 October alongside a design write-up for what it calls a Super-agent, Pandaily reported. Built for a single GitHub repository, the research code can take a permitted request, work on it in a separate session and return to the original conversation with a proposed code change, potentially as a pull request.
Key points
- The dsh-superagent-prototype repository packages a proactive coding agent for one GitHub repository as a DeepSeek Harness bundle.
- A resident Router assigns work to isolated Worker sessions, which can receive follow-up events from the threads they handle.
- In preliminary synthetic tests, the team reported completing half of roughly 20 work requests within 12.4 minutes, while using more cached tokens than the comparison system.
- The repository describes the release as research code rather than an official DeepSeek product and says some designs in the write-up remain unimplemented.
The 31 October release targets one repository
The repository, dsh-superagent-prototype, runs as a bundle for DeepSeek Harness, the open-source agent runtime on which the prototype is built. It watches GitHub and can also take events from Feishu, an optional chat channel. A request from an allowed user creates a work item with its own session and directory, separating that job from other work the agent may be carrying out.
The distinction between watching for an event and acting on it matters here. The prototype is designed to begin work when a permitted request arrives, rather than requiring someone to start a fresh coding session for each task. A team-defined rule can also create a work item, according to Startup Fortune. The resulting work returns to the conversation that prompted it, where a pull request would present a proposed code change for review.
Startup Fortune reported that DeepSeek released the separate, MIT-licensed Harness runtime on 13 August 2026. The prototype sits on top of that runtime rather than forming part of the same repository. That arrangement gives builders access to both the underlying agent software and an example of how to organise a coding agent around incoming repository work.
Router and Workers divide the coding work
In the team’s design, a resident Router handles incoming interactions and assigns jobs, while isolated Worker sessions carry them out concurrently and report back. The Router does not perform the coding itself. Each Worker can subscribe to the conversation threads relevant to its task, so a later pull-request comment or chat message can reach the session already working on it without another routing decision.
It is a division much like a reception desk and separate workbenches: the desk decides where a request goes, while each bench keeps the materials for its own job together. Here those materials are the session and directory attached to a work item. Keeping follow-up events with the relevant Worker is also meant to spare the Router from repeatedly deciding who should handle a discussion it has already assigned.
Fixing a reported bug could begin with a request in a repository conversation, proceed in its own session and return to that conversation as a proposed code change. A later review comment could reach the Worker handling the request. Those steps follow the prototype’s request and routing design; they would depend on the request being permitted and the work producing a change worth proposing.
The broader design write-up also describes filtering incoming events first with deterministic code and then with a model, as well as an external Watchdog session that checks whether Workers are making progress. Pandaily reported that, among the team’s own users, the agent quietly tries to reproduce bug reports and only speaks up upon finding a simple fix, sometimes opening a pull request before anyone tags it. The repository says some designs in the write-up are not implemented in the released code.
Synthetic tests measured roughly 20 requests
On preliminary synthetic workloads containing about 300 messages and roughly 20 work requests, the team reported completing half of the tasks within 12.4 minutes and 95% within 15.7 minutes, Pandaily reported. Its comparison was a single session using a subagent tool: the Super-agent finished sooner on that workload but consumed more cached tokens. The team called the results a preliminary reference.
The team also tested two routing choices. Without follow-up events going straight to Workers, Router decisions rose by about 30%. Batching events under load reduced inference time per Router decision from 6.4 seconds to 1.6 seconds. Both measurements concern the Router’s handling of this test workload, rather than the time needed to review or merge a proposed code change.
The repository’s README describes the prototype as research code, not an official DeepSeek product. Startup Fortune reported that it is not production-ready and that DeepSeek warns users of the experimental Harness runtime to review plugins and generated commands and run the software with minimal privileges. The team’s listed open problems include Router scaling, long-term memory, communication between agents and prompt-injection risk when a cloud agent can access credentials on local devices.
