DeepSeek releases dsh-superagent for GitHub repository tasks

• DeepSeek released a single-repository coding-agent prototype that takes GitHub tasks and delegates execution to parallel workers, as the release overview describes.
• Scheduling improved in an internal simulation: p95 completion time fell from 29.5 to 15.7 minutes, 46.8% lower, in the reported comparison.
• Proactive work defaults to observation: the architecture sketch lists observe, which records potential work without accepting it automatically.
• The public prototype implements only part of the broader design, according to a DeepSeek reviewer’s explanation.

Shell commands move into the background after five seconds. Follow-up comments carry context without granting new authority. And the benchmark’s neutral-prompt baseline had a subagent tool available but never used it across five runs.

DeepSeek published the MIT-licensed dsh-superagent-prototype on October 31. It runs as a DeepSeek Harness bundle, watches one GitHub repository, optionally receives Feishu messages, and returns results to the originating conversation.

The broader design divides responsibility between two layers:

• Router: maintains cross-task context, handles human interaction, and dispatches work. The team says a lighter model can often handle this role; it need not have a Bash tool.
• Workers: execute individual tasks with isolated contexts and full work tools. A Worker can itself launch subagents or an agent team, without exposing that internal organization to the Router.

Workers report conclusions to the Router rather than independently flooding external conversations with tool activity.

The design article organizes incoming events into four mechanisms:

1. Filtering: deterministic checks handle sources, channels, and allowlists before a model evaluates semantic policies.
2. Subscription and pass-through: the Router dispatches a new task once. Subsequent events on its subscribed threads go directly to the owning Workers. Subscriptions are many-to-many.
3. Inline, Spill, and Chain of Recall: likely-needed context goes into the prompt; excess content stays outside with references. Linked IDs and summaries let the model retrieve related events, threads, and sessions one hop at a time.
4. Speculative execution: permitted rules can initiate background work before an explicit request. The team describes an internal rule that silently reproduces reported bugs and posts only after confirming an issue and finding a simple fix.

A Worker can hand an out-of-scope follow-up back for routing instead of treating every comment as another instruction for its current task.

Long-running tools return control before their work finishes. In the proposed asynchronous loop, start() returns immediately, completion arrives as an event, and stop() can cancel the operation.

The released execution implementation adds specific scheduling behavior:

• Foreground worker shell commands become background jobs after five seconds, allowing new messages into the next step.
• Background jobs keep the worker slot occupied after a turn ends. Completion wakes the same Executor.
• After 30 minutes following a turn, remaining shell jobs are killed; subagents may continue.
• A question or handoff for review frees the slot immediately. Review servers can remain running without occupying it.
• A human message or status request can use one extra slot beyond normal concurrency, so queued launches cannot prevent someone from continuing existing work.

Every accepted Ticket carries a Mandate recording why the work was authorized. The authorization rules distinguish permission to start work from messages supplied as context.

The authorization ledger is the best bit of the release.

Three modes govern inferred work:

• off: inferred events do not become candidates.
• observe, the default: the agent assesses candidates and records positive decisions as “would accept,” without accepting them.
• auto: a positive assessment accepts work when at least one enabled rule matches.

Explicit authorized requests work in every mode. Observation mode therefore still permits requested work.

Messages on subscribed threads reach Workers even when they come from bots or CI, but that delivery grants no additional authority. Changing a policy notifies affected live Tickets; it does not immediately revoke their Mandates, which are revalidated before resumption.

The execution documentation draws a sharp boundary around the word “isolated”: Workers have separate sessions and directories, but execute commands without approval as the operator’s OS user.

Command wrappers and blocked command names establish defaults. A Worker can still invoke a program through an absolute path.

Merge behavior also has two different enforcement layers:

• Agent instructions: default auto-merge instructions require the Ticket’s own PR, approvals covering the current head commit, and fewer than 200 added-plus-deleted lines. A separate account’s CLI must be configured for merging.
• GitHub enforcement: the host has no merge-specific decision logic. Required reviews and dismissal of stale approvals depend on branch protection.

DeepSeek’s evaluation used approximately 300 messages per run, including about 20 work requests, across five runs per configuration. Coding tools simulated work by consuming time, so the experiment measured scheduling rather than code quality or human attention saved.

Against the neutral-prompt single-session baseline, the team’s reported results were:

• Median task completion: 20.4 → 12.4 minutes, -8.0 minutes.
• p95 task completion: 29.5 → 15.7 minutes, -13.8 minutes.
• Cache-read tokens per run: 6.1M → 23.2M, +17.1M, approximately 3.8x. These figures aggregate cache reads across sessions.

Two additional configurations expose what produced the difference:

• Delegation-first baseline: explicitly encouraging subagents brought median completion to 13.8 minutes, but p95 remained 29.0 minutes. It delegated in four of five runs; the neutral baseline delegated in none. In the remaining delegation-first run, the model judged the work small enough to execute itself.
• Super-agent without pass-through: cache reads rose from 23.2M to 31.8M, approximately +37%, while completion times remained similar. Routing follow-ups directly to Workers mainly reduced coordination overhead.

A separate Router stress test increased decision-requiring arrivals from roughly one to 40 per minute. Average batches grew from 1.0 to 2.8 events, while request time increased from 2.5 to 3.9 seconds; reported amortized time per decision fell from 6.4 to 1.6 seconds.

The broader architecture, circulated in an English translation, proposes separating three things currently tied together in many local agents:

• Compute: stateless agent-loop containers.
• State: persistent session records in a database.
• Environments: repositories, credentials, and toolchains on endpoint machines, reached through lightweight command-execution daemons.

An offline endpoint could reconnect later and execute queued work without hosting the agent’s session state.

Cui Tianyi, a DeepSeek Harness team member and final reviewer of the design article, said this separation still requires substantial engineering in Harness, according to ZhihuFrontier’s account of his explanation.

In the design article, a Watchdog runs as a separate agent session driven by scheduled messages. It checks infrastructure failures and whether Workers are making meaningful progress, including cases where a process remains alive but the model has drifted or entered an unproductive loop.

Maintainers can also ask it to investigate failures or change prompts and trigger rules during operation.

The public prototype’s runtime architecture documents a more concrete recovery foundation:

• Engine commands update domain records transactionally, with external effects performed after commit.
• The Outbox records a message receipt and queues its reply effect in one transaction.
• Startup resumes interrupted Assignments after restoring sessions and hooks.

Cui described validation in a small, trusted internal environment and attributed some of the system’s low complexity to deliberately simplified engineering and operating conditions. He also said Harness lacked built-in long-term memory spanning sessions at the time of his post.

The README says the published implementation was adapted for release and differs from both the internal version and the article. Coding agents performed much of its engineering; DeepSeek warns of bugs and inconsistent practices.

Earendil is converging on a long-lived agent with ad hoc, potentially recursive delegation and cross-system event triggers, as badlogicgames described. Cui likewise said several teams had explored similar architectures months earlier.

The setup guide specifies:

• Node.js 22.19+ or 24+, plus pnpm.
• Git 2.32+ and GitHub CLI 2.48+.
• Python 3.8+ and tmux.
• A compatible DeepSeek Harness version and configured model provider.

Setup is agent-assisted: an existing coding agent reads SETUP.md, asks one short question at a time, presents a plan, and installs and configures the bundle.

Early community activity included teortaxesTex’s setup thread. Separately, martinbowling floated pairing the repository with DeepSeek Flash V4.1 on four Sparks.

The web panel prioritizes Tickets requiring a person, then system health and execution history. Ticket details expose the originating event, authorization reason, scope, policy version, and outstanding inputs.

Prompt changes have their own version history. When an upgrade changes an overridden default, the panel compares the old and new defaults with the team’s text and offers “Keep my text” or “Use the new default.”