dsh-superagent: DeepSeek's Prototype for One Repository's Coding Agent
By Indie Kings | November 4, 2026
Updated November 4, 2026: DeepSeek has published dsh-superagent, a research prototype of a proactive coding agent for a single GitHub repository, written in TypeScript as a bundle for DeepSeek Harness, and it appeared on October 31, 2026. It already holds 17,099 stars and 1,843 forks. The repository is explicit that it is not an official DeepSeek product, that the published code is not identical to the internal version, and that it is research code rather than production software.
Image: GitHub social preview card for the dsh-superagent-prototype repository. Credit: deepseek-ai/GitHub.
Per the official repository README, dsh-superagent is a proactive coding agent for one GitHub repository, packaged as a bundle for DeepSeek Harness. It listens to GitHub and, optionally, Feishu. When someone allowed asks the agent for work, it opens a work item, works on it in its own agent session and directory, and answers in the original conversation, for example with a pull request. A web panel shows what needs a person. That is the whole surface: an agent that reads issues and comments and turns them into pull requests without anyone typing a prompt on its behalf.
The repository is a design document as much as it is code. Nine numbered documents lay out the design in order, each building only on the ones before it, and the README tells you to read them in that order. There are no releases at all. The newest thing in the repo is a TypeScript codebase with a large test suite, and the README's disclaimer asks readers to treat the whole thing as research code that may still contain bugs and whose coding style may be inconsistent.
The anti-noise principle
The philosophy document states the principle in one sentence: take as little human attention as possible, and give as much value as possible. Every part of the project is judged by the attention it costs. A message, a notification, a question, a setting, a panel element and a paragraph of documentation each cost someone's attention, and each has to give more value than that, or it is removed. That is a design constraint you can test features against, and the project does.
The consequences are written down plainly. The agent acts only when asked, or when a written rule the team wrote allows it. A request counts only when it addresses the agent directly and comes from a person the team allowed: someone on an allowed list, or anyone in a conversation the team opened to requests. Work nobody asked for needs a rule, and it starts in a mode that only records what the agent would have done. It speaks only when a person must act or can use a result. It confirms a request once and names what it will do, stays quiet while it works, and writes again only when a result is ready, when it needs a decision, or when it cannot finish. It asks one concrete question at a time in a structured form rather than burying it in a long report. And it reports honestly: a draft is marked unfinished, a failure is reported as a failure, and a limit is never bypassed to avoid asking.
The responsibility ladder is the part most agent projects skip. The agent comments, opens pull requests and messages people under accounts your team sees every day, and the operator is responsible for what it says. The guidance is to start narrow, with a short allowed list and proactive work only recorded. To tune for less noise by making prompts shorter and stricter, or by pausing it, rather than by adding more messages to explain the noise. Not to use it to produce volume, because mass pull requests and broadcast messages cost the team more than they give. And to own what it says, by reading what the agent posts in your name and correcting the prompts when it is wrong.
A domain model, not a plugin
The domain model document is the most interesting thing in the repository, because it does what almost no agent framework bothers to do: it names its concepts, gives each one a short list of rules it keeps, and records the concepts it rejected with reasons. Work moves from a Trigger to an Eval to execution. A Source produces Triggers. A Trigger fans out as context to the Tickets subscribed to its Threads. A person's message that reached a Ticket that way stays with that Ticket. Every other Trigger enters an Eval, which decides whether it asks for new work. When Eval accepts, it creates a Ticket with a Mandate. An Assignment hands the Ticket to an Executor. Results go back to the Source through a Channel.
The ten concepts are worth naming because they are the vocabulary the rest of the system uses and nothing else. A Source is a stream of events, a kind plus one configuration of it, which holds its read position and its own bot identity and drops the bot's own messages before they enter the domain. A Trigger is one immutable event. A Thread is Triggers in time order, with at most one Eval running on it at a time. An Eval is the judgement on a batch of Triggers in two layers, a deterministic gate and a model assessment. A Mandate is what an accept grants: the Policy version, the scope, the strength, the matched rules and the sender's identity, and it is immutable. A Ticket is a unit of authorized work. An Assignment binds a Ticket to one Executor instance. A Subscription is the many-to-many relation between Tickets and Threads that fans out later discussion to an Executor without anyone mentioning the agent again.
The rejected concepts table is where the design thinking shows. Principal and Membership were rejected as entities because a person is trigger metadata and an allowed list is a Source's part of the Policy. Eval scheduling its own delayed Triggers was rejected because a condition that needs waiting is an ordinary Source. Cancellation of running Tickets on a Policy change was rejected, because a cancelled change leaves half-finished work; the change is recorded and delivered instead. At most one live Ticket per Thread was rejected because one Thread can carry several independent pieces of work. Inferring "waiting on a person" from a report's free text was rejected because the classification needs structured facts. Each rejection is a decision that prevents a class of bugs rather than a matter of taste.
How a ticket flows through the system
Each open Ticket has one stage, determined by what it is waiting for, and the panel label is derived from that stage rather than from a free-text summary. The stages split into person stages, where the Ticket cannot continue without human input, and working stages. A person stage wins: delivering an input to the Executor Session failed is labelled Input undelivered, an outstanding question is Awaiting answer, a ready report is Awaiting review, and a blocked or failed report with no new human message is Blocked or Failed. An idle Ticket has finished its turn without an outstanding question. A new human message releases a blocked or failed Ticket to its Executor, which moves it back to working.
The Executor details are where the engineering discipline shows. Each Ticket gets an Executor Session named worker plus the ticket id and a directory named after the Ticket's short name, created under a configured execution root. Executor Sessions run commands without approval as the operator's OS user. The worker preset contains the tools needed for work and moves foreground shell commands to background jobs after five seconds, so a worker can receive new messages at the next step instead of waiting for a long command to finish. The main Session uses a different preset with the same five-second shell and job-wait limits and a smaller tool set for routing. Background work has at most thirty minutes to finish after a turn ends, at which point shell jobs are killed and the Ticket is reported waiting. Subagents are allowed to continue. A handoff to a person frees the slot immediately.
Concurrency is where agent systems usually fall over, and this one is careful. A Ticket holds a worker slot from the start of a launch, including preparation, and throughout an active turn. A configured concurrency limit applies to those slots, with one extra slot reserved for a person's message or a status request, which can take the next free slot before a new launch. New work therefore cannot prevent a person from continuing an existing Ticket. Other inputs, such as CI results, wait for a normal slot, and a launch waits in the queued stage until a slot is free, while launches run concurrently so a slow prepare command delays only its own Ticket.
Authorization and the trust boundary
Authorization is a separate concern from execution, and the split matters. Only Eval creates a Ticket. A Mandate is immutable and a wider scope means a new Ticket. A Ticket's end does not end its Mandate; only a person's stop withdraws it, and a Policy that no longer holds it revokes it. A Mandate is revalidated against the current Policy before an ended Ticket resumes. Identities on different Sources are never mapped to each other, which means the fact that one human has accounts on GitHub and Feishu is prompt text the agents read when they need it, not an identity join the system trusts.
| Element | What it is | The rule that matters most |
|---|---|---|
| Source | An event stream: GitHub notifications or Feishu messages | Restart must not replay events, so it holds its read position |
| Trigger | One immutable event with the Source's metadata | Accepting a Trigger twice creates one Ticket |
| Thread | Triggers in time order | At most one Eval runs on it at a time |
| Eval | Gate plus model assessment on a Trigger batch | Output is a Decision, and it holds no state |
| Mandate | What an accept grants, with scope and strength | Immutable, and revalidated before an ended Ticket resumes |
| Ticket | A unit of authorized work | Only Eval creates one, and it defines its own state |
| Assignment | One binding of a Ticket to one Executor | Only its final report may end the Ticket on the Executor's side |
| Subscription | The Ticket to Thread relation that fans out context | Route through Subscriptions, never through Correlation |
The trust boundary is stated with unusual candour. The wrappers and directories establish defaults, not a security boundary, and a worker can still execute a program by absolute path. That sentence is the most valuable line in the execution document, because it tells the operator exactly what the system does and does not guarantee. Executor Sessions run without approval as your OS user. There is no sandbox in this prototype. The authorization model controls who can start work and how far it may go; it does not contain what the worker can do once started.
What the prototype leaves out
Start with what this is not. The repository says plainly that it is a research prototype for reference only and is not an official DeepSeek product. The code grew out of the team's day-to-day development work, with much of the engineering done by coding agents. It has been adapted for publication, so it is not identical to the internal version or to the implementation described in the accompanying article Exploring Super-agent Design: Towards a More Autonomous Agent System. Some designs discussed in that article are directions for future development and are not implemented in this prototype.
There are no releases, no binaries and no images. The image slot in this article is a GitHub social preview card, which is itself the honest signal: the repository has no product artwork, no screenshots of a panel in use, and no demonstration material beyond its documentation and its test suite. The tests are extensive, with several of the largest files in the repository devoted to the core engine, runtime concurrency, sources and migration. But a large test suite behind a prototype is an argument for engineering seriousness, not for production readiness.
The setup story is designed for agents rather than for humans. Setup has many steps, so an agent does it with you: you ask your coding agent to read the setup document in the repository and set it up with you. It asks one short question at a time, shows the full plan once, and then installs and configures everything. That is consistent with the philosophy, but it means the intended operator is not a person reading a manual. It is another agent, supervised by a person who is expected to read what it posts.
What makes this worth covering, rather than filing under AI news, is that it is a readable reference design for a problem everyone is trying to solve badly. The domain model with its rejected concepts, the Mandate as an immutable grant, the person stages that win over working stages, the reserved slot so new work cannot starve a human reply, and the sentence that admits the wrappers are not a security boundary. Those are transferable ideas for anyone building an agent that acts on a shared queue of work. Review and adapt it before using it, as the README says, but steal the design.
FAQ
Is dsh-superagent an official DeepSeek product?
No. Per the repository README, it is a research prototype for reference only and not an official DeepSeek product. The published code has been adapted for publication and is not identical to the internal version.
What does dsh-superagent actually do?
Per the README, it is a proactive coding agent for one GitHub repository. It listens to GitHub and optionally Feishu, and when someone allowed asks it for work it opens a ticket, works in its own agent session and directory, and answers in the original conversation, for example with a pull request.
How does it avoid spamming a team with agent messages?
Per the philosophy document, the agent acts only when asked or when a written rule allows it, speaks only when a person must act or can use a result, and starts unasked-for work in a mode that only records what it would have done. The operator is told to start narrow and tune for less noise.
Is the agent sandboxed?
No. Per the execution document, Executor Sessions run commands without approval as the operator's OS user, and the wrappers and directories establish defaults rather than a security boundary. A worker can still execute a program by absolute path.
Is there a release I can install?
No. There are no releases. The repository is a TypeScript package with documentation, prompts and an extensive test suite, and development is driven by pnpm check, which runs the typecheck, tests and build.
What is the connection to the Super-agent article?
Per the README, the published code is adapted for publication and is not identical to the implementation described in the article Exploring Super-agent Design: Towards a More Autonomous Agent System. Some designs in that article are future development directions and are not implemented in this prototype.
Bottom Line
dsh-superagent is the most readable public design for a team agent we have covered: a ten-concept domain model with its rejected ideas documented, an immutable Mandate that states why the work may be done and how far it may go, a stage system where waiting on a person always wins, and an explicit admission that the tooling is not a security boundary. At 17,099 stars and 1,843 forks in four days, the industry is clearly interested in exactly that layer.
The limits are the ones the repository states itself. No releases, research code, an adapted rather than internal implementation, and no sandbox around a worker that runs commands as your OS user. Treat it as a design reference with runnable code attached, which is what its authors ask. Steal the authorization model and the stage discipline; do not deploy the agent into a repository you care about until you have built the containment it deliberately leaves out.
Related: How to Run DeepSeek R1 on Budget GPUs: RX 7600 XT, Arc B580, RTX 3060, Titan V, and RX 7900 XTX, DeepInfer: DeepSeek Open Sources Its Production Inference Engine Without the Serving Layer
Sources: per the official dsh-superagent-prototype repository README at github.com/deepseek-ai/dsh-superagent-prototype, and its numbered design documents 000 Philosophy, 001 Domain model and 003 Execution, all fetched in full on November 4, 2026; repository metadata (17,099 stars, 1,843 forks, no open issues, MIT, created October 31, 2026, language TypeScript) re-verified via the GitHub API on November 4, 2026; no releases exist.