DeepSeek published the code for Super-Agent on October 31, 2026, as the GitHub repository deepseek-ai/dsh-superagent-prototype, under the MIT license. Most coding agents wait for someone to open a chat. Super-Agent instead watches the places a team already talks, which are GitHub and optionally Feishu. When an authorised person asks for work, it opens a work item and runs the job in its own isolated session. It then replies in the original thread, usually with a pull request.
DeepSeek is clear that this is a research prototype for reference, not an official product, and not production-ready. That makes it more useful as a design to study than as a tool to install. This article explains how the DeepSeek super agent works, what is new about it, and what business teams can take from it even if they never run it.
What is DeepSeek Super-Agent?
Super-Agent is a team-level coding agent for a single GitHub repository. It runs on DeepSeek Harness, DeepSeek's agent runtime, and has three visible parts:
- Sources. Plugins for GitHub and Feishu turn messages, issues and comments into "triggers".
- A router. One long-running session reads incoming triggers and decides whether each is real work.
- Workers. Each accepted job gets its own executor session and working directory, so tasks don't share state.
A web panel lists the items that need a person: questions a worker can't answer, tickets waiting for approval, and failures.
The guiding rule in the README is to use as little human attention as possible while delivering as much value as possible. That is the core idea. The scarce resource is the team's attention, not the model's compute.
How it works: triggers, tickets and mandates
DeepSeek's architecture notes describe a pipeline that looks more like a work-order system than a chatbot.
- A trigger arrives. A GitHub comment or a Feishu message is stored once. Duplicates are recognised and filtered out.
- The router evaluates it. Triggers from the same thread are batched into one evaluation, so a burst of messages leads to one decision instead of five.
- Accepting it creates a ticket. The ticket is the unit of work. It is created atomically together with a mandate, a record of the authority it was accepted under (for example, "an allowed person addressed the agent directly").
- A worker runs the ticket. The worker can read its own ticket and the threads it subscribed to, and nothing else. It cannot message people directly, reschedule itself or edit outside documents.
- Replies go out through an outbox. Side effects run only after the state change is committed, with retries and backoff.
The mandate is the part worth copying. Each piece of work carries a written answer to "why is the agent allowed to do this?", and that answer is re-checked whenever the team changes its rules. If a person says stop, the mandate is withdrawn and the work halts.
Proactive, but only with permission
The headline feature is that the agent can act without being summoned, for example by noticing a coding problem in a group chat. DeepSeek knows an eager agent can waste a team's time, so the default is conservative:
- Explicit requests from allowed users always work.
- Implicit requests are only recorded as "would have accepted": unaddressed messages, bot messages, and follow-ups from people not on the list. The agent does not act on them.
- Auto mode turns on proactive acceptance only after the team has reviewed those records and written rules that match.
The allow lists and rules are enforced by the host, not by the model. A message, comment or quoted document cannot talk the agent into wider permissions, which is the right defence against prompt injection for any agent that reads open chat channels.
Merging follows the same restraint. By default the agent does not enable auto-merge under its own account, because GitHub credits the merge to whoever enabled it. A person merges unless the team's delivery prompt names another account.
DeepSeek Super-Agent vs Claude Code and Codex
Press coverage has framed Super-Agent as DeepSeek's answer to Anthropic's Claude Code and OpenAI's Codex. The comparison is only partly fair:
| Claude Code / Codex (typical use) | DeepSeek Super-Agent | |
|---|---|---|
| Who starts the work | A developer in a session | Any allowed person in a team channel, or a team rule |
| Scope | The developer's task | One repository, many requesters |
| Isolation | One session per developer | One session and directory per ticket |
| Authority | The developer's own permissions | A recorded mandate, re-checked against policy |
| Maturity | Commercial products | Research prototype |
DeepSeek has not published benchmarks against other agents, so claims about which one is "better" are unverified. Super-Agent's real contribution is the coordination layer around the model, not the model itself.
Risks before you try it
- It is a prototype. The README warns of bugs and inconsistent engineering, and says the public code differs from DeepSeek's internal version.
- Isolate it. It runs shell and file tools, so start in a sandbox or a dedicated machine with its own GitHub account, not on a developer laptop.
- Data growth. DeepSeek's own notes say nothing deletes old records yet.
- Policy. Some organisations restrict DeepSeek software. Check your own rules before installing.
What business teams should take from it
You don't need to adopt DeepSeek's code to use its ideas. They apply to any AI agent that does work for a team rather than for one person:
- Make every job a ticket. Give each request an owner, a status and an outcome. "The agent did something in the chat" isn't auditable.
- Write down the mandate. Record who asked and which rule allowed it, and re-check that when the rules change.
- Keep permissions out of the prompt. Enforce allow lists in code, so a pasted email or document can't expand what the agent may do.
- Run in observe mode first. Log what the agent would have done, review it for a week or two, then switch on autonomy rule by rule.
- Isolate every job. Use a separate session and workspace per task, so one bad run can't corrupt another.
- Spend human attention deliberately. Put everything that needs a person in one queue, rather than scattering pings across channels.
This is the same trade-off we cover in autonomous vs semi-autonomous AI agents: autonomy is earned per workflow, not switched on all at once. If you're weighing whether to build this kind of agent in-house or with a partner, our guide on how to choose an AI agent development company lists the questions to ask.
The bottom line
DeepSeek Super-Agent is less a Claude Code killer than a public blueprint for team agents: triggers in, tickets with mandates, isolated workers, and one queue for human attention. Read the architecture docs, borrow the patterns, and wait for a stable release before putting it near production code.