A practical guide to replicating DeepSeek's router/worker super-agent design using Pandaode bots, Claude Pass, and Telegram.
What is a “super agent” and why does it matter now? #
A super agent is a coding agent system built so that one agent feels continuous across every place you talk to it (chat, pull request comments, email) while separate worker sessions do the actual work behind the scenes. The idea comes from a DeepSeek Harness team article called “Exploring Super Agent Design.” Their core observation: coding agents got good enough to work unsupervised, so the bottleneck shifted from model quality to human attention. A person can realistically track three to five active agent sessions before losing track of who’s waiting on what. The fix isn’t a better model, it’s a different structure: a router that talks to people and workers that do the work.
TL;DR #
- DeepSeek’s super agent design splits work into a router layer (one long-lived session that talks to humans and hands out tasks) and aworker layer (isolated sessions that do the actual coding and never talk to people directly).
- Their experiment found that prompting alone doesn’t produce delegation : a single-session agent told to “use a sub-agent when appropriate” never delegated across five runs, while the structural router/worker split delegated reliably and finished tasks faster.
- The design treats incoming messages as filtered events rather than prompts, using cheap rule-based filtering before anything reaches a model, which keeps noisy channels like group chats from flooding the router.
- A cheap router model plus strong worker models makes economic sense because the router handles high volume at low complexity while workers handle the one expensive task that actually needs intelligence.
- You can approximate this today in Pandaode using its “bots” feature, paired withClaude Pass for access to several open models andClaude Desktop for scheduled recurring jobs.
- The official prototype, DSH Super Agent , is published as research code on GitHub, not a finished product, and it executes commands without approval, so it should only run against a test repo or isolated machine.
- Unsolved problems the DeepSeek team names outright include long-term memory decay over months of runtime andprompt injection risk from an agent that reads external events.
Nothing gets lost.
How does the router/worker design actually work? #
The router is a single, long-lived session that talks to people across channels and decides who does what. It doesn’t write code, doesn’t necessarily need a shell tool, and its job is intentionally shallow: track tasks, match events to the right worker, and keep replies short. Because the job is simple, a lighter, cheaper model is usually enough here.
Workers are different. Each one gets a single task, a clean context window, and no ability to talk to the person directly. It only reports back to the router. This is where the capable (and more expensive) model should go, since this is the layer actually writing and fixing code.
This flips the usual instinct of putting your best model on the “lead” agent. In DeepSeek’s design, the router never breaks a task into steps or deeply reasons about the work; it just routes. The heavy lifting, and the heavy model cost, sits downstream.
One detail worth noting: once a worker claims a task, like owning a pull request thread, it subscribes directly to new events on that thread. The router still sees them but doesn’t have to relay anything. If two workers end up on the same pull request, both see the same events and can notice a conflict without the router mediating.
Why do prompts fail at getting agents to delegate? #
DeepSeek ran a small experiment to test this directly. They simulated roughly 300 messages per run, about 20 of which were real work requests (the coding itself was simulated by a tool that just consumed time, so this tested scheduling behavior, not code quality).
A single session given a neutral prompt (“use a sub-agent when appropriate”) never delegated across five runs, and its slowest run took 29.5 minutes. A version of the same single-session setup, given a prompt that pushed hard for delegation, delegated in four of five runs, but in the fifth it decided the task was small and did everything itself anyway. The structured super agent, with the router/worker split enforced architecturally rather than through instructions, completed a typical task in 12.4 minutes on average and 15.7 minutes at the slow end.
The takeaway: you can’t rely on prompt wording to make a model delegate consistently. It has to be baked into the system’s structure, for example by removing the router’s ability to execute commands at all, so it has no choice but to hand work off.
What did the cost and performance numbers show? #
As event volume increased from about 1 to about 40 decisions per minute, the router’s time-per-decision actually dropped, from 6.4 seconds down to 1.6 seconds, because events started batching together. That suggests a single router session can handle a reasonably sized team’s worth of traffic without needing to be split early.
The cost tradeoff shows up in cached tokens. A full super agent run used about 23.2 million cached read tokens, and that number rises to 31.8 million without a pass-through caching system in place. At DeepSeek V4.1 Flash off-peak pricing, those 23.2 million cached tokens cost around $7. At Sonnet 4.5 pricing, the same cached tokens cost around $4.64 for comparison purposes, illustrating how much the router’s model choice matters once you’re running many sessions continuously. This is a big part of why the design leans toward cheap models for the router layer.
How do you build a practical version with Pandaode today? #
Pandaode is a free, open-source desktop app that runs coding agents, including the DeepSeek harness and Claude, in one window. It isn’t a super agent out of the box, but a feature called “bots” gets you most of the way there. A bot is a persistent agent you can message from Telegram, Slack, Discord, WhatsApp, or a local web chat. It keeps its own memory, schedules, and rules, and every conversation is a normal Pandaode task you can open and inspect on your desktop.
To build the router/worker split:
- Create a router bot. Assign it a lightweight model like DeepSeek V4.1 Flash. In its instructions, specify that it only talks to you, hands out work, and keeps chat replies under 100 words.
- Create worker bots. Set up at least one for building and one for reviewing, each on a stronger model.
- Connect bots with the
bot_messagebottool. This lets the router send work into a worker’s own conversation; when the worker finishes, the result flows back to the router as an update. - Add deny rules on the router bot for its shell and edit tools. This is the critical structural step: a prompt telling the router to delegate isn’t enough, per the experiment above. Deny rules remove the option entirely, which mirrors DeepSeek’s own approach of stripping the bash tool from their router.
Panda Code also has a separate feature called “Panda Router,” which is not the same thing as the router described here. Panda Router picks which model to run a task on (escalating to a stronger model if a worker fails); it doesn’t manage multi-channel conversations with humans. For a single big task at your desk, an automatic team with Panda Router makes sense. For an always-on assistant across channels, bots are the better fit.
Where do Claude Pass and Claude Desktop fit in? #
Claude Pass is a $9.99/month plan that gives access to models including Kimi K3.1 Pro, GLM 5.3, Qwen 38 Max, and DeepSeek V4.1 Flash. Running many concurrent sessions makes a single plan covering multiple strong open models more practical than paying per-provider. You can track 5-hour, weekly, and monthly usage limits from the Claude dashboard.
To set it up: install the Claude CLI (npm install -g claude), run claude auth, sign in, and select Claude Pass. Pandaode will detect it automatically so you can assign it to any bot. A reasonable split: Kimi K3.1 Pro on the builder bot (it holds long tasks well), GLM 5.3 on the reviewer (different models catch different mistakes), and the DeepSeek harness (npm install -g @deepseek-ai/dsh, with an API key under provider settings) for the router.
Without shadow IT.
Claude Desktop, a separate open-source app, is better suited to recurring, fixed jobs rather than the router/worker setup. Its schedule page lets you set frequency, prompt, model, and workspace for things like a nightly pull request review or a security scan. It can also import old sessions from Claude Code or Codex and continue them on cheaper models. It still requires you to manage sessions manually, so it doesn’t solve the attention problem by itself. It’s best reserved for work that doesn’t need a router at all.
Is this setup actually like DeepSeek’s design, and is it safe? #
Not fully, and it’s worth being honest about the gaps. Pandaode bots only accept paired senders, so a bot won’t sit in a public group chat and jump in unprompted the way DeepSeek’s design allows. A GitHub comment isn’t a channel a Pandaode bot listens to, so it can’t pick up a plan change from a pull request thread the way their agent does. Each chat thread in Pandaode is its own conversation with shared memory rather than one fully unified context, and the router here depends on instructions and deny rules rather than a dedicated event-filtering and pass-through system.
DeepSeek’s own prototype, DSH Super Agent, is published on GitHub as research code, explicitly not an official product. It watches one GitHub repository (optionally more) and includes a panel showing what needs human attention. Its workers execute commands without approval under your user account, so it should only be run on a separate machine or test repository. Proactive behaviors start in a mode that only logs what the agent would have done, which is a sensible default until you trust the system more.
The team names two unresolved risks directly: long-term memory degradation once a system has run for months, and prompt injection exposure, since an agent reading external events (chat messages, emails, CI output) can be manipulated through those same inputs. If the central loop is compromised, every connected machine is at risk. That’s a reason to avoid connecting any version of this, official or DIY, to a public or untrusted group chat.
Frequently Asked Questions #
What is DeepSeek’s super agent design?
It’s an architecture, described in a DeepSeek Harness team article, that splits a coding agent into a router layer (talks to humans, assigns work) and a worker layer (executes isolated tasks and reports back). The goal is to let one agent feel continuous across chat, code reviews, and other channels without requiring a person to track multiple separate sessions.
Is DSH Super Agent available to use right now?
DeepSeek published a prototype called DSH Super Agent on GitHub, but it’s explicitly labeled research code, not an official product. It can be set up by an agent reading its setup instructions, but its workers run commands without approval, so it should be run on a test machine or repository rather than production.
Can I replicate this without DeepSeek’s prototype?
Yes, approximately. Using Pandaode’s bot feature, you can create a router bot on a cheap model with deny rules blocking shell and edit tools, plus worker bots on stronger models connected via a message-passing tool. It’s a simplified version missing some of DeepSeek’s filtering and subscription mechanics, but it enforces the same router/worker separation.
Why does the router need a cheaper model than the workers?
Without shadow IT.
Every app, approved
✓
✓
✓
✓
✓
The router’s job is intentionally narrow: track tasks and route events, not write code. Workers handle the actual coding, which needs a stronger model. Since the router handles much higher message volume, using a cheap model there significantly reduces cost, an effect DeepSeek quantified by comparing cached token pricing across models.
What’s the biggest risk with this kind of always-on agent system?
Prompt injection. Any agent that reads external events like chat messages or emails is exposed to instructions hidden in that content. DeepSeek flags this directly as unsolved, along with long-term memory degradation over months of continuous operation.