The DeepSeek Harness team released dsh-superagent, an MIT-licensed research prototype designed to manage coding tasks across a single GitHub repository. This tool operates as a bundle for DeepSeek Harness, monitoring GitHub and, optionally, Feishu to convert permitted requests into parallel work items within separate agent sessions. The launch accompanied a design post titled Exploring Super-agent Design: Towards a More Autonomous Agent System.
Key specifications
- What it is: A TypeScript bundle at version 0.1.0, released as a single commit under the MIT licence. It employs the model configured in the Harness profile.
- Requirements: It runs on a local machine as a dedicated DeepSeek Harness profile. Installation requires Node.js 22.19 or 24+, git 2.32+, Python 3.8+, tmux and GitHub CLI 2.48+.
- Performance: DeepSeek simulation data indicates it completed tasks significantly faster under a noisy message stream compared to a single-session agent.
- Speed: The 95th percentile task completion time was 15.7 minutes, compared to 29.5 minutes for the single-session baseline (roughly 1.9x faster).
- Limitations: Testing relied on synthetic messages and simulated tools. The actual quality of the generated code was not measured.
How the agent works
The system waits for a prompt. When an authorised person addresses it, the agent creates a work item, called a Ticket. Each Ticket executes in its own session and directory. Results return to the original conversation, often as a pull request. A local web panel displays only items requiring human attention.
The README states the core rule plainly: take as little human attention as possible, and give as much value as possible. The philosophy document applies this to behaviour. The agent confirms once, stays quiet while working, and writes again only with a result, a question or a failure.
The reasoning behind the architecture
DeepSeek argues that mainstream agents treat a single session as the basic unit. As reported by ifeng, a person can actively follow only three to five sessions at once. Human attention, not model capability, becomes the bottleneck for multitasking.
Router-Worker architecture
The research team describes two layers. A long-running Router handles interaction and dispatch. Isolated Worker sessions perform the actual work.
In the prototype, that flow is concrete, per the domain model:
- Source to Trigger: GitHub or Feishu produces events.
- Eval: Decides whether a batch of Triggers asks for new work.
- Ticket: A unit of authorised work, with an immutable Mandate stating why it may proceed.
- Subscription: Later comments on a pull request reach the correct Worker without a fresh mention.
The main session runs the dsh-superagent-router preset with a smaller tool set. Each Worker runs dsh-superagent-worker. Shell commands move to the background after five seconds, so Workers keep receiving messages, per the execution doc.
Proactive work is gated. The authorization doc defines three accept modes: off, observe and auto. In observe, the agent only records what it would have accepted.
The research team also lists ideas beyond the prototype: an external Watchdog, storage and compute separation, and an asynchronous ReAct loop.
Performance metrics
DeepSeek tested the system with simulated group chat and GitHub CI streams. Each run contained about 300 messages, of which about 20 were real work requests. Each scheme ran five times, per ifeng’s account of the report.
- Super-agent: p50 of 12.4 minutes, p95 of 15.7 minutes.
- Single session plus subagents, neutral prompt: p95 of 29.5 minutes. No p50 was given.
- Reason: Under the neutral prompt, the baseline called a subagent zero times in five runs.
- Router load: As arrivals rose from about one to 40 per minute, batch size grew from 1.0 to 2.8. Per-request latency rose from 2.5 to 3.9 seconds.
An ablation removed direct event pass-through. Router decisions rose about 30%, and cache-read tokens rose about 37%, from 23.23M to 31.77M. All figures are self-reported and come from secondary reports of the report.
Comparison with other GitHub coding agents
| Feature | DeepSeek dsh-superagent | GitHub Copilot cloud agent | Claude Code Action | OpenAI Codex |
|---|---|---|---|---|
| Trigger | Mention by allowed person; written rules | Issue assignment, chat, API, Slack and more | @claude mention, issue assignment, workflow prompt | @Codex in Slack; cloud tasks |
| Unasked (proactive) work | Yes, rule-gated; observe by default | Yes, via automations | Yes, via workflow events | Not disclosed |
| Parallel isolated sessions | Yes, 1 per Ticket | Not disclosed | Not disclosed | Not disclosed |
| Where it runs | Your machine (Harness profile) | GitHub, in the background | Your GitHub Actions runner | Codex cloud |
| Chat source | Feishu (optional) | Slack, Teams | Not disclosed | Slack |
| License | MIT | Not disclosed | MIT | CLI agent open source |
| Availability | Research prototype | All paid Copilot plans | Your API key or cloud provider | ChatGPT Plus and above |
Summary
Developers using this tool should note it runs with full OS-user access, so isolation is required before use. Proactive work remains in observe mode until a team switches it on. The system relies on simulated data for performance claims, meaning real-world coding quality remains unverified.
