{"slug": "how-to-build-a-super-agent-like-deepseek-s-router-workers-and-triggers-explained", "title": "How to Build a Super-Agent Like DeepSeek's: Router, Workers and Triggers Explained", "summary": "A developer turned DeepSeek Harness's design essay on super-agents into a build guide, outlining a two-layer architecture with a long-lived Router session that handles human interaction and dispatches work to isolated Worker sessions, each running one task with full tools. The design feeds both layers from event Triggers such as chat, GitHub webhooks and CI callbacks, routes follow-ups by Thread, and adds a separate Watchdog session to check progress and errors. The guide notes the architecture is not a shipped DeepSeek feature and that a prototype plugin, dsh-superagent-prototype, is \"not an official DeepSeek product.", "body_md": "To build a super-agent like the one DeepSeek Harness describes, split your agent into two layers: one long-lived **Router** session that talks to humans and dispatches work, and many isolated **Worker** sessions that each run one task with full tools. Feed both from event **Triggers** (chat, GitHub, CI), route follow-ups by **Thread**, and add a separate **Watchdog** that checks on everything.\n\nThis guide turns DeepSeek Harness's design essay, [\"Exploring Super-agent Design\"](https://x.com/DeepSeekHarness/status/2116857257245987236), into a build order. One caveat: the essay describes architecture, not a shipped feature. Parts of it live in a prototype plugin called `dsh-superagent-prototype`, which the authors say is \"not an official DeepSeek product.\" Every code sketch below is illustrative, not DeepSeek's code.\n\nA super-agent is a single, always-online AI teammate that receives events from many channels (chat, pull requests, CI), runs many tasks in parallel in isolated sessions, and replies to people as one consistent identity.\n\nThe problem: agent sessions are isolated, and \"a person can usually follow only 3 to 5 active sessions at once.\" A single task is limited by the model. Multi-tasking is limited by human attention. The super-agent targets the second limit.\n\nIt has four traits:\n\nIf you're new to the harness itself, start with [what DeepSeek Harness is](http://apidog.com/blog/what-is-deepseek-harness?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) and how it [compares with Claude Code](http://apidog.com/blog/deepseek-harness-vs-claude-code?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation).\n\nThe essay has five modules. Here they are with the step where you'd build each:\n\n| Module | What it does | Build step | \n|---|---|---|\n| Two-level architecture | Router dispatches, Workers execute | 1 | \n| Event-driven Triggers | Turn chat, GitHub and CI events into agent input | 2 | \n| Full-duplex, multi-channel | Async tools, channel-aware replies | 4 | \n| Compute, state, environment split | Stateless loop, state in a DB, machines stay put | 5 | \n| Watchdog | Separate session that checks progress and errors | 6 | \n\nThe **Router** is one long-lived session. It handles all human interaction and all dispatch, and it never executes tasks itself. It can run without a Bash tool, and a lighter, cheaper model is enough. When several Triggers arrive during one Router turn, they're batched into the next call: long input, short output, merged in prefill.\n\nEach **Worker** is one isolated session per task. It gets full tools and the strongest model you can afford. It never talks to humans; it reports back to the Router. A Worker can itself use subagents, or be a whole agent team.\n\nDon't confuse this with an agent team. A team lead decomposes one coupled task; the Router only dispatches independent tasks. You can stack them.\n\n``` python\n# Illustrative sketch, not DeepSeek's code\nclass Router:\n    def on_events(self, batch):              # triggers arriving mid-turn are batched\n        plan = self.llm_light.decide(batch)  # dispatch, reply, or ignore\n        for task in plan.new_tasks:\n            Worker.spawn(task, model=\"strongest\", tools=\"all\", report_to=self)\n        for msg in plan.replies:\n            self.channels.send(msg)          # only the Router speaks to humans\n```\n\nEvery input to a super-agent is a Trigger: a chat message, a [GitHub webhook event](https://docs.github.com/en/webhooks/webhook-events-and-payloads), a [Slack Events API](https://docs.slack.dev/apis/events-api/) payload or a CI callback. Most of them shouldn't reach a model at all, so the essay filters in two passes.\n\nYour intake endpoint should acknowledge fast and work later. GitHub's [webhook best practices](https://docs.github.com/en/webhooks/using-webhooks/best-practices-for-using-webhooks) ask you to respond with a 2XX within 10 seconds, which a model call can't promise. Return `202 Accepted`, queue the Trigger, and let the Router pick it up. Our guide to [designing reliable webhooks](http://apidog.com/blog/how-to-design-reliable-webhooks?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) covers retries and idempotency for this layer.\n\nA **Thread** is a run of consecutive events on one PR, one IM topic or one email chain. The Worker created for a Thread's first event subscribes to it. Follow-up events then pass straight to that Worker, with no Router call.\n\nThe mapping is many-to-many. If two Workers touch the same PR, both receive its events, and they can resolve conflicts through the PR itself without messaging each other directly.\n\nSkip this step and you pay: in the essay's experiment, removing pass-through made the Router take about 30% more decisions and raised token use by about 37%.\n\nThe Router can't hold everything, so the essay treats context like a cache:\n\nStable IDs on Triggers, Threads and Workers form a reference graph the authors call a \"Chain of Recall.\" The agent hops from a Trigger to its Thread to the Worker that handled it, which gives it multi-hop recall without a giant prompt.\n\nThen go **full-duplex**. Replace a blocking `run()` tool with async `start()` and `stop()`. `start()` returns \"Started\" right away, and the result arrives later as a new event. That's what lets the agent take your next instruction while the last one is still running. The essay says DeepSeek Harness implements this but doesn't enable it by default.\n\nFinally, make replies **channel-aware**. Their tested rule caps IM replies at 100 words, while GitHub, email and docs get structured, dense write-ups.\n\nIt also enables **speculative execution**: in their user group, a \"silently reproduce and fix\" policy delivers only a confirmed simple fix and otherwise stays quiet.\n\nRun the agent loop in stateless cloud containers and keep session state in a database. Environments stay where they are: each machine runs a lightweight daemon, which the essay calls BYOM (Bring Your Own Machine). A crashed loop restarts anywhere and reloads its state, while repos stay on their machines.\n\nThe essay points to Anthropic's [\"Scaling Managed Agents: Decoupling the brain from the hands\"](https://www.anthropic.com/engineering/managed-agents) as the same idea, aimed at managed sandboxes rather than your own machines.\n\nThe Watchdog is a separate session on a schedule, outside the main system. It handles API errors and asks a model whether each Worker is making progress or drifting. Maintainers can also ask it directly why something failed. Keep it outside the Router's process so a stuck Router can't take its monitor down.\n\nThe authors ran about 300 chat and CI messages containing about 20 work requests, simulated the coding with a timer, and ran each setup 5 times. They call the results \"indicative only.\"\n\n| Setup | p50 (min) | p95 (min) | Cache-read tokens per run | \n|---|---|---|---|\n| Super-agent | 12.4 | 15.7 | 23.2M | \n| Without Thread pass-through | 12.6 | 15.5 | 31.8M | \n| Single session + subagent tool, neutral prompt | 20.4 | 29.5 | 6.1M | \n| Single session, delegation-first prompt | 13.8 | 29.0 | 10.8M | \n\nTwo findings stand out. With a neutral prompt, the single session never delegated in 5 runs, so its p95 was nearly double the super-agent's. A delegation-first prompt fixed the median but not the tail. The super-agent costs more tokens than a single session, so you're trading tokens for latency and attention.\n\nA second test loaded the Router alone. As Triggers rose from 1 to 40 per minute, batch size grew from 1.0 to 2.8 and time per request went from 2.5 s to 3.9 s, while time per decision fell from 6.4 s to 1.6 s. Batching is what keeps a single Router from becoming the bottleneck early.\n\nEvery Trigger starts life as an HTTP request hitting your intake endpoint, so that endpoint is the first thing worth testing. If it drops a PR comment or assigns a new `thread_id` to each event, Thread routing breaks and every follow-up goes back through the Router. Let your coding agent write and run that test with [Apidog CLI](https://apidog.com/apidog-cli/?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation).\n\n```\nnpm install -g apidog-cli@latest\napidog auth login --with-token <YOUR_TOKEN>\nnpx -y skills add https://apidog.com   # pick your agent when prompted\n```\n\nThen give your agent one [REDACTED PROMPT]\n\nIn Apidog project , create POST /triggers/github for a GitHub\n\npull_request_review_comment webhook. Add a test case that sends two\n\ncomments on the same PR and asserts: status 202, a trigger_id in the\n\nbody, and the same thread_id both times. Run it against staging and\n\nsummarize any failures.\n\n```\nThe agent reads each payload schema, validates its JSON, writes the endpoint and the case, and runs it:\n```\n\nbash\n\napidog cli-schema get endpoint-create\n\napidog cli-schema validate endpoint-create --file endpoint.json\n\napidog endpoint create --project  --file endpoint.json\n\napidog cli-schema get test-case-create\n\napidog cli-schema validate test-case-create --file case.json\n\napidog test-case create --project  --file case.json\n\napidog run --test-case  --project  -e  -r cli,json\n\n```\nThe same `apidog run` call with `-r junit` drops into your pipeline; see [Apidog CLI in CI/CD](http://apidog.com/blog/apidog-cli-ci-cd-pipeline?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation). If your agent is DeepSeek Harness itself, follow [this setup guide](http://apidog.com/blog/apidog-cli-in-deepseek-harness?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation); for Claude Code, use [this one](http://apidog.com/blog/apidog-cli-in-claude-code?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation). Apidog's Free plan covers up to 4 users.\n\n## Open problems\n\nThe essay lists what isn't solved:\n\n- **Scaling the Router** and choosing a Worker topology as load grows.\n- **Long-term memory** beyond the Chain of Recall.\n- **UX without sessions:** steering an agent with no single chat window.\n- **Context boundaries and agent-to-agent protocols**, where [A2A](http://apidog.com/blog/what-is-agent2agent-a2a?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) is one candidate.\n- **Security.** A prompt injection that reaches the cloud loop could reach every connected machine, and credentials in context can leak. The authors want agents to use credentials without ever seeing them.\n\n## FAQ\n\n**Is the super-agent a DeepSeek Harness feature I can turn on?** No. The essay describes architecture. Parts exist in the `dsh-superagent-prototype` plugin, which the authors say is not an official DeepSeek product. Full-duplex tools are implemented but off by default.\n\n**Why does the Router use a lighter model?** It only dispatches and talks to people; it never executes tasks or needs Bash. Workers do the heavy reasoning with the strongest model.\n\n**How is a super-agent different from an agent team?** A team lead splits one coupled task into parts. The Router dispatches independent tasks. A Worker can run its own agent team inside the super-agent.\n\n**What is Thread pass-through?** Follow-up events on a PR, IM topic or email chain go straight to the Worker that owns that Thread, skipping the Router. Removing it raised token use by about 37% in their test.\n\n**Does a super-agent save tokens?** Not against a single session. It used 23.2M cache-read tokens per run versus 6.1M to 10.8M, in exchange for a p95 of 15.7 minutes instead of about 29.\n```\n\n", "url": "https://wpnews.pro/news/how-to-build-a-super-agent-like-deepseek-s-router-workers-and-triggers-explained", "canonical_source": "https://dev.to/hassann/how-to-build-a-super-agent-like-deepseeks-router-workers-and-triggers-explained-5d18", "published_at": "2026-11-04 06:41:52+00:00", "updated_at": "2026-11-04 06:52:23.446954+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "large-language-models", "developer-tools"], "entities": ["DeepSeek", "DeepSeek Harness", "GitHub", "Slack", "dsh-superagent-prototype", "Claude Code"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/how-to-build-a-super-agent-like-deepseek-s-router-workers-and-triggers-explained", "markdown": "https://wpnews.pro/news/how-to-build-a-super-agent-like-deepseek-s-router-workers-and-triggers-explained.md", "text": "https://wpnews.pro/news/how-to-build-a-super-agent-like-deepseek-s-router-workers-and-triggers-explained.txt", "jsonld": "https://wpnews.pro/news/how-to-build-a-super-agent-like-deepseek-s-router-workers-and-triggers-explained.jsonld"}}