The DeepSeek Harness team published Exploring Super-agent Design on October 31, 2026, a design article on an agent system that stays online, watches for events and hands tasks to worker agents. [8] The same day, according to Chinese coverage, it released dsh-superagent-prototype, an MIT-licensed implementation in the deepseek-ai GitHub organization built for a single GitHub repository. [9][1] The prototype listens to GitHub and, optionally, Feishu or Lark chat. When an allowed person asks it 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. [1]
The release supports supervised coding help under written rules, and that is where enterprise use stands today. The hands-off operation the Super-agent label suggests exists mostly on paper. DeepSeek's README calls the code a research prototype that is not production-ready, says the published version differs from the internal one and from the implementation described in the article, and marks several designs in the article as future work the prototype does not implement. The deployment documentation adds the harder limit. Both agent presets run with danger-full-access as the operator's operating system user, and account wrappers do not isolate the process, so the docs point to a dedicated operating system account as the minimum safety measure. [1][5]
What DeepSeek shipped on October 31
The article argues that mainstream agent designs keep each session isolated, so multi-task work is capped by human attention, and the team's stated observation is that one person usually keeps up with only 3 to 5 active sessions at a time. It proposes a dual-layer architecture in which a Router takes human interaction, keeps the global context and dispatches work, while Workers execute in separate sessions and report results back to the Router, which speaks for the system. The article names continuity, efficiency, proactivity and persistence as the four base features of this agent form, and treats group messages, email, calendar reminders, code review comments and continuous integration runs as triggers that program rules filter before a model decides whether to act. [8]
The prototype runs on DeepSeek Harness, an open source agent platform in worldwide public preview. [7]
The README says the code grew out of the team's daily development work, with much of the engineering done by coding agents, and tells readers to review and adapt it before using it in their own environment. [1]
Written rules authorize every move the agent makes
Authorization comes first in the released design. The host enforces allowed lists, rules and Mandates, and each work item remains limited by its Mandate. Messages, comments and quoted documents are inputs to a decision that cannot change those permissions. A bot on the source's bot list can produce an inferred candidate for work, never an explicit request, and a follow-up message delivered on a subscribed thread grants no new authority. [3]
Unrequested work needs a rule the team wrote, and starts in a mode that only records what the agent would have done. In the prototype this is the default observe mode, which keeps a record of intended actions instead of executing them, while explicit requests that match the rules still run. The prototype's documentation recommends starting with a short allowed list and proactive work recorded only, and widening both once the recorded intentions look right. [2][9]
Execution is bounded in time and place. Each work item gets an executor session named worker-<ticket id> that runs commands without an approval step as the operator's operating system user, moves foreground shell commands to background jobs after 5 seconds, and gives background work at most 30 minutes before the item is reported as waiting for a person, with a documented exception for background shell jobs offered during a review. [4]
In conversations, the agent confirms a request once, stays quiet while it works, and writes again when a result is ready, when it needs a decision or when it cannot finish. A pass runs every 2 seconds to move due work through the engine, and an outbound message waits while its source is off and is dropped when the conversation is gone. The asynchronous execution the article describes is implemented in Harness but not enabled by default, according to a vendor statement relayed in Chinese coverage. [2][6][9]
Running it takes one machine, one repository and dedicated accounts
Setup asks for Node.js 22.19 or later or Node.js 24 or later, pnpm, git 2.32 or later, Python 3.8 or later and tmux, plus GitHub CLI 2.48 or later. The repository has to live on github.com, and GitHub Enterprise Server is not supported. A model provider must be configured, and the agent uses the profile's default model unless settings name another. [5]
The agent acts under its own GitHub user account with write access to the repository, because the system reads that account's notifications and a GitHub App cannot be the agent. Its GitHub CLI must be signed in only as that account. On Feishu, support is optional and needs a self-built app with a bot, tested against lark-cli 1.0.90. The panel serves on 127.0.0.1 on the operator's machine. [5]
The README's setup instruction is to ask your coding agent to read SETUP.md and set up dsh-superagent with you, one short question at a time. Chinese coverage of the release notes it is not a new model API or a switch in a web page. [1][9]
Full local access and open security questions block production
Behind that boundary, account wrappers choose the agent's credentials by default, a worker can execute programs by path, and it can read the operator's home directory. [5]
The architecture doc leaves open which trigger fields are trusted, the source's actor and thread membership for example, and which are not, such as the message body and quotes. Deployment isolation through a profile with its own pinned Harness installation is written down as future work. [6]
The vendor's open problems go further. Chinese coverage relays the official list as cross-month memory, external message injection, and the security of credentials split between cloud and local machine, and cautions that the cloud-local separation cannot be counted as complete deployment capability in this prototype. The watchdog session the article describes is not documented in the released prototype, whose README says some designs are unimplemented without naming them. [9][1]
The vendor's published experiment measured scheduling dispatch. It ran about 300 synthetic messages containing about 20 work requests, 5 runs per setup. The Super-agent layout showed a shorter p95 wait time, the wait time by which 95 percent of tasks finish, than a single session with a subagent tool. The single session delegated in 0 of 5 runs under a neutral prompt and in 4 of 5 under a delegation-primed prompt. The test swapped coding for tools that only consume time and did not test whether the agents' code output improves. As of November 1, 2026, no independent replication of the result has been found. [9]
Cost has no settled number. The relayed figures show the Super-agent layout reading more cached tokens than the baseline, and with a pass-through setting off, the Router made about 30 percent more decisions with higher cached reads while completion times stayed about the same. The same coverage notes that no complete bill exists to support a value-for-money conclusion. One X user, Henk Nie, added a concern the coverage labels personal, that a Router mistake could propagate faster as concurrency grows. [9]
The near edge is supervised work on one repository
A team puts the prototype on a dedicated operating system account, connects one github.com repository through a dedicated agent GitHub account, keeps proactive work in observe mode, and widens the allowed list once the recorded intentions match what the team expects. Work comes back as a pull request, a person reviews and merges it, and the panel lists whatever waits on a human. [2][9][1]
That is the near edge of the Super-agent idea as released. DeepSeek says an internal instance is already running, handling bug reproduction, code review and Harness iteration, with an internal group configured to silently reproduce and fix reported bugs, a vendor claim about a system that is not the published code. Startup Fortune reported that the deepseek-harness repository reached 177,904 GitHub stars within eight days of its August 13, 2026 launch and has since climbed past 188,000, running on an MIT license that allows anyone to inspect, fork and self-host the code. [10][9][11]
The record as of November 1, 2026 supports a conditional conclusion. An enterprise team can run a rule-bounded coding assistant on a single repository today and get supervised help with real work. Hands-off operation, where the agent keeps picking up work across channels and coordinates its own workers, depends on designs DeepSeek has written but not shipped in this prototype, on an isolation answer the deployment docs still flag as an open question, and on scheduling results for which no independent replication has been found as of November 1, 2026. Until those change, the practical Super-agent for an enterprise team is the supervised one the prototype ships. [1][5][6][9]