DeepSeek Open-Sources a 'Super-Agent' That Takes Coding Requests From a Whole Team

DeepSeek has published the code for an experimental "super-agent" that sits inside a software team's GitHub repository and picks up coding work when an approved person asks for it. The project, called dsh-superagent, went up on GitHub on October 31 under the MIT licence, and the Chinese AI lab's Harness team followed with a long design essay over the weekend.

DeepSeek is clear that this is not a finished product. The README opens with a warning that the release is a "research prototype for reference only, not an official DeepSeek product," and that much of the engineering was done by coding agents. Even so, it is one of the most detailed public blueprints yet for an always-on agent that works for a whole team rather than one developer, and it lands in the same week GitHub showed its own multi-agent Copilot app.

Key facts at a glance

• What it is: dsh-superagent, a proactive coding agent for one GitHub repository, packaged as a bundle for DeepSeek Harness, the company's open-source agent app.
• When: Code first committed on October 31, 2026; licence is MIT.
• How it works: It listens to GitHub and, optionally, Feishu chats, opens a work item when an allowed person asks, works in its own session and directory, and replies in the original thread, for example with a pull request.
• Guiding rule: "Take as little human attention as possible, and give as much value as possible," according to the project's philosophy document.
• Caveat: Worker sessions run with full access as the operator's OS user, so DeepSeek advises a dedicated OS account for isolation.

How we got here

DeepSeek Harness is the agent app this prototype plugs into. DeepSeek describes Harness as being in public preview worldwide and open source, built on an "everything is a plugin" architecture called Cordis. It runs as a desktop app for macOS and Windows or as a web interface, and DeepSeek pitches it for organising documents, analysing spreadsheets and running background tasks as well as writing code.

The super-agent is the next step up. Most coding assistants today wait for one developer to type a request into an editor or terminal. DeepSeek's design instead watches a shared space, a repository's issues and pull requests or a team chat, and decides whether a message is a request it is allowed to act on. That makes it closer to a junior teammate who reads the team channel than to an autocomplete tool.

The release also arrives while DeepSeek faces pressure in the United States, where civilian federal agencies were told last month to remove DeepSeek software. Nothing in the super-agent code changes that position, but it does mean US organisations evaluating it will need to clear their own policies first.

How the super-agent decides what to do

Requests have to come from the right people. The authorization document describes a gate that checks every incoming message. An allowed person who mentions the agent or messages it directly makes an "explicit" request. Messages from people not on the list, or messages that do not address the agent, fall under an admission table that the team configures for each chat or type of GitHub event. Bots such as dependabot[bot] can be placed on a list, but they can only create "inferred" candidates and can never make explicit requests or stop work.

Text cannot rewrite the rules. DeepSeek states that the host enforces allowed lists, rules and what it calls Mandates, and that "messages, comments and quoted documents are inputs to a decision; they cannot change those permissions." Only the web panel can change execution settings; text sent to the agent's main session cannot. That matters because an agent reading open issues and chat threads is an obvious target for anyone trying to slip instructions into a comment.

Proactive work starts in a dry-run mode. The philosophy document says work nobody asked for needs a rule the team wrote, and "starts in a mode that only records what the agent would have done." Operators are told to start with a short allowed list and widen it only once the recorded actions look right.

How the work gets done

Each job is a Ticket with its own worker. Once a request is accepted, the agent creates a Ticket, an Executor session named after it, and a working directory under a configurable root. A typical setup uses git worktree to give each Ticket its own checkout, and a pull request is linked to a Ticket when the last segment of its branch name matches the Ticket's short name.

Long jobs move to the background. Worker sessions push foreground shell commands into background jobs after 5 seconds, so the agent can still receive new messages mid-task. After each turn, background work has at most 30 minutes to finish before shell jobs are killed and the Ticket is marked as waiting. A preparation command for a new Ticket gets ten minutes.

People can always get through. The number of parallel workers is capped by a maxWorkers setting, but DeepSeek reserves one extra slot for a person's message or a status request, so new work cannot block someone trying to continue an existing job. A web panel shows only what needs a human: tickets awaiting an answer, awaiting review, or blocked.

Where it fits among coding agents

DeepSeek is pitching the same kind of work as Anthropic's Claude Code and OpenAI's Codex, and in August it released a preview of its own agent app aimed at that market. US companies are moving in the same direction: at its Universe conference on Wednesday, GitHub showed a Copilot app that runs agent work across several repositories in parallel sessions.

The difference is mostly in posture. DeepSeek's design is explicitly team-facing and chat-aware, and its documentation spends as much space on restraint as on capability. "An agent that can act for a whole team can also waste a whole team's attention," the README says, so 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." The philosophy document goes further, telling operators not to use the agent "to produce volume" such as mass pull requests or broadcast messages.

The other view: teams of agents are still hard

Not everyone is convinced that agents working alongside each other, or alongside a whole team, deliver more. In January, researchers behind the CooperBench study found that coding agents performed worse when they had to cooperate: success rates were on average 30% lower than when each agent did the tasks alone. That study did not test DeepSeek's agent, but it is a useful reminder that coordination, not raw coding skill, is often the bottleneck.

There is also a security trade-off that DeepSeek states plainly. Both of the bundle's presets run with danger-full-access as the operator's OS user. "A worker can execute programs by path and read the operator's home directory," the deployment guide warns, and account wrappers "do not isolate the process." For any team that keeps cloud keys, SSH keys or customer data in a developer's home directory, that is a reason to run the prototype on a separate machine or account.

What it means for you

For developers in the US, UK, Canada and Australia, this is a free, inspectable reference design rather than a tool to drop into production. If you are building internal agents, the authorization model, the record-only mode for proactive work and the reserved slot for humans are ideas worth borrowing whatever model you use. The bundle uses whatever default model the Harness profile is configured with, so it is not tied to DeepSeek's own models.

For engineering managers, the useful lesson is the attention budget. DeepSeek treats every message, notification and setting as a cost to the team. Teams piloting any coding agent can apply the same test: does this notification save more time than it takes to read?

For security teams, the prototype is a case study in what to ask of any repository-watching agent: who can trigger it, whether comments can change its permissions, what account it pushes as, and what it can read on the host.

What happens next

DeepSeek says the published code is not identical to its internal version and that some ideas in the design essay are "directions for future development" that the prototype does not yet implement. The repository had no tagged releases at publication, and its deployment guide pins a preview build of Harness, version 0.2.1-rc.3. The open questions are whether DeepSeek turns the super-agent into a supported part of Harness, whether it adds connectors beyond GitHub and Feishu such as Slack, and how it answers the isolation concerns its own documentation raises.

Takeaways

• Treat it as a blueprint, not a product. DeepSeek itself says to review and adapt the code before running it.
• Isolate it if you test it. Use a dedicated OS account and a dedicated GitHub user, as the deployment guide recommends, and keep personal credentials off that machine.
• Start in record-only mode. Keep the allowed list short and let proactive rules only log what they would do until the results look right.
• Borrow the attention rule. Whatever agent you use, cut notifications and messages that do not lead to a decision or a result.