DeepSeek Super Agent: How dsh-superagent Works
On October 31, 2026, DeepSeek published dsh-superagent-prototype on GitHub under the MIT license. By November 1 it had close to 7,000 stars. It is the open version of DeepSeek's Super-agent, a proactive coding agent that watches one GitHub repository and an optional Feishu chat, then takes work from the team. Below we separate what the prototype ships from what exists only in DeepSeek's design essay. Then we look at how it keeps track of team decisions.
What is DeepSeek Super-agent, in one sentence?
DeepSeek Super-agent (dsh-superagent) is a research prototype of a proactive coding agent that turns allowed requests on one GitHub repository into work items, each with its own session.
The README is blunt about its status. It calls the code a research prototype, "not an official DeepSeek product," and says much of the engineering was done by coding agents. It runs as a bundle for DeepSeek Harness, DeepSeek's open-source agent harness, which its own page lists as a public preview. Results go back to the conversation where the request started, often as a pull request. A web panel shows what needs a person.
How does the prototype differ from the Super-agent essay?
The README says the public code differs from DeepSeek's internal version and from the essay Exploring Super-agent Design: Towards a More Autonomous Agent System. Some designs in that essay "are not implemented in this prototype." We could not open the essay, which DeepSeek posted on WeChat. The left column relies on Yicai's report of it. The right column comes from the repository's numbered docs.
| The essay, as Yicai reports it | The open prototype's docs | |
|---|---|---|
| Structure | A two-layer design | A main Session that routes, plus one Executor Session per work item |
| Intake | Event-driven processing | GitHub polled once a minute by default, Feishu live events |
| State | Compute separated from storage | One SQLite file in a state directory, on one Harness profile |
| Supervision | An external Watchdog | A web panel and restart recovery. The docs mention no watchdog |
| Status | Internal instances run continuously on DeepSeek's own work | "Not production-ready," and proactive work is recorded only until a person enables it |
The right column draws on the execution and deployment docs. The state row comes from the architecture doc. Treat anything only in the left column as a direction, since the prototype does not show it.
How does dsh-superagent work?
The domain model has a small vocabulary. A Source, such as GitHub, produces Triggers. Triggers belong to Threads, like an Issue or a chat topic. An Eval decides whether a batch of Triggers asks for new work. It has two layers: a deterministic gate that checks who sent the message, then a model's assessment. When Eval accepts, it creates a Ticket with a Mandate that records why the work is allowed and how far it may go.
Each Ticket gets an Executor Session named after it and its own directory. A prepare command, typically a git worktree, sets up the checkout. The main Session only routes and makes no technical decisions. The Executor reads the sources and does the work, including verification.
Follow-ups need no new mention. Comments on a Ticket's pull request reach that Ticket through a Subscription, so nobody has to tag the bot again. An ended Ticket keeps its Subscriptions, even on a merged pull request. A person's later message there resumes it under the same Mandate, with no new Eval.
Setup is handed to an agent too. The README tells you to ask your coding agent to read the setup guide and set it up with you. You need a dedicated Harness profile, a GitHub user account for the agent (a GitHub App cannot be the agent) and a repository on github.com. GitHub Enterprise Server is not supported, per the deployment guide.
When does a proactive coding agent act on its own?
Rarely, by design. The philosophy doc states the rule: "Take as little human attention as possible, and give as much value as possible." The agent acts when an allowed person addresses it, or when a rule the team wrote allows it.
Authorization has three accept modes for work nobody asked for. In off, nothing inferred becomes a candidate. The default is observe, which assesses candidates and records "would accept" without acting. Only auto accepts them. Explicit requests from allowed people work in every mode. The docs advise starting in observe and switching after you review the recorded decisions.
The messaging limits are just as strict. Per the prompts doc, chat messages are one sentence by default, with a hard limit of 100 words. We like this part most, because the design treats each message as a cost to the reader. Every GitHub message also starts by default with a line saying an automated agent wrote it.
How does dsh-superagent keep team context?
There is no memory feature in the docs we read, numbered 000 through 008. The Harness page does not describe one either. Context lives in four places, and people maintain most of them:
- Repository instructions. Executors read Harness's coding prompt and the repository's AGENTS.md. The main Session does not.
- Team prompt sections and skills. A team edits three sections (Communication, Ticket scope, Delivery requirements) and can add skills, such as one that maps Feishu users to GitHub accounts. Every save is a version, and Sessions read the latest one on each model request.
- The Ticket itself. Each Ticket keeps its Executor Session history and its directory. Its subscribed Threads keep arriving as context. This survives restarts, and a recovery note tells the Executor to check its directory, git history and GitHub before repeating outside actions.
- Notes between Tickets. The main Session can pass a fact from another Ticket in a note of at most 100 words, as context only.
The isolation is strict. The architecture doc says an Executor Session reads only records tied to its own Ticket. It cannot read other Tickets or their Decisions. One rule shows the workaround. A built-in prompt caps automated review rounds at three per pull request. Each worker records the count in its report, and the next worker continues it.
A lesson from one Ticket reaches the next only if a person writes it into AGENTS.md or a team section. The docs describe no step that does this.
What should you read in the fine print?
Every fact here comes from DeepSeek's own repository and Harness page, plus two press reports. We found no independent test of the prototype on a real team's repository. Digital Trends framed it as a rival to Claude Code and Codex, and added that "this is a prototype." The repository says the same thing more strongly.
Security needs attention before anything else. The deployment guide says both presets run with danger-full-access as the operator's OS user. A worker can read the operator's home directory. DeepSeek recommends a dedicated OS account holding only the agent's credentials.
Storage grows without limit for now. The architecture doc says nothing deletes old records yet. Triggers and ended Tickets pile up in the database, as does every saved prompt version.
The bottom line
If your team works in GitHub and wants an agent that answers in the pull request, dsh-superagent is the most carefully specified design we have read. Try it in observe mode on a test repository, under a dedicated OS account. Do not put it on a production repository yet. Put every convention you want it to follow in AGENTS.md or a team section, because that is where its Executors look.
How does a team agent remember past decisions?
Say a reviewer tells the agent on Monday, in a pull request thread, that your repository formats dates with one helper and never a new library. The Executor fixes it, and the Ticket ends. On Wednesday someone opens an Issue that also touches dates. Eval creates a new Ticket, and a new Executor Session starts. It cannot read Monday's Ticket. Unless someone wrote the rule into AGENTS.md, it may pick the library again.
| dsh-superagent prototype | memU | |
|---|---|---|
| Where a lesson goes | Stays in its Ticket's session and threads. People copy it into AGENTS.md or a team section | The agent distills session history into readable Markdown memory |
| Who can read it | One Executor reads one Ticket. The main Session can relay a note of at most 100 words | One memory shared by every supported host, so what one session learned, another retrieves |
| Skills | A team adds skills by hand, such as an identity map | Distills reusable skills from agent history, as Markdown |
| Hosts | Runs on DeepSeek Harness | Codex, Claude Code, Cursor, OpenClaw, Hermes Agent and more |
dsh-superagent is a team agent with a written rulebook. memU is personal memory across your own agents and devices. For a team that keeps AGENTS.md and its team sections current, the prototype's design is enough, and its rules stay reviewed text.
memU does not fix the Wednesday Executor today. DeepSeek Harness is not among its tested hosts, and we have not tried its generic memu-agent adapter there. memU helps earlier, in your own Claude Code or Codex sessions, where you learn the conventions worth writing into AGENTS.md.
To try the hosted version, get an API key from memu.so and send your agent one message:
Read https://memu.pro/SKILL.md, follow its instructions to install and configure memU, API Key is
YOUR_MEMU_API_KEY.
The self-hosted setup and the support matrix are in the memU GitHub repository. More on the design is at memu.pro. For how another coding agent handles memory, see our Codex memory v2 explainer.
FAQ
Is dsh-superagent an official DeepSeek product?
No. The README calls dsh-superagent a research prototype for reference only and "not an official DeepSeek product." It also says the code is not production-ready.
What license is dsh-superagent released under?
MIT. DeepSeek Harness, the agent harness it runs on, is also listed as MIT-licensed on its own page.
Does dsh-superagent support GitHub Enterprise?
No. The deployment guide supports repositories on github.com only. The agent must also be a GitHub user account, because it reads that account's notifications.
Does DeepSeek Super-agent have long-term memory?
Its docs describe no memory store. Executors read the repository's AGENTS.md and the team's prompt sections, and each work item keeps its own session history. One work item cannot read another.
Can dsh-superagent work without being asked?
Only under a rule the team wrote, and only after someone switches the accept mode from observe to auto. In the default observe mode it records what it would have done and takes no action.