On October 31, DeepSeek's Harness team announced an open-source coding agent on WeChat, and by November 1 Bloomberg was framing it as a challenge to Claude Code. The repo is deepseek-ai/dsh-superagent-prototype, MIT licensed, v0.1.0, a single commit. The README's own first lines matter more than the headlines: "Research prototype for reference only, not an official DeepSeek product." Treat it as a published design study, because that is what it is. I read the repo and the coverage, and the interesting parts are not the speed claims. They are the control flow.
What actually shipped
dsh-superagent is a proactive coding agent scoped to one GitHub repository. It is packaged as a bundle for DeepSeek Harness, the team's open-source agent harness (we covered its Claude Code Mods compatibility layer last month). It listens to GitHub events and, optionally, Feishu chat. When someone allowed to ask requests work, the agent opens a work item, does the work in its own agent session and working directory, and answers in the original conversation, often as a pull request. A local web panel lists only the items that need a human.
The stated principle in the README: "take as little human attention as possible, and give as much value as possible." An agent that can act for a whole team can also waste a whole team's attention, so it acts only when asked, or when a rule the team wrote allows it, and speaks only when someone must act or can use a result. That is an attention budget enforced in code, which is rarer than it sounds.
The unit of work is a Ticket with a Mandate
The domain model is the part I would copy first. Every request becomes a Ticket, and every Ticket carries an immutable Mandate stating why the work may proceed. Authorization is recorded per unit of work, not granted globally to the agent. The flow, as MarkTechPost's breakdown documents it:
Source GitHub or Feishu produces events
Trigger a single event arrives
Eval does this batch of triggers ask for new work?
Ticket unit of authorized work, with an immutable Mandate
Subscription later PR comments reach the right worker, no new mention
The Subscription piece solves a real annoyance: follow-up comments on a pull request are routed to the worker that already holds the context, instead of spawning a fresh session per mention.
One router, many workers
The architecture has two layers. A long-running Router handles interaction and dispatch, running the dsh-superagent-router preset with a deliberately smaller tool set. Isolated Worker sessions do the actual work, each running dsh-superagent-worker. One session and one directory per Ticket, so concurrent tasks cannot trample each other's state.
One execution detail worth knowing: shell commands move to the background after 5 seconds, so a worker keeps receiving messages while a slow command runs. That is the kind of small decision that decides whether a long-running agent feels alive or wedged.
Autonomy is a gate, and observe is the default
This is the design choice I keep coming back to. Proactive behavior is not a switch you get for free. The authorization model defines three accept modes: off, observe (the default), and auto. In observe, the agent only records what it would have accepted. Nothing runs until a human reviews the log and moves to auto, presumably per rule, not as a global leap of faith.
Most "autonomous agent" releases ship with the scary part enabled and a warning label. This one ships with the boring part enabled and a paper trail. Anyone who has spent time writing deny rules in agent configs knows which default ages better. If the topic of rules-gated agent behavior is new to you, the same week's coverage of Microsoft's Agensh experiment is a good contrast: 1,024 agents with no manager, and one agent on a newer model beat the whole fleet. More agents without a dispatch discipline is not automatically more throughput.
The 1.9x number, and what it does not prove
The benchmark floating through coverage comes from DeepSeek's simulation: about 300 messages per run, of which about 20 were real work requests, five runs per scheme. The super-agent finished with a p50 of 12.4 minutes and a p95 of 15.7 minutes. A single-session agent with subagents, run under a neutral prompt, hit a p95 of 29.5 minutes. That is roughly 1.9x at the tail, and the reported reason is instructive: under the neutral prompt, the baseline invoked a subagent zero times in five runs. The router also degraded gracefully under load, with batching growing from 1.0 to 2.8 as arrivals rose from about 1 to 40 per minute, and per-request latency from 2.5 to 3.9 seconds.
Now the caveats, which the coverage buries. The test traffic was synthetic. The tools were simulated. Real coding quality was not measured. The README also says the published code was adapted for release and is not identical to the internal version, and that some designs in the accompanying post, "Exploring Super-agent Design: Towards a More Autonomous Agent System", are future directions, not implemented features. So read the 1.9x as a property of the dispatch design under noisy input, not as a productivity claim about your repository.
Running it at all takes five dependencies
If you still want to try it: Node.js 22.19+ or 24+, git 2.32+, Python 3.8+, tmux, and GitHub CLI 2.48+, on your own machine as a dedicated Harness profile. The setup is explicitly agent-assisted. You ask your coding agent, in so many words:
Read SETUP.md in this repository and set up dsh-superagent with me.
It then asks one short question at a time, shows the full plan once, and installs. Setup docs written for an agent reader rather than a human one is a small signal of where this team thinks tooling is going.
What to steal even if you never run it
I will not be deploying this prototype; it says not to, in writing, at the top of its own README. But the checklist generalizes to any chat-triggered agent you build or configure, and it matches what newruntime's review took from it too. A defensible autonomous workflow needs four things: a durable work item, an authorization boundary, task isolation, and a narrow escalation path. Ticket, Mandate, one session per task, a panel that only lists what needs you. If your current setup is a bot in a channel with a broad tool set and no ledger of why it was allowed to act, this repo is a free reference implementation of everything you are missing.
Top comments (0)