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

Posted on Nov 4 • Originally published at apidog.com

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.

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.

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.

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

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

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 Enter fullscreen mode Exit fullscreen mode 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.

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.

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

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

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.

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.

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.

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.

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 Enter fullscreen mode Exit fullscreen mode 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: Enter fullscreen mode Exit fullscreen mode 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