DeepSeek's Super-agent: A Router Above Your Workers, Not Superintelligence
First, the name, so it doesn't scare anyone.
Super-agent is not a "super intelligent agent". Here, "super" means "above" in English, opposite to "sub" (below). You're familiar with subagent, which is a helper hanging under the main Agent. Super-agent is the reverse: it adds a layer above the working Agent, letting the upper layer manage the lower one.
In one sentence: sub is adding minions below; super is adding a supervisor above. It has nothing to do with super intelligence. It's just a positional word.
What it's actually solving
When you use AI, one window at a time goes smoothly. But if you're pushing three or four things at once - fixing a bug here, reviewing code there, a new request popping up in a group chat - you start acting as a supervisor. You switch windows back and forth, keeping track yourself of where each task stands and which bit of feedback hasn't been delivered yet.
DeepSeek says a person can realistically keep track of only 3 to 5 concurrent tasks. Beyond that, the brain explodes.
Their judgment is practical: whether a single task is done well depends on the model's ability; how many things you can do at once depends on human attention. And human attention doesn't get stronger just because models get stronger.
So the logic is direct: take "remembering who's doing what" out of your head and hand it to the system. You only say "what I want" and "yes or no"; the work of assigning tasks and passing messages in between is handled by the AI itself.
The architecture has two layers, like a company
The upper layer is called Router, the supervisor. The lower layer is called Worker, the doer.
The Router is always on, keeping an eye on group chats, GitHub, email, and such. When a message comes in, it decides whether it needs handling, who to hand it to, and dispatches it. It doesn't do the work itself, so a lightweight model is enough.
Workers are one per task, each doing its own thing, invisible to each other. The one fixing a bug doesn't know the one beside it is reviewing code. But the Router knows the whole picture. When a Worker finishes, it reports to the Router, and the Router speaks externally for everyone - otherwise six Workers typing into the group chat at once would be a mess.
One detail matters: when a Worker takes on a GitHub PR, subsequent comments on that PR are sent directly to it, without going back through the Router for re-dispatch. This is called "subscription direct-pass". It sounds like a small optimization, but it's key to saving money. In their experiments, with the direct pass removed, Router decision counts rose by about 30%, and tokens climbed accordingly.
The funniest part: nobody calls it; it finds work on its own
DeepSeek ran an instance internally that lurked in a team group. Over hundreds of messages, it stayed silent more often than not. But one time, someone in the group complained about a double-click bug triggering dozens of times a day. Nobody @-ed it. After a while, a PR appeared in the repo, fixing it, with before-and-after comparison screenshots attached.
That's what they call "silent reproduction and fix". Rules are written in advance: when a likely bug is spotted, try to reproduce it in the background; if the problem is confirmed and a simple fix is found, submit it. If not found, stay quiet and don't report the process.
To keep it from becoming the kind of annoyer that reports on every little thing, the prompt enforces hard rules: any single reply in the group over 100 words is rejected by the sending channel; filler like "I'll handle it" is banned; the auto-review bot's comments are only reference, and each PR gets at most three rounds of replies, to prevent two AIs from being polite to each other into an infinite loop.
The cost of initiative is noise, and noise kills initiative. The sooner people building Agents understand this, the better.
The data looks good, but the accounting has to be clear
They released preliminary data: median task completion time was 12.4 minutes, the 95th percentile was 15.7 minutes. The control group was "single session + subagent tools", with a 95th percentile of 29.5 minutes.
But there's a particularly interesting detail: in the control group, the model was given subagent tools and the prompt said "delegate to subagents when appropriate", and across five runs, the model never once delegated. It did everything itself, got interrupted mid-task by new messages, stacked up an increasingly messy context, and dragged on to nearly half an hour.
What does this tell us? "Whether to divide work" is not something you can leave to a model's on-the-spot judgment; it can't be trusted. The model thinks it can handle it, so it doesn't delegate. That's why super-agent's approach is: division of labor is not decided by the model, but forced by the architecture. The Router only dispatches, the Worker only works. No choice.
The cost is tokens. Read-cache tokens are about four times that of the single-session approach. DeepSeek's own framing is "spend more tokens for shorter and steadier completion times". Whether it's worth it depends on the scenario. Fixing a low-priority small bug may not be worth it; one person overseeing a team's backlog might be.
To be honest
DeepSeek made it clear at the start: this is an engineering-practice-oriented architecture discussion, not a product release. The open-source prototype isn't a button you open to use DeepSeek; it's aimed mainly at a single GitHub repo, and parts of the functionality are still under development.
They also didn't sell it as a new theory. Their words roughly were: move old ideas from computer systems - scheduling, caching, watchdog - onto Agent architecture.
But old ideas, applied in the right place, sometimes work better than new theories. For the past two years, the bottleneck has been on the model side - whether it can understand, whether it can write correctly. Now that individual tasks need less human babysitting, a new ceiling has appeared: how many AIs can you manage at once?
Super-agent's answer is: you don't manage. Let AI manage AI. You handle acceptance.
As for how to do that acceptance, their article didn't fully explain either. That's another problem.