DeepSeek Super-agent, Explained: How to Build Agents Once the Bottleneck Is Human Attention

On the evening of October 31 (Beijing time), the DeepSeek Harness team published a long essay on its WeChat account, “Exploring Super-agent Design: Toward More Autonomous Agent Systems,” and at the same time open-sourced a companion prototype on GitHub, dsh-superagent-prototype.^[1][3] The next day Bloomberg ran it as “DeepSeek Drops Enhanced Coding Agent With Aim to Rival Anthropic,” and the South China Morning Post and IT Home covered it the same day.^[7][8][14] Two days in, the repository had more than ten thousand stars.

The headlines suggest a new product or model. It is neither. The README opens with “Research prototype for reference only, not an official DeepSeek product,” and the essay says it explores architecture, not features.^[1][3] What DeepSeek delivered is a design, two preliminary experiments, and a rough but runnable reference implementation.

The essay is worth a careful read, and not for the “rival Claude Code” angle. It states plainly something many people feel: how well one task goes depends on the model; how many tasks you can push at once depends on human attention. If that holds, agent competition moves from models and harnesses to system design, where computer science has decades of practice.

What was actually released

Three things came out:

• A Chinese essay in nine sections, now also circulating in a full English translation. It runs from the problem statement through five modules, two experiments, and four open questions.^[1][2]
• An MIT-licensed GitHub repository at version 0.1.0 with a single commit, made at 20:05 Beijing time on October 31. The code is mostly TypeScript, about 25,000 lines, with nine design documents meant to be read in order.^[3]
• A concrete scenario. The prototype watches one GitHub repository and, optionally, Feishu (ByteDance’s workplace chat app). When someone on the allowed list mentions it with a request, it opens a work item, does the work in its own session and directory, and replies in the original conversation, usually with a pull request. A web panel lists only what needs a person.^[3]

Screenshot: the dsh-superagent-prototype repository (captured 2026-11-02, at 11.9k stars and 1.2k forks)^[3]

The README also says the published code matches neither the internal version nor the essay, and that some designs in the essay are future directions.^[3] So the essay describes the system DeepSeek runs internally; the prototype is a smaller sample you can run.

This site has covered DeepSeek Harness before, on its main loop and plugin system and on the Cordis layer underneath. Super-agent sits on top: it is about how many sessions are organized, not how one runs.

The problem is the session as a unit

Mainstream agents use one session as the unit of work, and sessions are independent. To push several things in parallel, you switch between sessions and remember what each holds. In DeepSeek’s experience, one person can track only three to five active sessions.^[1] Anyone running several Claude Code or Codex windows knows it: by the fourth, you forget what the second is waiting on. The stronger the model, the more this ceiling shows.

Wiring a local CLI to MCP or a chat bot lets it receive group messages, but it still gets stuck: a long command blocks new messages, task contexts tangle, and the agent stops when the laptop sleeps.^[1]

So DeepSeek wants to break the binding between “an agent” and “a session someone opened by hand,” and make the agent one continuous entity. The essay names four traits. Continuity: you talk to it in IM, in GitHub comments, wherever, and it always feels like the same agent. Efficiency: several tasks run in parallel, and it takes the next instruction without waiting for the last one. Proactivity: it watches events in its environment, acts on what is worth acting on, and stays quiet otherwise. Persistence: it stays online and recovers from failures on its own.^[1]

A single ReAct loop cannot deliver all four: continuity wants every message in one context, efficiency wants tasks split apart. The five modules below mostly resolve that tension.

Router and Workers: continuity and throughput on two layers

One session for every event gives the most continuous context, but runs serially and mixes task details. A new session per event gives maximum concurrency, but related tasks stop connecting, and several sessions replying separately confuses people.^[1]

DeepSeek’s answer is to give “keep global continuity” and “run many things at once” to two different layers:

Diagram: event paths and layers in Super-agent (based on sections 2–6 of the official essay)^[1]

The Router layer is always on. It handles human interaction from every entry point and assigns work, and it serves as the global ordering point, coordination point, and memory. To keep it from becoming a bottleneck, it does not execute tasks itself. The essay says it may not even have a Bash tool. Its job is simpler than it looks, and a light model is often enough.^[1]

The Worker layer is a set of sessions with isolated contexts. Each Worker has the full execution toolset, focuses on one task, and usually runs on the strongest available model. Workers do not talk to people. Their reasoning and tool calls never reach the group chat. They report to the Router, which replies for them.^[1]

This looks like an Agent Team, but an Agent Team breaks down one complex task, and its lead must understand it deeply. The Router only decides which task goes where.^[1] A team lead benefits from being as smart as possible; the Router is closer to a dispatcher, and needs speed and steadiness.

Can one resident Router keep up? The answer is batching. Events that arrive mid-inference go in together on the next call, and since Router steps are long input and short output, merged events are computed in parallel during prefill. In the stress test, as decision-requiring Triggers rose from about 1 to about 40 per minute, the average batch grew from 1.0 to 2.8, single-request time rose only from 2.5 to 3.9 seconds, and inference time per decision fell from 6.4 to 1.6 seconds.^[1] The more backed up the queue, the cheaper each decision. It is the same idea as group commit in databases, and it still holds under LLM cost structures.

At larger scale the Router may need sharding, and then the trade-off comes back: the finer the shards, the more memory breaks across them.^[1]

Event-driven: filter first, then subscribe, then recall on demand

For an agent to be proactive, its input cannot be only prompts that a person types one at a time. It has to include semi-structured events from the environment, such as group chat messages, email and calendar reminders, code review comments, and CI results. The essay calls them all Triggers.^[1]

Real group chats are noisy, and little of the stream needs action; judging every message with a large model costs too much. So the first step is two-stage filtering. Code admits or drops events on fixed conditions such as source, chat scope, and user allowlists: that is the fast path. Only the remaining candidates go to the model, which applies policies written in the prompt to decide whether to act: that is the slow path.^[1] The slow path doubles as a natural-language extension point. To add a rule, you edit a prompt.

The second step is routing. Successive events under the same PR, IM topic, or email chain form a Thread. After the Router creates a Worker from a Thread’s first event, that Worker subscribes to the Thread, and code delivers later events straight to it without passing through the Router. Subscriptions are many-to-many, so two Workers that touch the same PR receive the same events and can notice a conflict without talking to each other.^[1] If you know message queues, this is topic subscription.

The third step is filling the context window, which the essay treats as a cache. Inline puts what the model will likely need soon into the window, saving tool calls. Spill leaves the rest outside, with a reference or summary inside.^[1] It starts with the current object’s ID and summary, inlines nearby content by locality, and truncates long content with a pointer to read more.

Every Trigger, Thread, and Worker Session gets a unique ID, and each injected object inlines the IDs of related ones, forming a reference graph. The model follows IDs hop by hop: from a message to its Thread, to the Worker that owns it, to another Thread linked to that Worker. The essay calls this Chain of Recall; it keeps a long-running Router from losing early tasks.^[1]

The last mechanism is speculative execution: like a CPU running past a branch, the agent starts work before it knows the result will be used. DeepSeek runs a “silently reproduce and fix” policy in its internal user group. When someone reports a problem, the agent tries to reproduce and fix it in the background, and speaks up only if it confirms the bug and finds a simple fix.^[1] In the essay’s example, a fix PR lands while the group is still discussing. This is what “proactive” means, and also the part most likely to go wrong.

Async ReAct, and speaking each channel’s language

In a classic ReAct loop, a synchronous run() blocks until the tool returns, and new messages wait. The essay replaces slow calls with asynchronous start() and stop(): start() returns “Started” at once, the result arrives later as a new event, and the model can stop() a job that runs too long.^[1] Conversation becomes full-duplex. This is implemented in DeepSeek Harness but not on by default. The prototype uses a blunter approach: foreground shell commands move to background jobs after 5 seconds.^[1][3]

The other half is matching output to the channel. Long reasoning stays inside Workers, and the rest is per-channel prompting. In IM, speak like a colleague, only when someone must decide or accept a result; one rule that worked in their tests is to keep each reply under 100 words. On GitHub and email, be structured and complete.^[1]

The prototype turns all this into one principle: take as little human attention as possible, and give as much value as possible. It acts only when asked or when a rule the team wrote allows it. It speaks only when someone must act or can use a result. It asks one concrete question at a time.^[4] I think 000-philosophy.md is the most worth-copying file in the repository, because it directly answers how an agent that can act for a whole team avoids becoming a source of noise.

Compute-state separation and the Watchdog: keeping it alive

A local agent ties together, on one device, the compute that runs its loop, its session state, and its execution environment. When the device sleeps, the agent stops. The essay decouples them in two steps.^[1]

First, the agent loop runs in stateless cloud containers and session state lives in a database, so containers can restart or be replaced at any time. Second, execution environments stay where they are, and each device runs a light daemon that holds no state and only executes commands. That is BYOM (Bring Your Own Machine): you connect your everyday dev machine to a cloud agent, and when the device comes back online, the cloud side can run the tasks that were waiting for it.^[1]

The essay says this follows Anthropic’s “decoupling the brain from the hands”: Managed Agents separates the session log, the harness, and the sandbox, so a dead container is a failed tool call and a dead harness resumes from the log.^[1][15] The difference is the setting. Anthropic describes on-demand sandboxes in a managed service. DeepSeek wants to connect personal machines that come and go and carry local credentials.^[1] That difference becomes a security problem.

Persistence also needs a control loop outside the main system. Many agent failures are not crashes: the model loops without progress or drifts, and liveness probes cannot see that. So a separate, timer-driven Watchdog Session has a model judge whether each Worker is making real progress. It is itself a fully tooled agent, so maintainers can ask it what went wrong, or have it change the main system’s prompts while it runs.^[1]

How to read the experiment numbers

The batching stress test was covered above. The end-to-end ablation drove four setups with streams of group chat and GitHub CI messages. Each run had about 300 messages, about 20 of them work requests, and the rest small talk, follow-ups, stop requests, and CI notices. Coding was replaced by a tool that only consumed time, and each setup ran five times.^[1]

Chart: task completion time and cache-read tokens for the four setups (Super-agent token counts from the essay text, other values from the essay’s results table image)^[1][9]

Super-agent finished with p50 at 12.4 minutes and p95 at 15.7. A single session with a Subagent tool and a neutral prompt (“use a subagent when appropriate”) hit p95 of 29.5 minutes, and the reason is the interesting part. In five runs, the model never once called a Subagent. All work happened in the main session and kept getting interrupted by new messages. With a delegate-first prompt, it delegated in four of five runs and p50 dropped to 13.8 minutes, close to Super-agent. In the fifth run the model decided the work was “small” and did it itself, and p95 stayed at 29.0.^[1][9]

To me, the most valuable thing in this data is not “almost twice as fast.” It confirms something many people have noticed in practice: letting the model decide on its own whether to delegate, through prompting, is unreliable. The model judges at every step whether to do a thing itself or hand it off, and it leans toward doing it itself. The two-layer design takes that judgment away from the model. The Router never executes work, and Workers only receive messages from Threads they subscribe to. Using structure instead of prompts is a lesson that reaches well beyond Super-agent.

The cost is stated just as clearly. One Super-agent run used 23.23 million cache-read tokens. The neutral-prompt single-session setup used 6.05 million, so Super-agent used about 3.8 times as much.^[1][9] It trades tokens for shorter, steadier completion times. Removing direct delivery left completion times essentially unchanged, but the Router made about 30% more decisions, and cache-read tokens rose from 23.23 million to 31.77 million, about 37% more.^[1] Direct delivery does not make things faster. It saves Router overhead.

The workload was synthetic, the coding was fake, and DeepSeek did not say which model it used.^[1][9][10] So these numbers show that this layering holds up better under noisy input. They do not show that it will fix more bugs in your repository.

The gap between prototype and essay

A Reddit r/singularity post on the architecture passed 900 upvotes, while Hacker News submissions drew almost no discussion.^[12][11] One Chinese developer on X wrote that the idea roughly matches Claude Tag in Slack, with tasks moving between a Feishu group and GitHub.^[13]

Screenshot: @lijiankuan on X about Super-agent, with the opening of the official essay attached (captured 2026-11-02)^[13]

People who installed it mostly agree: the design is worth learning from, and installation and fault tolerance are not ready.^[9] On Node.js 24, the service script cannot find its own process, because the main thread is renamed MainThread, so status reports a running service as down; late GitHub @-mentions can be lost for good. One tester summed up a night of setup as “love the idea, hate the install.” Another carried an issue to a PR on a private repository, after turning on observeIssues and observeComments to work around missing notifications.^[9]

Permissions deserve more attention. Router and Workers both run with danger-full-access as the operator’s OS user and can read your home directory; account wrappers switch credentials but do not isolate the process. The deployment doc recommends a dedicated OS account holding only the agent’s credentials.^[6] An independent security audit reported two problems. The local admin API checks only the Host and a request header documented in public, x-orchestrator-request: 1, so any process that can reach the local port can change the CLI path and the allowlist. And in a mixed batch, a rejected message can borrow an allowlisted member’s authorization to open a work item. As of November 1, upstream had not fixed either.^[9]

The defaults, at least, are conservative. Proactive work starts in observe mode: the agent records what it would have accepted and does nothing, and the team reviews the record before switching to auto. Explicit requests work in every mode, from allowlisted people only.^[5] This is the most practical choice in the design: the agent must show sound judgment before it gets to act.

Placing it on the 2026 agent map

DeepSeek is not the first to aim for “always on, multiplayer, proactive.” Put the main systems side by side and you can see them converging:

The closest match is Claude Tag. Per Anthropic’s June launch post, each Slack channel has one Claude everyone talks to; it builds context from the channel, and in ambient mode follows up on unresolved threads and schedules its own work over days.^[16] An August update let it decide for itself when to step in.^[17] Anthropic says 65% of its product team’s code comes from the internal version.^[16]

Continuity, proactivity, and persistence line up almost one for one, which supports the essay’s line that “similar design constraints lead to similar architectural choices.”^[1] The difference is release style. Anthropic sells a tuned product without publishing its internals. DeepSeek published the layering, the data, and the losing baselines, plus code. To build your own team agent, DeepSeek’s material is more useful; to @ a reliable assistant in Slack tomorrow, Claude Tag is less work.

Bloomberg framed this as a challenge to Claude Code, which misses the point.^[7] Claude Code is a single-session tool; Super-agent is the layer above. They stack: the essay says a Worker can itself spawn Subagents or be an Agent Team.^[1]

What I make of it

Four things are worth copying: the Router does no work, so structure enforces the division of labor instead of prompts; Thread subscriptions with direct delivery let follow-up events bypass the central node; an external Watchdog checks progress, not just liveness; and proactive behavior starts in observe until there is enough evidence to let it act. None of the four depends on DeepSeek Harness.

Now the unsolved parts. Section 8 of the essay lists four open questions, and I think security matters most.^[1] Event-driven means the agent’s input no longer comes only from a trusted operator. Anyone who can comment on a public repository, or who is in that group chat, can put text into the context of a Worker running with full access. Almost every attack path in this site’s prompt injection survey applies here. The essay admits as much: if the cloud agent loop is compromised or injected, every connected device could be taken over, and device credentials that can enter the model’s context can leak even during normal execution.^[1] In Managed Agents, Anthropic makes sure tokens are never reachable from the sandbox where generated code runs.^[15] DeepSeek’s BYOM model connects exactly the credential-heavy personal machines that make this harder.

The other three questions are open too: long-term memory over months of operation; how tasks should be shown, and how people step in midway, once sessions no longer map to chat windows; and how a team’s Super-agent and each person’s private assistant, which sit in different permission boundaries, can work together safely (agent-to-agent, or A2A).^[1]

Should you install it now? If you want to study this architecture, or give a private test repository an “on-call agent,” and you are willing to debug, yes: use a dedicated OS account, private repositories only, and yourself as the only allowlisted user. For production or public repositories, not yet. DeepSeek says the same.^[3][9]

Either way, read the essay. Its strongest point is the premise: models no longer need people to watch them work, so the thing to save is human attention. Design toward that and you arrive at routers, subscriptions, batching, compute-state separation, and watchdogs, all old ideas. The essay says the team proposed no new theory, only classic systems thinking applied to agents.^[1] That is exactly its value.

References

1. DeepSeek Harness team, “Super-agent 设计探索：迈向更自主的 Agent 系统” (Exploring Super-agent Design), WeChat, 2026-10-31: https://mp.weixin.qq.com/s/zoS7GlReWPhfCjENGxXCdg ↩
2. Full English translation, “Exploring Super-agent Design: Toward More Autonomous Agent Systems,” offloop.org: https://offloop.org/learn/exploring-deepseek-super-agent-design ↩
3. deepseek-ai/dsh-superagent-prototype, README: https://github.com/deepseek-ai/dsh-superagent-prototype ↩
4. dsh-superagent, docs/000-philosophy.md: https://github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/000-philosophy.md ↩
5. dsh-superagent, docs/002-authorization.md (observe mode): https://github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/002-authorization.md ↩
6. dsh-superagent, docs/006-deployment.md (permissions and isolation): https://github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/006-deployment.md ↩
7. Bloomberg, Debby Wu, “DeepSeek Drops Enhanced Coding Agent With Aim to Rival Anthropic,” 2026-11-01: https://www.bloomberg.com/news/articles/2026-11-01/deepseek-drops-enhanced-coding-agent-with-aim-to-rival-anthropic ↩
8. South China Morning Post, Ben Jiang, “DeepSeek unveils AI ‘super agent’ in coding race with OpenAI, Anthropic,” 2026-11-01: https://www.scmp.com/tech/article/3372884/deepseek-unveils-ai-super-agent-coding-race-openai-anthropic ↩
9. AI Code With, DeepSeek Super-agent review (full results table, a roundup of GitHub discussions #11700, #11706, and #11714, and an independent security audit), 2026-11-01: https://aicodewith.ai/en/blog/deepseek-super-agent-review-dsh-superagent ↩
10. DEV Community, “DeepSeek’s dsh-superagent is a proactive coding agent that waits to be asked”: https://dev.to/piekwerk/deepseeks-dsh-superagent-is-a-proactive-coding-agent-that-waits-to-be-asked-router-tickets-and-o8m ↩
11. Hacker News, “DeepSeek open-sources dsh-superagent, a coding agent largely built by agents”: https://news.ycombinator.com/item?id=50316116 ↩
12. ainews radar, dsh-superagent spread timeline (r/singularity and HN engagement): https://ainews.leverageai.com.au/case/deepseek-dsh-superagent-prototype ↩
13. X, @lijiankuan, 2026-10-31: https://x.com/lijiankuan/status/2116565847967924286 ↩
14. IT Home, “DeepSeek 提出 Super-agent 架构设计”: https://www.ithome.com/1/020/615.htm ↩
15. Anthropic Engineering, “Scaling Managed Agents: Decoupling the brain from the hands”: https://www.anthropic.com/engineering/managed-agents ↩
16. Anthropic, “Introducing Claude Tag,” 2026-06-23: https://www.anthropic.com/news/introducing-claude-tag ↩
17. VentureBeat, “Anthropic’s new Claude Tag update lets its Slack agent read the full conversation and jump in unprompted”: https://venturebeat.com/orchestration/anthropics-new-claude-tag-update-lets-its-slack-agent-read-the-full-conversation-and-jump-in-unprompted ↩
18. GitHub Docs, “Kick off a task with Copilot agents on GitHub”: https://docs.github.com/en/copilot/how-tos/copilot-on-github/use-copilot-agents/kick-off-a-task ↩
19. ChatGPT Learn, “Review GitHub pull requests with Codex”: https://learn.chatgpt.com/docs/third-party/github ↩