DeepSeek Super-agent Explained: What Makes It Different

DeepSeek's super-agent is one AI that a whole team talks to in its normal chat and on GitHub. Behind it, a single "router" session takes every request and hands each job to its own "worker" session. On 31 October 2026 DeepSeek published the design and an open-source prototype, dsh-superagent-prototype. The interesting part isn't speed. It's how hard the design works to stay quiet and not waste people's attention.

I read DeepSeek's long design article, all nine design documents in the repository, and the prompts the agent runs on. Here's what a super agent is, how this one works, and what is actually new.

What is a super agent?

A super agent is one always-on AI that handles many jobs at once without you opening a new chat for each one. You talk to it where you already work, and it keeps track of which conversation belongs to which job.

DeepSeek starts from a problem most people using coding agents will know. Today every job lives in its own session. You switch between them and try to remember what each one knows. In DeepSeek's words, a person can usually follow only 3 to 5 active sessions at once. So with one task, the model is the limit. With many tasks, your attention is the limit.

The article lists four things a super agent should be:

• Continuous: it feels like one agent. Say "use plan A" in chat, then "actually plan B" in a GitHub comment, and it follows.
• Efficient: it takes a new request before the last one is finished.
• Proactive: it watches events and acts on the ones worth acting on, and stays quiet otherwise.
• Persistent: it stays online and recovers from errors on its own.

DeepSeek says its own internal super-agent already runs every day. It reproduces and fixes bugs, answers code review comments, and helps build DeepSeek Harness itself. It also watches a public group chat and opens fix pull requests when nobody has tagged it.

What is dsh-superagent-prototype?

It is a working, cut-down version of that idea for one GitHub repository. It runs as a plugin bundle for DeepSeek Harness, DeepSeek's open-source agent app.

It listens to GitHub and, if you want, Feishu (ByteDance's work chat, similar to Slack). When an allowed person asks it for work, it opens a ticket, does the job in its own session and folder, and replies in the same conversation, often with a pull request. A web panel shows only what needs a person.

The README is blunt. It says this is a "research prototype for reference only, not an official DeepSeek product". It also says the code differs from DeepSeek's internal version.

I cloned it on 2 November 2026 and counted. There is a single commit dated 31 October 2026 under the MIT licence. It has about 15,200 lines of TypeScript in 110 files and 65 test files with about 790 test cases. There are also nine numbered design documents, which you are meant to read in order. It already had about 11,400 stars on GitHub when I checked.

How does the router and worker design work?

One long-running router session talks to people and hands out jobs. Each job goes to its own worker session with full tools and a clean context. Workers never talk to people directly. They report to the router, and the router replies.

DeepSeek explains why both obvious choices fail. Put every event into one session and its context stays joined up, but it is slow and the jobs get mixed together. Start a new session for every event and it is fast, but nothing knows what anything else is doing, and several sessions all talk to the user at once.

So the router only routes. It doesn't even need a shell tool, and DeepSeek says a lighter model often does the job. The workers do the real work, so they get the strongest model. In the prototype, the router note to a worker is capped at 30 words.

Isn't one router a bottleneck? DeepSeek tested that. Events that arrive while the router is thinking pile up and go into its next model call together. In their stress test, raising the rate from about 1 to about 40 decisions a minute took the average batch from 1.0 to 2.8 events. Each call only went from 2.5 to 3.9 seconds, so the time per decision fell from 6.4 to 1.6 seconds. For a team their size, one router is enough.

How does it decide what to act on?

In two steps. Plain code checks first: who sent it, which chat or repo, and whether they tagged the agent. Only what passes goes to the model, which judges it against rules the team wrote in plain English.

DeepSeek borrows the "fast path, slow path" idea from computer systems. Most group chat messages need nothing from an agent. Calling a model for every one would be slow and costly, so cheap code throws most of them away first.

The prototype makes this concrete. Each source has an allowed list of people and an admission table. A request is "explicit" when someone on the list tags the agent, and those always work. Anything else is only a candidate. Bots can only make candidates. They can never ask for work outright or stop a job.

Then comes the part I like most. Work nobody asked for, such as fixing a bug it spotted in chat, starts in "observe" mode by default. The agent judges the message and writes down "would accept", but does nothing. You read what it would have done, and only then switch to "auto".

Once a job exists, the worker subscribes to its thread: the issue, pull request or chat topic it came from. Later messages on that thread go straight to the worker, without asking the router again. DeepSeek calls this pass-through. In their test, turning it off made the router take about 30% more decisions and read about 37% more cached tokens (23.23 million to 31.77 million per run), with no change in speed.

What makes DeepSeek's super-agent different?

Lots of tools now run agents in the background. What stands out here is that attention is treated as a budget. The first design document says it plainly: take as little human attention as possible, and give as much value as possible. Every message, setting and panel item has to earn its place, or it goes.

That rule shows up all over the code and prompts:

• It confirms a request once, then stays quiet while it works. It speaks again only for a result, a question, or a failure.
• Chat replies default to one sentence, with a hard limit of 100 words. DeepSeek says this simple rule worked well.
• It asks one concrete question at a time, in a structured form, so the question doesn't get lost in a long report.
• Opening a pull request does not count as done. A draft is marked unfinished, and a UI change without a real "before" screenshot is not ready.
• Every GitHub message starts with "This is by an automated agent, not a human" by default.
• It never turns on auto-merge as its own account. By default it may only auto-merge its own approved pull requests under 200 changed lines, and only through another account you name.
• The panel shows what waits for a person first. A healthy system takes up no space.

The other new idea is how it feeds the model. DeepSeek treats the context window like a cache. Likely-needed details go inline, such as the first 50 characters of a message and its neighbours. Long text is cut off with a pointer to read more. Every object has an ID that links to related objects, so the router can follow a chain from a message to its thread, to the worker, to another review thread. DeepSeek calls this the chain of recall. As they put it, wasting the context window means wasting the model's intelligence.

The article also asks the model to act ahead. DeepSeek's own user group runs a "quietly reproduce and fix" rule. While people are still discussing a bug, the agent tries to reproduce and fix it in the background. It only speaks if it confirms the bug and finds a simple fix. Otherwise nobody hears from it.

Is a super agent faster than one session with subagents?

In DeepSeek's own test, yes, and much more predictable. The super-agent finished requests in 12.4 minutes at the median and 15.7 minutes for the slowest 5%. One session with a subagent tool took 20.4 and 29.5 minutes.

The reason surprised me. With a neutral prompt ("use a subagent when appropriate"), the model never used a subagent in 5 runs. It did all the work itself and kept getting interrupted by new chat messages. With a prompt that pushed it to delegate, it did so in 4 of 5 runs. In the fifth it decided the job was "small", did it itself, and that run dragged the slowest times out to 29.0 minutes.

The super-agent takes that choice away from the model. The router can't do the work itself, and each worker only hears its own threads.

It costs more tokens, though. The super-agent read 23.23 million cached tokens per run, against 6.05 million and 10.82 million for the single-session setups. DeepSeek says this openly. You spend tokens to get shorter, steadier waits.

The test has limits, and DeepSeek lists them. Each run had about 300 chat and CI messages, with about 20 real work requests. The coding was replaced by a tool that just waits. Message gaps and work times were scaled to a quarter, while the model calls were real. So it measures scheduling, not whether the code is any good. DeepSeek calls the results preliminary.

What is in the article but not in the prototype?

Several big ideas are still future work. The README itself says some designs in the article "are not implemented in this prototype".

• Non-blocking tools.: The article's async start() and stop() tools let the agent take new messages while a long command runs. DeepSeek says this is in DeepSeek Harness but not on by default. The prototype gets close another way: worker shell commands move to the background after 5 seconds.
• Cloud brain, your machine.: The article wants the agent loop and its memory in the cloud, with a small daemon on your own PC running the commands. DeepSeek calls this "bring your own machine", and compares it with Anthropic's "decoupling the brain from the hands". The prototype runs on one machine.
• Watchdog.: In the article, a separate agent session checks on a timer whether workers are making real progress or going in circles. The prototype's setup has a simpler hourly check that repairs the service when it isn't running.

DeepSeek is also frank about the open problems: memory over months, when to split the router, how separate agents should talk to each other, and security.

Is it safe to run?

Only in a small, trusted setup for now, and DeepSeek says much the same. An agent driven by outside messages sees a lot more untrusted text. If the system is broken into or tricked by a prompt injection, everything it connects to is at risk. Keys that end up in the model's context can leak.

The prototype's documents are clear on this too. Workers run commands without asking, as your own user account. The command block-list and account wrappers "establish defaults, not a security boundary". The good news is that the permissions are enforced in code. A message or comment can't talk the agent into new permissions. The design treats outside text as data, never as rules.

Their advice to operators is worth copying even if you never install it. Start with a short allowed list. Keep proactive work in observe mode. When the agent is noisy, make the prompts shorter and stricter instead of adding more messages. And read what it posts in your name, because you own it.

Should you try DeepSeek's super-agent?

If you run a GitHub project with a small team, it is worth reading even if you don't install it. The nine design documents are some of the clearest writing I've seen on running an agent for a team. If you do install it, give it a test repository and a dedicated GitHub account, and expect alpha software.

I use DeepSeek Harness already. In my DeepSeek V4.1 Flash-1017 test it built a whole 3D game from one prompt, which you can play here. I haven't run the super-agent on a real repository yet, so this article is about the design, not my results with it.

What I keep thinking about is the starting point. In Is the Programmer Outdated? I wrote that agents now do much of my typing, while I still decide what matters. DeepSeek's design is built around the same idea. When agents can do the work, people's attention is the scarce thing, and a good agent knows when to keep quiet. If you want the bigger picture of always-on agents, my earlier piece on the era of AI agents covers it, and my PC that now works for AI agents shows what this looks like on one home machine.

Sources (checked 2 November 2026): DeepSeek, "Super-agent 设计探索：迈向更自主的 Agent 系统" (Exploring Super-agent Design: Towards a More Autonomous Agent System), DeepSeek's verified Zhihu account, edited 1 November 2026, sections 1–9 including the section 7 results table and figures; deepseek-ai/dsh-superagent-prototype on GitHub (README, SETUP.md, docs 000–008, prompts; commit 6337fc8, 31 October 2026); DeepSeek Harness product page. The line and test counts are my own count of the cloned repository. The chart is redrawn from DeepSeek's table; the speed and token figures are DeepSeek's own and were not checked independently.

The images were made locally with Qwen Image 2.1, and AI helped me research and edit this article.