DeepSeek’s Harness team published a design for what it calls a Super-agent on October 31, 2026: one always-on agent that takes requests from group chats and GitHub, works on many of them at once, and speaks only when a person has to act. The same day it released dsh-superagent-prototype, an MIT-licensed bundle for DeepSeek Harness that works through one repository’s issues and pull requests.
The article, posted in Chinese on the team’s WeChat account and written by Yujia Qiao, starts from a limit anyone running coding agents will recognize. The team observes that one person can usually follow only three to five active sessions. A single task is capped by the model; many tasks are capped by human attention. The repository puts the goal in one line: “take as little human attention as possible, and give as much value as possible.”
Two caveats come first. The article calls itself an architecture discussion, not a description of DeepSeek Harness features, and the repository opens with “Research prototype for reference only, not an official DeepSeek product.” Some of what the article describes is not in the code yet.
On this page · 8 sectionsOpen
DeepSeek’s Harness team published a Super-agent design on October 31, 2026, plus an MIT-licensed prototype for one GitHub repository.
Its starting point: a person can follow only three to five active agent sessions, so human attention, not the model, caps multitasking.
The design splits a Router that talks to people and hands out work from isolated Workers that do it in parallel.
In DeepSeek’s own synthetic test, the Super-agent finished requests at a p95 of 15.7 minutes against 29.5 for a single session.
DeepSeek calls the code a research prototype, not an official product, and says some of the design is not implemented yet.
§ 01What DeepSeek means by a Super-agent
The article names four properties, in our translation:
- Continuous: people talk to it in chat and in GitHub comments and it feels like one agent. A plan agreed in chat and changed later in a pull request comment is understood.
- Efficient: it takes the next instruction without waiting for the last one to finish, and runs several complex tasks in parallel.
- Proactive: it watches events and moves on what is worth handling, and stays quiet otherwise.
- Persistent: it stays online inside the team’s real tools and recovers on its own when something fails.
The team’s own instance, running on DeepSeek Harness, gives the flavor: it watched a public group chat and, with nobody mentioning it, found the root cause of a reported bug and opened a fix pull request.
§ 02The five parts of the design
| Part | What it does | Detail from the article |
|---|---|---|
| Two layers | A Router talks to people and hands out work; isolated Workers do the work in parallel | The Router may not even get a shell, and a lighter model is often enough; Workers get the strongest model |
| Events, not prompts | Chat messages, emails, review comments and CI results arrive as triggers | Code filters first; the model judges only what passes. A Worker subscribes to its thread, so follow-ups skip the Router |
| Replies people can live with | Long-running tools return at once, so the agent keeps talking while work runs | Chat replies capped at 100 words; the async task mechanism is built into DeepSeek Harness but off by default |
| Compute, state and machine apart | The loop runs in the cloud, state lives in a database, a small daemon runs commands on your own machine | Works with a developer’s own computer that is only online some of the time |
| Watchdog | A separate session on a timer checks that every Worker is making real progress | Maintainers can ask it in plain language what went wrong |
The Router is the part that differs from a familiar agent team. A team lead usually breaks one task into steps and coordinates them closely. DeepSeek’s Router never breaks a task down; it only handles people and decides which Worker gets which request. The article argues that keeping that layer thin is what keeps one Router session from becoming the bottleneck: triggers that arrive while it is thinking pile up and get handled together on the next call.
§ 03What DeepSeek’s tests showed
The team drove four setups with a synthetic stream of group chat and GitHub CI messages: about 300 messages per run, about 20 of them real work requests, five runs each. Coding was replaced by a tool that only uses time, so the test measures scheduling and coordination, not code quality. DeepSeek calls the results preliminary.
| Setup or load | Result |
|---|---|
| Super-agent | Requests finished at p50 12.4 minutes, p95 15.7 minutes |
| Single session with a subagent tool, neutral prompt | Never delegated in 5 runs; p95 29.5 minutes |
| Single session, prompt that prefers delegating | Delegated in 4 of 5 runs; still slower than the Super-agent |
| Super-agent without follow-ups going straight to Workers | Same completion time; about 30% more Router decisions; cached tokens read rose from 23.23 to 31.77 million |
| Router at about 1 trigger a minute | 6.4 seconds of inference per decision |
| Router at about 40 triggers a minute | 1.6 seconds per decision, average batch 2.8 |
The single-session result is the one to read twice. With a neutral prompt, the model chose to do every piece of work itself and kept getting interrupted by new messages. Asking it to delegate helped in four runs; in the fifth it judged the work too small to hand off and did it alone, which produced the long tail. The Super-agent removes that judgment call from the prompt: the Router simply cannot do the work.
§ 04What the prototype does today
The released code is narrower than the article. It is a proactive coding agent for one GitHub repository, with Feishu as an optional chat source. When an allowed person asks, 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 lists only what needs a person. Setup is done by your own coding agent, which reads the repository’s SETUP.md and asks one question at a time.
Its philosophy document is the most quotable part of the release. “It acts only when asked, or when a written rule allows it.” “It speaks only when a person must act or can use a result.” Work nobody asked for starts in an observe mode that only records what the agent would have accepted. And for operators: “Do not use it to produce volume.”
The repository passed 4,300 GitHub stars by November 1, about a day after it was created. Hugging Face’s Leandro von Werra shared it on X as “Another DeepSeek drop.”
§ 05The questions DeepSeek leaves open
The article ends with four problems it has not solved: how to scale past one Router session, how people should work with an agent once sessions disappear from the screen, where to draw context boundaries between separate agent instances and how those instances should talk to each other, and security. On the last, it is blunt: if the cloud loop is compromised, every machine connected to it is at risk, and credentials need a way to be used without ever entering the model’s context.
§ 06Where this meets AI employees
We build in this space, so read this section as a participant’s view. The shape DeepSeek describes, one continuous agent that people reach in the tools they already use and that carries work between conversations, is the shape of an AI employee. On CellCog, each AI employee has its own secure VM and file system plus its own browser identity and logins, and it can fill a saved website login without ever seeing the password, which is one answer to DeepSeek’s last open question. The difference in scope: the prototype is one agent for one repository’s team, while CellCog employees take any role and work in teams with managers. For how we think about one agent versus subagents, see one agent or subagents; for how general agents compare, see our super agent rankings.
§ 07What we are watching
- Whether DeepSeek turns the async task mechanism on by default in DeepSeek Harness.
- An English version of the article, or a DeepSeek post on its own news page.
- The first outside team that reports running the prototype on a real repository.
§ 08Sources
- DeepSeek Harness team, Super-agent design exploration, WeChat, October 31, 2026, read November 1.
- dsh-superagent-prototype README and philosophy document, GitHub, read November 1, 2026.
- Leandro von Werra on X, October 31, 2026.
Q1What problem does the Super-agent design solve?
Attention. DeepSeek’s team observes that one person can follow about three to five active agent sessions, so running more work in parallel needs one agent that manages its own sessions and only asks a person when a decision is needed.
Q2How is it different from a lead agent with subagents?
The Router does not do the work and does not break a single task into steps. It only handles people and hands each request to an isolated Worker, which can itself use subagents.
Q3What did DeepSeek's tests show?
On a synthetic load of about 300 messages, 20 of them work requests, the Super-agent finished requests at a p50 of 12.4 and a p95 of 15.7 minutes. A single session with a subagent tool and a neutral prompt never delegated and reached 29.5 minutes at p95.
Q4Where does the prototype work?
On one GitHub repository, with Feishu as an optional chat source. It opens a work item per request, works in its own session and directory, and answers in the original conversation, for example with a pull request.
Q5Is the prototype safe to point at a real team?
DeepSeek says to start narrow: a short allowed list, and proactive work only recorded until what the agent would have done looks right. It runs commands without approval as the operator’s user, so treat it as research code.