DeepSeek Super-Agent

DeepSeek Super-Agent is an open-source research prototype of a coding agent that watches one GitHub repo and opens pull requests when allowed people ask.

What it is: an agent that works for a team, not one chat session

The repo, dsh-superagent-prototype, is MIT licensed and written in TypeScript, as a bundle for DeepSeek Harness. It came out on November 1, 2026 together with the DeepSeek Harness team's article "Exploring Super-agent Design: Towards a More Autonomous Agent System". The README says it is a research prototype for reference only and not an official DeepSeek product. It also says the code is not production-ready, is not identical to DeepSeek's internal version, and that some designs in the article are future directions and are not implemented.

• It listens to GitHub and, optionally, Feishu. When an allowed person asks for work, it opens a work item, does the work in its own agent session and directory, and replies in the original conversation, for example with a pull request.
• A web panel shows what needs a person.
• The stated principle is to take as little human attention as possible and give as much value as possible. 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.

How the pieces fit

• Router and Workers: a long-lived Router receives requests and hands work out. It does not do the work itself. Each Worker has its own context, tools and working directory, so several tasks can run at once without touching each other.
• Triggers and Tickets: a GitHub comment is stored as a Trigger, checked for duplicates, then judged by Eval. Eval starts with plain code checks, such as who sent it and whether it is addressed to the agent, and only uses a model when a request needs interpreting. An accepted request becomes a Ticket with its own state, such as queued, working, awaiting review, blocked or waiting for a human answer.
• Mandates: a Ticket records the authorization it started under. A later comment such as "delete the old production database" can give the Worker context but cannot widen what it may do.
• Subscriptions: a Worker follows the issue and the pull request it opened, so a CI failure or a "Request changes" reaches it directly, without going back through the Router.
• Proactive modes: proactive work is off, observe or auto, and the default is observe, which records what it would have accepted for someone to review first. Explicit requests from allowed people work in every mode.
• State is kept in SQLite, with one component that writes it and a queue of outgoing messages that retries after failures.

What DeepSeek measured, and how far to trust it

The article reports two early experiments. In the first, about 300 synthetic messages with around 20 work requests were run through four setups, five runs each, with the coding work simulated by a tool that only uses time. The Super-agent setup finished at a median of 12.4 minutes and p95 of 15.7. A single session told nothing about delegating finished at 20.4 and 29.5, and one told to delegate first at 13.8 and 29.0. Removing the direct hand-off to Workers barely changed the time but raised cached tokens read from 23.2 million to 31.8 million per run.

• These measure how work is coordinated, not whether the code is good, and five runs on simulated tasks is a first signal only.
• In the second experiment, going from about 1 to 40 events a minute grew the average batch from 1.0 to 2.8 and cut inference time per decision from 6.4 to 1.6 seconds. That tested only the routing layer with simulated Workers.

Setup and what it needs

• The README says setup has many steps, so it asks your coding agent to read SETUP.md and walk you through it, one question at a time. The manual route is in docs/006-deployment.md.
• You need Node.js 22.19+ or 24+, pnpm, git 2.32+, Python 3.8+, tmux and the GitHub CLI 2.48+, plus a model provider set up for DeepSeek Harness and a repository on github.com. GitHub Enterprise Server is not supported, and one install takes one repository.
• The agent needs its own GitHub user account with write access, because a GitHub App cannot be the agent. Feishu is optional and needs a bot app and lark-cli.
• The deployment guide warns that both presets run with danger-full-access as the operator's OS user, and that a Worker can run programs and read the operator's home directory. It recommends a dedicated OS account holding only the agent's credentials.

Limits the authors and testers point out

• The article's fuller design, including an independent Watchdog that checks Workers are making progress, is a research proposal, not proven in the public prototype.
• A third-party review by Helmcode says a crash between GitHub accepting a comment and the receipt being stored can send it twice, so exactly-once delivery is not guaranteed. It also hit 404 errors and an event-loop failure after changing the Source, and fixed it by wiping the state.
• That review's own field test, with deepseek-v4-flash as Router and GLM 5.3 as Worker on private repos, reports a first reply in 40 seconds to a minute and a coding task to a pull request with tests in 2 to 3 minutes. It was one task at a time on a small sample, and it is Helmcode's measurement, not DeepSeek's.

How fresh it is

• The repository was created on October 31, 2026, and its last push was on November 3. On November 7 it had about 20,000 stars, about 2,400 forks and no open issues.
• Seailife did not install it, connect it to a repository or run any task. Everything above is from the README, its docs, DeepSeek's article and the Helmcode review.