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.
It has four traits:
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:
| Module | What it does | Build step |
|---|---|---|
| Two-level architecture | Router dispatches, Workers execute | 1 |
| Event-driven Triggers | Turn chat, GitHub and CI events into agent input | 2 |
| Full-duplex, multi-channel | Async tools, channel-aware replies | 4 |
| Compute, state, environment split | Stateless loop, state in a DB, machines stay put | 5 |
| Watchdog | Separate session that checks progress and errors | 6 |
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.
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
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."
| Setup | p50 (min) | p95 (min) | Cache-read tokens per run |
|---|---|---|---|
| Super-agent | 12.4 | 15.7 | 23.2M |
| Without Thread pass-through | 12.6 | 15.5 | 31.8M |
| Single session + subagent tool, neutral prompt | 20.4 | 29.5 | 6.1M |
| Single session, delegation-first prompt | 13.8 | 29.0 | 10.8M |
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
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.