DeepSeek's New Agent Can Handle GitHub Tasks Autonomously

Abstract

DeepSeek's team recently open-sourced dsh-superagent-prototype. The project addresses a common pain: an agent is fixing an interface issue, has read a dozen files, edited the code, and started running tests, when a documentation request arrives in the group chat. With a shared synchronous session, the new request waits. Even with interleaved handling, interface errors, documentation requirements and test output all bleed into the same context. dsh-superagent is designed to take over this collaboration layer: after a task is handed off, the system picks up the follow-up feedback itself and pushes the work to a reviewable result. This article examines what the prototype is, why it splits work into two layers, how a single bug advances through the system, and where its real boundaries sit.

1. The Problem dsh-superagent Targets

Consider a realistic scene. Several AI sessions run at once: one fixes a bug, another writes tests, a third reviews a pull request. A test fails, so the error has to be forwarded. A requirement changes, so the matching window has to be found. Another task stalls, and the developer has to ask what it is missing.

The core observation is blunt: the AI writes code while the human chases the AI. dsh-superagent targets exactly this coordination work. The design question is whether the system can accept the follow-up feedback after a task is handed off and keep driving it toward a reviewable result, instead of leaving the human to relay every message.

2. What dsh-superagent Is

dsh-superagent is a coding agent that runs on DeepSeek Harness. The public prototype targets a single GitHub repository and can also connect to Feishu.

When an authorized request arrives, the system creates a ticket, assigns a dedicated execution session and directory, and finally returns to the original discussion to deliver the result, such as submitting a pull request.

A critical caveat comes first: what is public today is a research prototype, not an official DeepSeek product. Some capabilities in the official design article are not implemented in this repository. The rest of the article therefore combines the public prototype with the architecture design. For actual deployment, the capabilities currently offered by the repository are the source of truth.

3. Why Split the Work into Two Layers

The starting point is a concrete example. The agent is fixing an interface issue. It has read over a dozen files, edited the code, and started running tests. A documentation requirement arrives from the group. If everything shares one synchronous session, the new requirement waits. Even if the tasks alternate, the interface error, the documentation requirement and the test output keep mixing into one context.

dsh-superagent splits the work into two layers:

• Router: receives requests, dispatches tasks, and coordinates.
• Worker: reads code, implements, and verifies.

The two layers separate task reception from task execution. New requests from GitHub or Feishu first pass an admission check, then reach the Router, which handles interaction, routing and coordination and dispatches the different tasks. Worker A fixes the interface issue with its own independent context. Worker B writes another set of tests with its own independent context. Both workers can feed results back directly.

The practical benefit is isolation. The worker fixing the interface keeps fixing the interface; the worker changing documentation has its own context. The Router does not need to crawl through every file itself to decide which task goes to whom.

4. The Feedback Path That Matters Most

The more valuable part of the design is the feedback path at the bottom of the diagram. After a task subscribes to related discussions, events such as pull-request comments and CI results enter the original task's context directly. The routine of copying an error message and telling the AI "keep fixing" can now be handled by the system.

Without this path, even ten agents running in parallel may only create ten windows that a human has to watch.

4.1 A Concrete Bug Example

Suppose a Go service's /users interface panics when given empty parameters. After deployment and authorization are configured, a request can be written in the issue:

1. @repository-bot
2. Fix the panic caused by empty parameters in the /users interface.
3. Add regression tests and keep existing interface compatibility.
4. Submit a pull request when done, and leave it for review.

This example states what to fix, how to accept it, and where to deliver it. It removes ambiguity from the request itself.

4.2 How a Single Bug Advances

Assuming deployment and authorization are complete, the process runs as a closed loop:

1. Request: fix the empty-parameter panic in /users and add regression tests while keeping interface compatibility.
2. Accept and execute: create a ticket, hand it to an execution session, and implement and verify in the task directory.
3. Submit PR: deliver a reviewable change. Creating a PR does not mean the task is complete.
4. Follow-up comments and CI feedback enter the original task, and the system keeps judging and handling through the established subscription.
5. Scope decision: if the modification stays in the original scope, such as adding an empty-string test, the original task continues to implement and verify. If it exceeds the original scope, such as refactoring the entire user module, the work is returned for re-evaluation and re-dispatch.

4.3 Authorization Does Not Auto-Expand

After a task is accepted, it owns its execution session and directory. The preparation command can be configured to create a working copy through git worktree, letting different tasks advance in their own directories.

When the PR is submitted, the work is not over. A failing test has to be fixed; a review that catches a missing edge case has to be addressed. These can return to the original task. But if someone suddenly says "by the way, refactor the whole user module too", the system needs to re-evaluate. Follow-up messages add context, but they do not automatically expand the original authorization scope.

Every developer understands that "by the way" is rarely trivial.

5. Requirements Can Change While Tests Are Still Running

When multiple tasks are separated, a single task can still be blocked by a long-running command. For example, an integration test has just started, and the developer remembers that an old client still needs compatibility. The message is sent, but the agent keeps waiting for the command to return and does not react for a long time. By the time the test ends, the earlier implementation may have to change again.

The official design discusses asynchronous tool calls to handle this. The mechanism starts background work, returns immediately, and delivers the completed result back as an event later. A new message is processed after the current reasoning step ends, without waiting for the background command. In the earlier example, the test keeps running in the background, and the agent can first accept the compatibility requirement, then decide whether to stop the test and adjust the implementation. The developer can correct the direction mid-execution.

A boundary must be stated: a new message cannot interrupt model reasoning at any arbitrary point. At the time of the official publication, the mechanism was implemented in Harness but was not enabled by default, which has to be treated separately from the public prototype's specific configuration.

6. Does It Look for Work by Itself?

The official team has described an internal practice: a pre-configured silent-fix strategy lets the agent try to reproduce and fix issues based on group-chat feedback, and only notifies a human when there is a deliverable worth reporting.

For example, someone reports in the group that an interface seems to time out occasionally after an upgrade. If the team has already authorized this kind of investigation, the agent can try it first. It may find a stable reproduction, or it may search around and find nothing.

This cost has to be accounted for. Background attempts consume compute. If the agent posts a message for every step and throws out a few guesses for humans to judge, people end up busier, not less busy. Proactive work therefore needs a gradual opening process. The public prototype offers three modes:

• off: does not accept inferred candidates, and will not create tickets from them.
• observe (default): evaluates but only records. It notes "would have accepted this ticket" without executing.
• auto: accepts the ticket after evaluation passes.

6.1 Rules Still Apply

In all three modes, an explicit request that meets authorization conditions can still execute. observe is not a read-only switch for the whole system. A common recommendation is to start with observe: see what "work it was about to pick up" gets recorded. If even casual chat is frequently judged as a development requirement, adjust the rules first. Once the judgment matches expectations, consider switching to auto. This detail is best understood before deployment.

7. Measured Effect: A Scheduling Experiment

The official design article, "Super-agent Design Exploration: Toward More Autonomous Agent Systems", reports a set of preliminary scheduling experiments. Two configurations are compared on the p95 of task completion time, measured from receiving a work request to emitting the result message. The p95 means roughly 95 percent of requests complete within this time.

• Super-agent: 15.7 minutes.
• Single session + subagent with neutral prompting: 29.5 minutes.

The experimental conditions matter. Each run used about 300 messages, of which about 20 were work requests. Each scheme ran five times, and only two configurations are shown here. The coding work was replaced by a time-consuming tool.

These numbers cannot be converted into a real programming speedup ratio. The experiment used a synthetic message stream, coding was emulated by a slow tool, and each scheme ran five times. It measures scheduling and collaboration ability, not real coding quality on an actual project. Once placed in a business project, the team still has to track fix correctness, review time and rework count. A PR that lands fast but is painful to review may not be worth it.

The source is the official design article's section 7.1, the author's preliminary experiment, not the present article's own measurement.

8. Deployment Boundaries and Engineering Reality

Deployment has its own limits. The executor runs commands under the operating-system user identity of the runner. The independent directory and command wrapper do not constitute a security sandbox. Any automatic-merge convention also needs repository branch protection to be enforced properly.

The gap between "can keep executing tasks" and "can be safely delivered" contains a significant amount of engineering work. Scheduling experiments are a useful signal, but they sit upstream of the production hardening that decides whether the system is trustworthy in a real codebase.

9. Summary: A Paradigm Shift or a Practical Tool?

dsh-superagent moves the manual work of task dispatch, feedback forwarding and progress tracking into a continuously running process. If this process works reliably, developers can spend more time on requirement judgment and result acceptance. A task can still be adjusted mid-execution.

Whether this counts as a new AI development paradigm depends on one thing: how much follow-up cost it saves in a real team. Handling the messy parts of multi-session collaboration well is already practical value. Later, measuring code quality, review time and runtime cost together gives a more meaningful picture than counting how many pull requests it submits in a day.

The honest verdict is that the scheduling gains are real but narrow. The p95 improvement comes from removing handoff friction and parallelizing context-isolated work, not from making the underlying model better at coding. The value of a system like this is measured in reduced coordination overhead, and that only holds when the execution environment, authorization model and feedback subscription are configured correctly. For teams that live with constant context switching across sessions, this is the kind of tool that pays for itself; for teams without that friction, it adds deployment surface for little return.

10. Conclusion

dsh-superagent is a coding agent on DeepSeek Harness, targeting a single GitHub repository with optional Feishu integration. It splits work into a Router layer for reception and dispatch and a Worker layer for implementation and verification. Tasks get isolated sessions and directories, feedback flows back through subscriptions, and asynchronous tool calls let requirements change while tests still run.

The three proactive modes, off, observe and auto, gate how much inferred work the agent may pick up, while explicit authorized requests always execute. A scheduling experiment reports a p95 of 15.7 minutes for Super-agent versus 29.5 minutes for a single session plus subagent, but the conditions are synthetic and the experiment does not verify coding quality. The executor is not a sandbox, and deployment hardening remains the developer's responsibility.

The practical takeaway is to judge this system on follow-up cost saved, code quality, review time and runtime cost, not on pull-request counts. When multiple model backends and long-running agent sessions coexist, teams also need a consistent layer for routing, authentication and usage accounting across those endpoints, which is what an API gateway such as 4sapi provides: one stable contract in front of the model providers so the application does not re-implement dispatch and metering for each one.

References

• dsh-superagent-prototype: https://github.com/deepseek-ai/dsh-superagent-prototype