{"slug": "deepseek-super-agent-design-router-workers-triggers-and-a-watchdog-explained", "title": "DeepSeek Super-agent Design: Router, Workers, Triggers and a Watchdog Explained", "summary": "DeepSeek's Harness team published \"Exploring Super-agent Design: Towards a More Autonomous Agent System\" on November 1, 2026, a machine-translated Chinese design article describing a five-module architecture in which a long-lived Router session handles all human interaction and dispatch while isolated Worker sessions each run one task, driven by Triggers such as chat messages, PR comments, CI results and emails. In DeepSeek's synthetic test the design cut task latency to a p50 of 12.4 minutes versus 20.4 minutes for a single session and a p95 of 15.7 versus 29.5 minutes, at the cost of more tokens — 23.2 million cache-read tokens per run versus 6.1 million to 10.8 million. The article drew about 82,700 views and 1,600 likes in its first hours on X, and the accompanying MIT-licensed dsh-superagent-prototype research repo grew to about 5,400 stars; the authors state a person can usually follow only 3 to 5 active sessions at once and flag security around untrusted events as the biggest open problem.", "body_md": "On November 1, 2026, the DeepSeek Harness team published [Exploring Super-agent Design: Towards a More Autonomous Agent System](https://x.com/DeepSeekHarness/status/2116857257245987236?ref=explainx), a machine-translated version of a Chinese design article. It is the paper behind the [dsh-superagent-prototype repo we covered yesterday](https://explainx.ai/blog/deepseek-dsh-superagent-prototype-proactive-github-coding-agent-tickets-mandates-mit-2026). 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.\n\nThe 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](https://explainx.ai/blog/claude-code-subagents-multi-agent-workflows-2026) or your own harness today.\n\n## TL;DR: what people are asking\n\n| Question | Short answer | \n|---|---|\n| Is this a new DeepSeek product? | No. The article says it \"discusses architectural ideas\" and is \"not an introduction to existing features of DeepSeek Harness\" | \n| What is the core idea? | A long-lived **Router** session handles all human talk and dispatch; isolated**Worker** sessions run one task each | \n| What drives the agent? | **Triggers** : chat messages, PR comments, CI results, emails. Not typed prompts | \n| Did it beat a single session? | In DeepSeek's synthetic test: p50 12.4 min vs 20.4 min, p95 15.7 vs 29.5 | \n| What does it cost? | More tokens: 23.2M cache-read tokens per run vs 6.1M to 10.8M | \n| Can I run it? | Partly, through the MIT [dsh-superagent-prototype](https://github.com/deepseek-ai/dsh-superagent-prototype?ref=explainx) bundle. It is a research prototype | \n| Biggest open problem | Security: untrusted events in, cloud loop controlling your machines out | \n\n## What is a Super-agent?\n\nDeepSeek defines a [Super-agent](https://explainx.ai/dictionary/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:\n\n- **Continuous.** It always feels like one agent. Ask for Plan A in chat, switch to Plan B in a PR comment, and it follows.\n- **Productive.** It runs several complex tasks in parallel and takes new instructions before old ones finish.\n- **Proactive.** It watches its environment, acts on what is worth handling, \"and stays quiet otherwise.\"\n- **Persistent.** It stays online, connects to real work environments and recovers from failures by itself.\n\nThe 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.\n\nDeepSeek Super-agent carrying one font-settings task from an IM group chat into a GitHub pull request review and back\n\n*Figure: DeepSeek Harness team, \"Exploring Super-agent Design\".*\n\nThe 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](https://explainx.ai/blog/what-is-openclaw-personal-ai-assistant-guide-2026) or a [proactive agent](https://explainx.ai/blog/claude-duet-vs-openai-dots-vs-meta-muse-vs-grok-bot-proactive-agents-2026) for a few weeks, you have likely hit all three.\n\nThe whole design is five modules, numbered in the overview diagram:\n\nDeepSeek Super-agent architecture overview: event triggers, two-stage filter, Router layer, Worker sessions, session database, environments and Watchdog\n\n*Figure: DeepSeek Harness team. Numbers match the article's sections 2 to 6.*\n\n| Module | Section | What it gives you | \n|---|---|---|\n| Two-level architecture (Router + Workers) | 2 | Continuity and parallel throughput together | \n| Event-driven Triggers | 3 | Proactive behavior without step-by-step prompts | \n| Full-duplex multi-channel interaction | 4 | Talk while tools run; right tone per channel | \n| Separate compute, state and environments | 5 | Always online; reach machines that sleep | \n| Watchdog | 6 | Self-recovery, including from stuck loops | \n\n## Why not one big session or one session per task?\n\nThis 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.\n\nThe two-level split takes the good half of each:\n\nTwo-level Super-agent architecture with one Router layer for routing and external interaction and several isolated Worker sessions running tasks in parallel\n\n*Figure: DeepSeek Harness team.*\n\nThe 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.\n\n### The Router layer: dispatch, never execute\n\nThe 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.\"\n\nDeepSeek 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](https://explainx.ai/blog/multi-agent-orchestration-patterns-guide-2026).\n\n### The Worker layer: isolated, strongest model, never talks to people\n\nEach 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.\n\nWorkers 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.\n\n## How do Triggers make the agent proactive?\n\nThe 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.\n\n### 1. Filter first, with code before the model\n\nReal 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.\n\n- **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\".\n- **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.\n\nDeepSeek Super-agent two-stage event filtering: programmatic fast-path rules drop most messages before semantic slow-path policies judge the rest\n\n*Figure: DeepSeek Harness team.*\n\nThis 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.\n\n### 2. Route follow-ups by Thread, not through the Router\n\nConsecutive 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:\n\n- **Subscribed (fast path):** code passes new events in that Thread straight to the Worker. No Router decision.\n- **Unsubscribed (slow path):** the Router still sees every event, but only evaluates events with no subscriber yet.\n\nDeepSeek 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\n\n*Figure: DeepSeek Harness team.*\n\nSubscriptions 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.\n\nTry the trade-off yourself. Toggle the design, then step through twelve events and watch how many model decisions the coordinating session makes.\n\n### 3. Treat the context window as a cache: Inline, Spill, Chain of Recall\n\nDeepSeek 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.\"\n\nIn 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.\n\nThe 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.\n\nDeepSeek Chain of Recall: each recalled object inlines the IDs of next-hop objects so the Router can expand context hop by hop\n\n*Figure: DeepSeek Harness team.*\n\nIf you have built memory for [Claude Code](https://explainx.ai/blog/claude-mem-persistent-memory-claude-code-hooks-sqlite-chroma-github-trending-guide-2026) or a [shared markdown wiki between agents](https://explainx.ai/blog/ai-memory-akitaonrails-shared-memory-claude-code-codex-handoff-markdown-wiki-guide-2026), this is the same idea with stricter rules: every object carries pointers to its neighbors.\n\n### 4. Act ahead: speculative execution\n\nThe 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.\n\n## What is full-duplex interaction?\n\nIn 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.\n\nClassic versus asynchronous ReAct loop in DeepSeek Super-agent: an async start call returns immediately so the session keeps answering while background tools run\n\n*Figure: DeepSeek Harness team.*\n\nNew 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](https://explainx.ai/blog/loop-engineering-coding-agents-claude-code-guide-2026) covers why blocking tool calls hurt long agent runs.\n\n### Different channels need different replies\n\nTool logs that suit a terminal will flood a group chat. DeepSeek sets rules by channel:\n\n| Channel | Rule | \n|---|---|\n| IM and group chat | Light, few interruptions, direct questions, short conclusions. Hard cap of **100 words per reply** | \n| GitHub, email, docs | Structured and dense: full background, change description and verification results in PRs | \n\nThe 100-word cap is another rule you can add to any chat-facing bot today.\n\n## How does it stay online when your laptop sleeps?\n\nLocal 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.\n\n1. **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.\n2. **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.\"\n\nDeepSeek Super-agent compute-storage separation: the cloud Agent Loop is separate from persistent session state and reaches execution environments through endpoint daemons\n\n*Figure: DeepSeek Harness team.*\n\nThe 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](https://explainx.ai/blog/anthropic-claude-managed-agents-dreaming-multiagent-orchestration-2026). 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.\n\n## What does the Watchdog do?\n\nMany 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.\n\nDeepSeek'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](https://explainx.ai/blog/multi-agent-error-propagation-patterns-2026) explains why one stuck Worker can spread bad state if nothing watches it.\n\n## Did it actually work? The experiments\n\nDeepSeek ran two tests on synthetic workloads. The authors say \"the results below are indicative only.\"\n\n### End-to-end: four designs, five runs each\n\nEach 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.\n\n| Design | Task time p50 / p95 (min) | Cache-read tokens per run | \n|---|---|---|\n| Super-agent | 12.4 / 15.7 | 23.2M | \n| Super-agent without pass-through | 12.6 / 15.5 | 31.8M | \n| Single session + subagent tool, neutral prompt | 20.4 / 29.5 | 6.1M | \n| Single session + subagent tool, delegation-first prompt | 13.8 / 29.0 | 10.8M | \n\nCumulative work requests and completions for Super-agent, Super-agent without pass-through and two single-session designs, mean of 5 runs\n\n*Figure: DeepSeek Harness team, ablation study.*\n\nThree findings stand out:\n\n- **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.\n- **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.\n- **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.\n\n### Router stress test: batching gets cheaper under load\n\nThe 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.\n\nDeepSeek 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\n\n*Figure: DeepSeek Harness team.*\n\nAverage 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.\"\n\n## What can you copy into your own agent setup today?\n\nYou do not need DeepSeek Harness to use most of these ideas. Here is how they map to common setups:\n\n| Idea | How to apply it now | \n|---|---|\n| Router never executes | Give your main agent no shell tool; force all work through subagents | \n| Workers report, Router replies | Only one session posts to Slack, Discord or GitHub | \n| Fast-path filter | Allowlists and per-channel modes in code before any model call | \n| Thread subscriptions | Key work by PR number or chat thread ID; send follow-ups to the same worker | \n| Inline and Spill | Short summaries plus IDs in prompts; a tool to fetch the full object | \n| Async tools | Move shell commands over a few seconds to background jobs | \n| 100-word chat cap | One line in the system prompt for chat channels | \n| Watchdog | A scheduled job that reads worker progress and flags stalls | \n\nA starting prompt for a Router-style main session in any harness:\n\n```\nYou are the coordinator. You do not run commands or edit files.\nFor each new request, start a separate worker with a short task brief.\nSend follow-ups on the same PR or thread to the worker that owns it.\nIn chat, reply in under 100 words. Ask only when a decision is needed.\n```\n\nOur [top 10 agent harnesses ranking](https://explainx.ai/blog/top-10-open-closed-source-agent-harnesses-2026) shows which harnesses can run subagents in the background, which is the minimum you need for this pattern.\n\n## What is still unsolved?\n\nDeepSeek lists four open problems, and they are honest ones.\n\n- **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.\n- **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.\n- **Context boundaries and A2A.** Which teams share one Super-agent, and how separate agents with different permissions talk safely, is open.\n- **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.\"\n\nThat last point is the one to plan for before you connect a proactive agent to a public channel. Read our [indirect prompt injection explainer](https://explainx.ai/blog/what-is-indirect-prompt-injection-ai-agents-guide-2026) first. If you want a guard between the agent and dangerous actions, [AgentBeam](https://agentbeam.com/?ref=explainx) is the agent security platform from the explainx.ai team that stops AI agents before they take dangerous actions.\n\n## How does this compare with other \"super agent\" harnesses?\n\nThe name is not new. ByteDance used \"super agent harness\" for [DeerFlow 2](https://explainx.ai/blog/bytedance-deerflow-2-super-agent-harness-langgraph-2026), 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](https://explainx.ai/blog/earendil-pi-1-durable-minimal-harness-2026) go the other way and keep one durable session simple. DeepSeek's own base, the plugin-first [DeepSeek Harness](https://explainx.ai/blog/deepseek-harness-desktop-macos-windows-2026), is what makes this layering practical: the prototype ships as a DeepSeek Harness bundle with separate `dsh-superagent-router` and `dsh-superagent-worker` presets.\n\n## Summary\n\nDeepSeek'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.\n\n## Related reading\n\n*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.*", "url": "https://wpnews.pro/news/deepseek-super-agent-design-router-workers-triggers-and-a-watchdog-explained", "canonical_source": "https://explainx.ai/blog/deepseek-super-agent-architecture-router-worker-triggers-watchdog-2026?utm_source=rss&utm_medium=feed&utm_campaign=blog", "published_at": "2026-11-01 00:00:00+00:00", "updated_at": "2026-11-01 14:21:20.291346+00:00", "lang": "en", "topics": ["ai-agents", "artificial-intelligence", "ai-tools", "ai-research"], "entities": ["DeepSeek", "DeepSeek Harness", "dsh-superagent-prototype", "X", "GitHub"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/deepseek-super-agent-design-router-workers-triggers-and-a-watchdog-explained", "markdown": "https://wpnews.pro/news/deepseek-super-agent-design-router-workers-triggers-and-a-watchdog-explained.md", "text": "https://wpnews.pro/news/deepseek-super-agent-design-router-workers-triggers-and-a-watchdog-explained.txt", "jsonld": "https://wpnews.pro/news/deepseek-super-agent-design-router-workers-triggers-and-a-watchdog-explained.jsonld"}}