DeepSeek Super-agent Design: Router, Workers, Triggers and a Watchdog Explained

On November 1, 2026, the DeepSeek Harness team published Exploring Super-agent Design: Towards a More Autonomous Agent System, a machine-translated version of a Chinese design article. It is the paper behind the dsh-superagent-prototype repo we covered yesterday. At that time we could not find the article. It drew about 82,700 views and 1,600 likes in its first hours on X, and the prototype repo had grown to about 5,400 stars.

The claim is simple. Coding agents now need less help per task, so the limit has moved to human attention. The authors say "a person can usually follow only 3 to 5 active sessions at once." Their answer is to stop making people manage sessions. One agent lives in chat and on GitHub. Behind it, a light Router talks to people and isolated Workers do the work. This post walks through the five modules, the numbers, and which parts you can copy into a Claude Code subagent setup or your own harness today.

TL;DR: what people are asking

What is a Super-agent?

DeepSeek defines a Super-agent as "one continuous entity that keeps its context across sessions and works on several complex tasks at once." It must have four traits:

• Continuous. It always feels like one agent. Ask for Plan A in chat, switch to Plan B in a PR comment, and it follows.
• Productive. It runs several complex tasks in parallel and takes new instructions before old ones finish.
• Proactive. It watches its environment, acts on what is worth handling, "and stays quiet otherwise."
• Persistent. It stays online, connects to real work environments and recovers from failures by itself.

The team's own instance does this today. Its first example is one feature request that moves from a group chat to a GitHub review and back, with the same agent tracking every change.

DeepSeek Super-agent carrying one font-settings task from an IM group chat into a GitHub pull request review and back

Figure: DeepSeek Harness team, "Exploring Super-agent Design".

The authors argue that adding MCP servers or CLIs to a local single-session agent does not fix this. The session still blocks on long operations, mixes context from different tasks, and "everything stops whenever the local device goes offline." If you have run OpenClaw or a proactive agent for a few weeks, you have likely hit all three.

The whole design is five modules, numbered in the overview diagram:

DeepSeek Super-agent architecture overview: event triggers, two-stage filter, Router layer, Worker sessions, session database, environments and Watchdog

Figure: DeepSeek Harness team. Numbers match the article's sections 2 to 6.

Why not one big session or one session per task?

This is the trade-off the whole design is built on. Send every event to one session and context is fully shared, but a ReAct loop works one step at a time, so throughput is low and different tasks pollute each other's context. Give every event its own session and throughput is high, but results come back unconnected and several sessions reply to the user separately.

The two-level split takes the good half of each:

Two-level Super-agent architecture with one Router layer for routing and external interaction and several isolated Worker sessions running tasks in parallel

Figure: DeepSeek Harness team.

The line that matters most for product people: "Sessions should be an implementation detail of the system, not a mental burden on its users." Today most harnesses make the session the unit of project management. DeepSeek says that habit was carried over from low-level LLM APIs.

The Router layer: dispatch, never execute

The Router receives all human input from every channel. It is the system's "global sequence point, coordination point, and memory." To stop it becoming a bottleneck, it does not execute tasks and "can run without a Bash tool at all."

DeepSeek separates this from a typical agent team. In an agent team, a lead breaks one coupled task into steps and coordinates closely. That is heavy reasoning. The Router only dispatches separate tasks and tracks how they relate at a high level. The authors found the Router's job "is often simpler than expected, and a lighter model can usually provide both speed and quality." For a deeper look at the lead-and-members pattern, see our multi-agent orchestration patterns guide.

The Worker layer: isolated, strongest model, never talks to people

Each Worker owns one task, has an isolated context and a full tool set. Because Workers decide the quality of each result, DeepSeek says they "usually need the most capable models." Workers report to the Router. The Router writes every reply. That keeps tool logs and reasoning out of the group chat.

Workers do not message each other by default. When two Workers touch the same PR, both subscribe to that PR's event stream, so they see the same events and can resolve conflicts themselves. A Worker can itself use subagents or be an agent team. The Router does not need to know.

How do Triggers make the agent proactive?

The main input is no longer a typed prompt. It is a stream of semi-structured events: group chat messages, emails, calendar reminders, code review comments, CI results. DeepSeek calls these Triggers. Four mechanisms handle them, in order.

1. Filter first, with code before the model

Real group chats are noisy, and "the vast majority of everyday messages need no action from the agent." Running a large model on every message costs too much time and compute. So DeepSeek borrows the fast path / slow path split from systems design.

• Programmatic policies (fast path). Code checks the source, group, and user or bot allowlists. Each source can be set to "respond only to explicit requests", "treat as candidate events", or "ignore".
• Semantic policies (slow path). Events that pass go to the LLM, which decides based on context and policies written as prompts. People can add or switch off policies in plain language.

DeepSeek Super-agent two-stage event filtering: programmatic fast-path rules drop most messages before semantic slow-path policies judge the rest

Figure: DeepSeek Harness team.

This is the cheapest idea in the paper to copy. If your bot answers on Slack or Discord, put allowlists and per-channel modes in code before any model call.

2. Route follow-ups by Thread, not through the Router

Consecutive events on one PR, one chat topic or one email chain form a Thread. When the Router creates a Worker for a Thread's first event, that Worker subscribes to the Thread. After that:

• Subscribed (fast path): code passes new events in that Thread straight to the Worker. No Router decision.
• Unsubscribed (slow path): the Router still sees every event, but only evaluates events with no subscriber yet.

DeepSeek Super-agent subscription and pass-through: the first event goes through the Router, follow-up events in the same Thread go directly to the subscribed Worker

Figure: DeepSeek Harness team.

Subscriptions are many-to-many. A Worker can follow several Threads, and a Thread can have several Workers. If a new event is outside the task, the Worker can unsubscribe or hand it back to the Router.

Try the trade-off yourself. Toggle the design, then step through twelve events and watch how many model decisions the coordinating session makes.

3. Treat the context window as a cache: Inline, Spill, Chain of Recall

DeepSeek frames context injection with two terms from compilers. Inline puts what the model will likely need next straight into the window. Spill keeps the rest outside and leaves an ID or a short summary. "Wasting the context window is wasting the model's intelligence."

In practice: start with the object's ID and a summary. Then inline nearby things, such as the IDs of related objects, the first 50 characters of content, the messages around a reply, and nearby review comments. Truncate long content and leave a pointer so the model can fetch the rest.

The Router has a harder problem. After weeks of work it cannot hold every past task, yet a user can bring up an old task in another channel. The answer is Chain of Recall. Every Trigger, Thread and Worker Session has an ID. Every recalled object inlines the IDs and summaries of the objects linked to it. The model follows those links one hop at a time, as far as it needs.

DeepSeek Chain of Recall: each recalled object inlines the IDs of next-hop objects so the Router can expand context hop by hop

Figure: DeepSeek Harness team.

If you have built memory for Claude Code or a shared markdown wiki between agents, this is the same idea with stricter rules: every object carries pointers to its neighbors.

4. Act ahead: speculative execution

The agent can start work before anyone asks. A meeting invite arrives, and it checks the calendar and drafts a reply. In DeepSeek's internal user group, a "silently reproduce and fix" policy tries to reproduce reported bugs in the background. It posts only when it has confirmed the issue and found a simple fix. "Otherwise, it stays quiet the whole time." The cost is extra background compute. The gain is fewer people waiting.

What is full-duplex interaction?

In a classic ReAct loop, a synchronous run() tool call blocks the session until it returns. The user waits. DeepSeek replaces long calls with start() and stop(). start() returns "Started" at once, and the finished result arrives later as a new event. The model can call stop() on a command that runs too long.

Classic versus asynchronous ReAct loop in DeepSeek Super-agent: an async start call returns immediately so the session keeps answering while background tools run

Figure: DeepSeek Harness team.

New input is now handled "as soon as the current inference step ends, rather than after background tools finish." The article notes that DeepSeek Harness already implements this, "but it is not yet enabled by default." Our loop engineering guide covers why blocking tool calls hurt long agent runs.

Different channels need different replies

Tool logs that suit a terminal will flood a group chat. DeepSeek sets rules by channel:

The 100-word cap is another rule you can add to any chat-facing bot today.

How does it stay online when your laptop sleeps?

Local agents tie three things to one device: compute (the agent loop), session state, and the execution environment (repos and toolchains). DeepSeek splits them in two steps.

1. Compute from state. The agent loop runs in stateless cloud containers. Sessions live in a database. Containers can restart or scale and nothing is lost.
2. Compute from environments. The repos, credentials and hardware stay where they are. Each machine runs a light daemon that "keeps no session state and does nothing but execute commands and return results."

DeepSeek Super-agent compute-storage separation: the cloud Agent Loop is separate from persistent session state and reaches execution environments through endpoint daemons

Figure: DeepSeek Harness team.

The article credits Anthropic's "Decoupling the brain from the hands" for the same approach. The difference is the target. Anthropic's version is a managed service with on-demand sandboxes, which we covered in Claude Managed Agents. DeepSeek wants BYOM (Bring Your Own Machine): your real dev laptop, with uncommitted changes and local credentials, online only some of the time. When that machine reconnects, the cloud agent runs the tasks that were waiting for it.

What does the Watchdog do?

Many agent failures are not crashes. "The process is still running, but the model is stuck in an unproductive loop or has drifted from its goal." A liveness probe cannot see that.

DeepSeek's Watchdog is a separate agent session, driven by scheduled messages, outside the main system. It handles infrastructure faults such as API errors and failed state recovery. It also uses the model to judge whether each Worker is making real progress. Because it is a full agent session, maintainers can ask it in plain language why something failed, or tell it to change prompts and trigger rules while the system runs. Our post on multi-agent error propagation explains why one stuck Worker can spread bad state if nothing watches it.

Did it actually work? The experiments

DeepSeek ran two tests on synthetic workloads. The authors say "the results below are indicative only."

End-to-end: four designs, five runs each

Each run had about 300 messages from a group chat and GitHub CI, of which about 20 were work requests. The rest were chat, follow-ups, cancellations and CI noise. Coding was simulated by a tool that only uses time, so the test measures scheduling, not coding skill.

Cumulative work requests and completions for Super-agent, Super-agent without pass-through and two single-session designs, mean of 5 runs

Figure: DeepSeek Harness team, ablation study.

Three findings stand out:

• Prompts are not a reliable delegation switch. With the neutral prompt, the model did not call a subagent in any of the 5 runs. With a strong "prefer handing each piece of work to a subagent" prompt, it delegated in 4 of 5 runs. In the fifth it judged the work "small" and did it itself, which produced the long tail. The two-level design removes that choice: the Router cannot execute.
• You pay in tokens. The Super-agent used about 2 to 4 times the cache-read tokens of the single-session designs. That is the price of shorter and steadier completion times.
• Pass-through saves tokens, not time. Without it, the Router made about 30% more decisions and token use rose about 37%, but task times did not change.

Router stress test: batching gets cheaper under load

The second test ran only the Router on a real model, with mock Workers. The rate of Triggers that need a decision went from about 1 to about 40 per minute. Events that arrive during one inference turn queue up and go into the next call together.

DeepSeek Router batching results: batch size rises from 1.0 to 2.8 while time per request grows only from 2.5 to 3.9 seconds, so time per decision falls from 6.4 to 1.6 seconds

Figure: DeepSeek Harness team.

Average batch size rose from 1.0 to 2.8. Time per request grew only from 2.5 s to 3.9 s, because merged Triggers are computed in parallel during prefill. So the amortized time per decision fell from 6.4 s to 1.6 s. A single Router gets more efficient as load rises, up to the context and accuracy limit. DeepSeek's conclusion: at its team size, there is no need to shard the Router "at the cost of global context continuity."

What can you copy into your own agent setup today?

You do not need DeepSeek Harness to use most of these ideas. Here is how they map to common setups:

A starting prompt for a Router-style main session in any harness:

You are the coordinator. You do not run commands or edit files.
For each new request, start a separate worker with a short task brief.
Send follow-ups on the same PR or thread to the worker that owns it.
In chat, reply in under 100 words. Ask only when a decision is needed.

Our top 10 agent harnesses ranking shows which harnesses can run subagents in the background, which is the minimum you need for this pattern.

What is still unsolved?

DeepSeek lists four open problems, and they are honest ones.

• Scaling. When to shard the Router, and when Workers should talk directly, is not settled. Long-term memory becomes the main limit after months of operation.
• Product without sessions. If one chat on screen is not one session underneath, how do people see and steer tasks? DeepSeek thinks more work will move into domain tools like GitHub Issues and PRs.
• Context boundaries and A2A. Which teams share one Super-agent, and how separate agents with different permissions talk safely, is open.
• Security and privacy. The event-driven design brings in more untrusted input. If "a server-side intrusion or a prompt injection compromises the Agent Loop, every endpoint device connected to it could be taken over." Credentials can leak even without a breach, so "the agent therefore needs a way to use credentials without ever seeing them."

That last point is the one to plan for before you connect a proactive agent to a public channel. Read our indirect prompt injection explainer first. If you want a guard between the agent and dangerous actions, AgentBeam is the agent security platform from the explainx.ai team that stops AI agents before they take dangerous actions.

How does this compare with other "super agent" harnesses?

The name is not new. ByteDance used "super agent harness" for DeerFlow 2, which is about long research and coding runs on LangGraph. DeepSeek's design is about a different problem: one agent that lives in team channels and runs many unrelated tasks at once. Minimal harnesses like Pi 1 go the other way and keep one durable session simple. DeepSeek's own base, the plugin-first DeepSeek Harness, is what makes this layering practical: the prototype ships as a DeepSeek Harness bundle with separate dsh-superagent-router and dsh-superagent-worker presets.

Summary

DeepSeek's Super-agent article is less a product launch than a systems design note. Its core moves are a Router that only dispatches, Workers that only execute, code filters before model calls, Thread subscriptions for follow-ups, context as a cache, async tools, and a Watchdog that checks progress, not just uptime. The numbers favor it on speed and stability and cost it in tokens. The security section is the part to take most seriously before anyone points one at a public chat.

Related reading

• DeepSeek dsh-superagent-prototype: the proactive GitHub agent
• DeepSeek Harness Desktop: should you switch?
• DeepSeek Harness v0.1: the plugin-first agent stack
• Claude Code subagents and multi-agent workflows
• Multi-agent orchestration patterns
• Claude Managed Agents and multi-agent orchestration
• Proactive agents compared: Claude Duet, OpenAI Dots, Meta Muse, Grok Bot
• Sources: Exploring Super-agent Design on X, dsh-superagent-prototype on GitHub

Figures are from the DeepSeek Harness team's article and are reproduced with attribution. Engagement numbers, star counts and feature status are accurate as of November 1, 2026 and may change.