How to Build a Super-Agent Like DeepSeek's: Router, Workers and Triggers Explained

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.

Try Apidog today

This guide turns DeepSeek Harness's design essay, "Exploring Super-agent Design", 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.

What is a super-agent?

A 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.

The 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.

It has four traits:

• Continuous: one agent across IM and GitHub. You discuss Plan A in chat, switch to Plan B in a PR comment, and it follows.
• Productive: it runs tasks in parallel and takes your next instruction before the last one finishes.
• Proactive: it watches events and stays quiet unless something needs it.
• Persistent: it's always online and recovers on its own.

If you're new to the harness itself, start with what DeepSeek Harness is and how it compares with Claude Code.

Super-agent architecture: the five modules

The essay has five modules. Here they are with the step where you'd build each:

Step 1: Split the Router from the Workers

The 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.

Each 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.

Don't confuse this with an agent team. A team lead decomposes one coupled task; the Router only dispatches independent tasks. You can stack them.

# Illustrative sketch, not DeepSeek's code class Router: def on_events(self, batch): # triggers arriving mid-turn are batched  plan = self.llm_light.decide(batch) # dispatch, reply, or ignore  for task in plan.new_tasks: Worker.spawn(task, model="strongest", tools="all", report_to=self) for msg in plan.replies: self.channels.send(msg) # only the Router speaks to humans 

Step 2: Turn events into Triggers

Every input to a super-agent is a Trigger: a chat message, a GitHub webhook event, a Slack Events API payload or a CI callback. Most of them shouldn't reach a model at all, so the essay filters in two passes.

1. Fast path, in code. Filter by source, group, and user or bot allowlists. Each source gets a mode: "respond only to explicit requests," "candidate," or "ignore."
2. Slow path, with an LLM. Candidates go to a model that applies policies written as prompts, such as "reply when someone reports a bug in this channel."

Your intake endpoint should acknowledge fast and work later. GitHub's webhook best practices 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 covers retries and idempotency for this layer.

Step 3: Route follow-ups by Thread

A 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.

The 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.

Skip 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%.

Step 4: Treat context as a cache and make tools async

The Router can't hold everything, so the essay treats context like a cache:

• Inline what's likely needed: IDs, short summaries, neighboring messages.
• Spill the rest: truncate it and leave a pointer the agent can follow.

Stable 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.

Then 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.

Finally, make replies channel-aware. Their tested rule caps IM replies at 100 words, while GitHub, email and docs get structured, dense write-ups.

It also enables speculative execution: in their user group, a "silently reproduce and fix" policy delivers only a confirmed simple fix and otherwise stays quiet.

Step 5: Separate compute, state and environments

Run 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.

The essay points to Anthropic's "Scaling Managed Agents: Decoupling the brain from the hands" as the same idea, aimed at managed sandboxes rather than your own machines.

Step 6: Add a Watchdog

The 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.

What the experiments showed

The 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."

Two 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.

A 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.

Test your Trigger intake with Apidog CLI

Every 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.

npm install -g apidog-cli@latest apidog auth login --with-token <YOUR_TOKEN> npx -y skills add https://apidog.com # pick your agent when prompted 

Then give your agent one [REDACTED PROMPT]
In Apidog project , create POST /triggers/github for a GitHub
pull_request_review_comment webhook. Add a test case that sends two
comments on the same PR and asserts: status 202, a trigger_id in the
body, and the same thread_id both times. Run it against staging and
summarize any failures.

 The agent reads each payload schema, validates its JSON, writes the endpoint and the case, and runs it: 

bash
apidog cli-schema get endpoint-create
apidog cli-schema validate endpoint-create --file endpoint.json
apidog endpoint create --project --file endpoint.json
apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project --file case.json
apidog run --test-case --project -e -r cli,json

 The 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. ## Open problems The essay lists what isn't solved: - **Scaling the Router** and choosing a Worker topology as load grows. - **Long-term memory** beyond the Chain of Recall. - **UX without sessions:** steering an agent with no single chat window. - **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. - **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. ## FAQ **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. **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. **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. **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. **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.