dsh-superagent: The Super-Agent Written by Agents

Background and Phenomenon: 13,000 Stars in 3 Days and a Self-Revealing Disclaimer

On October 31, 2026, GitHub repository deepseek-ai launched the dsh-superagent-prototype. Three days later, on the morning of November 3, the status was: 13,000 stars, 1,348 forks, 79 subscribers, and 0 open issues. The author field was listed as DeepSeek Harness Team, under MIT license, version 0.1.0.

Beyond the number of stars, the first paragraph of the README contains more information. Three key sentences deserve direct citation: “Research prototype for reference only, not an official DeepSeek product.” It’s a research prototype for reference only, not an official DeepSeek product; “much of the engineering done by coding agents” – a large portion of the engineering was completed by coding agents; “adapted for publication, so it is not identical to our internal version” – modified for release, not identical to the internal version. A repository that gained 13,000 stars in three days first denies its official status, creating a contrast that is the first breakdown point of this issue: it’s an open-source research prototype by DSH team, limited to “team research prototype” and cannot go any further.

There is a clear difference in dissemination. This repository was submitted to Hacker News multiple times, with the best score being 11 points and 0 comments, with little discussion; while on GitHub, the number of stars soared, with most popularity on the trending side. The background is the DSH platform itself: on August 13, the developer preview got 747 points and 314 comments on HN; on October 2, the Harness Desktop (macOS/Windows client) got 417 points and 228 comments. The platform has real community popularity, and dsh-superagent is the first major bundle in its ecosystem, with the number of stars reflecting the attention drawn by the platform’s branding.

In one sentence, it’s a permanent coding agent packaged for DSH, serving only one GitHub repository, monitoring GitHub, with optional monitoring on Lark; authorized individuals assign tasks to it, which creates work items and works within its own conversations and directories before returning to the original dialogue, such as submitting a pull request; the Web panel only shows “tasks needing processing.” There’s also an article titled “Exploring Super-agent Design: Towards a More Autonomous Agent System,” with the README specifically noting that some designs discussed in the article are future directions, and the prototype has not been implemented.

Architecture and Technical Principles: One Authority Rule and Five Disciplines

Let’s start with the form. It is not an independent application but a bundle under the Cordis plugin architecture (cordis.patch.yml), running within DSH. The repository comes with nine numbered documents, numbered 000 to 008: Philosophy, Domain Model, Authorization, Execution, Prompt, Panel, Deployment, Architecture, and Cookbook. The last document teaches how to add a Source. Each document relies only on the preceding ones, following the design constraint of the README: readers will never encounter concepts that have not yet been introduced.

The domain model is a one-way flow. A Source (event source, GitHub or Lark) generates a Trigger (immutable event), which belongs to a Thread (chronologically ordered session). Eval performs two-layer evaluation on a batch of Triggers (gate plus evaluation) and produces a Decision; if rejected, a Ticket is created with a Mandate attached. Assignment binds the Ticket to an Executor (execution session), and the result is written back to the original conversation through the Channel. Subsequent messages in the same Thread are spread out through Subscriptions, delivered directly to the subscribed Tickets as context, without re-evaluation.

The core of the entire system lies in authorization. The opening sentence in docs/002 reads: “The host enforces allowed lists, rules, and Mandates. Messages, comments, and quoted documents are inputs to a decision; they cannot change those permissions.” The host program strictly enforces the whitelist, rules, and Mandate; messages, comments, and cited documents are merely inputs for decision-making and cannot alter permissions. In other words, prompt injection protection is not written in the prompts themselves but in the architecture layer: regardless of what the message content says, permission determination does not go through the message content.

There are two paths for Triggers. The first is Eval, which decides whether to proceed: The Source records whether the message is addressed directly (@mention or private message), and gate checks the sender’s policy with that Source. Those on the whitelist who are directly addressed constitute an explicit request; bots can only generate “inference candidates,” never constituting an explicit request, and bots not on the list will not accept them. Inference candidates also need to pass the accept mode: off, observe, auto—defaulting to observe, recording only judgments of “would accept,” without actually proceeding. The second path is Subscriptions, continuing existing work: Each message (including bots and CIs) subscribed to a Thread is delivered to the subscribed Ticket, bypassing gate but not granting any new permissions. The Ticket is always limited by its own Mandate; even if a subscription is canceled, the ownership of the Executor continues until the Ticket ends.

A Mandate is an authorization credential frozen at the moment of acceptance, immutable, recording the Policy version, scope, intensity, and rules of hits. Only three operations in the entire system can change it: accept creates it, someone’s stop revokes it, and a failed revalidation invalidates it. To restore a closed Ticket, one must first revalidate according to the current Policy: remove the sender from the allowlist to invalidate the Mandate granted by him. These rules are located in line 242 of src/policy.ts, with the gate and revalidate functions corresponding to each other in the documentation.

The philosophical document sets five disciplines for agents: act only when required or allowed by team written rules, work that no one requests must be run in a record-only mode first; speak only when someone needs to act or can use the results, remain quiet during work; ask only one specific question at a time, ask in a structured manner, let questions find people rather than be buried in long reports; stop based on impact, not workload, and make local changes reviewable; report honestly, mark drafts as unfinished, report failures as failures, “Limit never to avoid asking questions.”

The directory structure and documentation echo each other. src/core contains the domain model and ticket engine (15 files including engine, tickets, intake, stage, replies, memory, etc.); src/sources contains github-* and feishu-* files in pairs, with two Source implementations being completely symmetrical; src/executor implements execution into DSH sessions; policy.ts, limits.ts, and admission.ts are independent files, with authorization and throttling not mixed with business code. Thirteen prompt strings are placed in the prompts/ directory and stored in the repository, with admission, dispatch, orchestrator, worker, and handoff each having their own roles, and prompts are managed as first-class citizens.

Key Data: 12,390 lines of code, one commit

Several hard numbers for repository statistics: src/ contains 12,390 lines of TypeScript and 147 .ts files; tests/ has 65 files; the entire repository has 216 files (excluding node_modules and .git), totaling 3.8MB. The language is TypeScript, and private: true is set in package.json, so no npm packages are released, using bundle instead.

History consists of only one commit: a single squash commit (6337fc8, 2026-10-31, “feat: add the dsh-superagent research prototype”), with no new commits after release, and the contributors API returns an empty array. Beyond the nine numbered documents, prompts/ contains 13 prompt strings, and skills/ contains 2 (one from GitHub and one from Feishu).

The default parameters in policy.ts deserve a separate listing: the maximum number of concurrent workers is 3 by default; the Eval timeout is 120 seconds by default; the accept mode is observe by default. There are only two default rules: copy (text correction) and visual (visual correction). The instruction for the visual rule reads “Do not invent visual style,” meaning to only observe without confirmation or action unless directed. The default values are very strict, consistent with the operating advice of “narrow first, then expand.”

Details on the execution side: Each ticket is assigned a session named worker-<ticket id> and a dedicated directory. Front-end commands that take more than 5 seconds will automatically convert to background tasks, allowing workers to receive new messages immediately instead of waiting for the command to complete.

SETUP.md itself serves as a breakdown document. It is not meant for people but for agents: the official installation advice is “let your coding agent read SETUP.md and help you install.” The document sets rules for agents: ask only one short question at a time, each message should be within 300 words, the complete plan should be displayed only once, and action is allowed only after all questions are answered. Never request secrets in chat; steps that require manual effort (creating accounts, logging into CLI, filling out app secrets) should be packaged as separate messages. The list of prerequisites is also long: Node.js 22.19+, pnpm, git 2.32+, tmux, Python 3.8+, GitHub CLI 2.48+, plus the DSH ontology and a model provider.

Impact and Significance: Attention is currency, authority is a iron law

First, the attention economy is treated as a design axiom. The bolded sentence in README: “Take as little human attention as possible, and give as much value as possible,” meaning to occupy as little human attention as possible and provide as much value as possible. This philosophy document expands into acceptance criteria: each message, notification, question, setting, panel element, or document occupies someone’s attention. If the value provided exceeds the cost, it should be deleted. The motivation is also straightforward: “An agent that can act for the entire team can also waste the team’s attention.” Most agent products emphasize capabilities, but this project reverses this logic, making “how much attention it takes” the primary constraint: the panel only displays tasks that require human handling, and health status does not take up any space; there should be fewer concepts and settings. If a default value can be used, it should not be configured; team behavior described in text should be written as prompts rather than switches.

Secondly, an architectural-level answer was provided for prompt injection. A common practice in the industry is to instruct the model not to execute the commands in the prompt, essentially aiming for model autonomy. dsh-superagent hands the task to the host program: permissions exist only in the whitelist, rules, and Mandate, while prompts, comments, and cited documents are merely inputs for decision-making. No matter how text appears to be a command, it cannot obtain permissions beyond the gate. This defense line does not depend on model capabilities; it remains valid even when models are replaced. In the “Rejected Concepts” table of docs/001, there is a choice regarding its origin: Executor is not allowed to claim that “someone asked me to stop”; the authority to stop lies with Eval. Any proxy system that needs to receive external messages can directly adopt this design.

Thirdly, operator responsibility is written into technical documentation. A dedicated section in the philosophical document is Responsibility: proxies comment on accounts seen by the team daily, open PRs, and send messages, each of which distracts colleagues’ attention, and the operator must be responsible for this. Four operating rules: start narrow, begin the whitelist with short prompts, only record active work, and expand when it’s appropriate; if it causes noise, modify the prompt to be shorter and stricter, or even pause it, “do not use more messages to explain noise”; do not use it for spam, as mass PRs, broadcast messages, and busywork consume more than they add value to the team; be responsible for what you say, read content sent in your name, and modify the prompt if there’s a mistake. The governance terms and technical design are placed in the same document, which is rarer than the code itself.

Fourthly, it provides an example of an engineering organization structure where “proxies write and read”. The README acknowledges that much of the work was done by the coding agent, and the organization of these 12,390 lines of code provides a repeatable answer: numbered documents depend on each other, ensuring that readers (including proxy readers) do not lack prerequisite concepts; prompts are stored and organized by role; two Source implementations are strictly symmetrical, with a new Source having cookbook tutorials; 65 test files provide support; even the domain model document includes a “Rejected Concepts” table, listing ten clear designs and reasons for not adopting them. Here is a complete reference answer on how to create a repository for proxies.

Controversies and Risks: A research prototype is still a research prototype

Firstly, identity and maturity. The README acknowledges that the code may still contain bugs, and the coding style and engineering practices may not be consistent, “consider it research code, not production-ready software”. The release version is different from the internal version, and some designs in the accompanying articles are future-oriented, not yet implemented as prototypes. Teams wishing to use it directly should read these lines three times.

Secondly, there is no evolutionary history. The entire repository has only one squash commit, with a one-time release, making it impossible to assess the choices made during code growth; the contributors API returns an empty array, leaving no knowledge of contributor distribution. For a repository that claims “proxy participation in engineering”, the lack of history is particularly regrettable: it’s impossible to observe the real way proxies produce code from the commit records, only the final result. Additionally, 0 open issues does not mean there are no problems; it’s more likely that the community hasn’t had time to use it seriously (this is my judgment).

Third, the spread of temperature difference itself is a signal. HN has the best score of 11 points with 0 comments, and GitHub has 13,000 stars in three days. The lack of activity on HN indicates that its share of discussions in the English tech community is limited; the surge in GitHub’s stars comes more from DeepSeek’s brand effect and the narrative of “super-agent”. Stars are an indicator of attention, not quality, and they should not be confused (this is my judgment).

Fourth, limit the deployment threshold to sample locations. Prerequisites include a long list of requirements: you must have the DSH platform, a dedicated GitHub account, and optionally a Lark bot; the official documentation directly suggests using a coding agent for installation. For teams not part of the DSH ecosystem, its practical value is limited; what can be truly transferred are documents and designs. Also, note the implicit cost of the authorization model: the tighter the gate, mandate, and recheck mechanisms, the broader the configuration options. When the Policy version changes, all ongoing Evals are invalidated and rearranged, and there are many rules to remember for operation and maintenance.

Conclusion and Outlook: Documents Are More Worth Reading Than Code

The title of the accompanying article is a declaration: “Exploring Super-agent Design: Towards a More Autonomous Agent System,” moving towards a more autonomous agent system. The article and prototype complement each other: the article discusses design, some of which is future direction; the prototype only shows implemented parts and explicitly states they are different. Two things deserve attention later: whether a second or third major bundle will emerge in the DSH ecosystem; and whether DeepSeek’s team will implement the future directions from the article in subsequent versions.

For readers, the value hierarchy of this repository is clear. At the bottom is the authorization model that can be directly transferred: the host holds authority, messages are just input, mandates are immutable, and rechecking occurs before recovery. In the middle layer are the design axioms of the attention economy and operator responsibility clauses. At the top are the 12,390 lines of TypeScript implementation, which according to the README is only a potentially bug-filled reference sample. My conclusion in one sentence: dsh-superagent is worth reading; documents are more worth careful study than code; it proves that the difficulty of agent systems lies not in capability but in authorization and attention, both of which have engineering solutions.

Reference Sources

• Repository and README: https://github.com/deepseek-ai/dsh-superagent-prototype (13,000★ / 1,348 forks / 0 open issues / 79 subscribers, November 03, 2026)
• Local clone read-only check (November 03, 2026): README.md, SETUP.md, docs/000-philosophy.md, docs/001-domain.md, docs/002-authorization.md, docs/003-execution.md, src/policy.ts, package.json, prompts/, skills/
• Related article: “Exploring Super-agent Design: Towards a More Autonomous Agent System” (citing README; prototype statements and article do not fully match)
• DSH platform HN discussions: developer preview 747▲/314c (August 13, 2026); Harness Desktop 417▲/228c (October 02, 2026)
• This repository HN submission: highest score 11▲/0 reviews (October 31, 2026)

Author: Yongliang