DeepSeek's super-agent: one Router, many Workers — p95 15.7 min vs 29.5 for a single session, and the 37% token cost of direct delivery

On October 31 the DeepSeek Harness team published a design essay, "Exploring Super-agent Design: Towards a More Autonomous Agent System," and open-sourced dsh-superagent-prototype, an MIT-licensed coding agent that treats the session as an implementation detail: a resident Router handles people and dispatch while isolated Workers execute tasks in parallel. In DeepSeek's synthetic scheduling test the architecture finished requests at p95 in 15.7 minutes versus 29.5 for a single-session agent — a win bought with roughly 4× cache-read tokens and a security model that explicitly trusts the operator's machine.

What shipped

The release is two things. First, a Chinese design essay by Yujia Qiao of the Harness team, published on DeepSeek's WeChat account the evening of October 31, arguing that mainstream agents are capped by human attention rather than model capability. Second, the dsh-superagent-prototype repository: TypeScript, MIT-licensed, created the same day, and at about 8,500 stars within two days (GitHub API). The README is upfront about what it is: "Research prototype for reference only, not an official DeepSeek product," with "much of the engineering done by coding agents."

The prototype itself is narrow — a proactive coding agent for one GitHub repository, with Feishu as an optional chat source, a web panel that lists only what needs a person, and setup driven by a SETUP.md that your own coding agent walks through. Unrequested work starts in an observe mode that only records what the agent would have done (philosophy doc). The essay is the interesting part.

The essay defines four properties a "super-agent" needs — Continuous, Efficient, Proactive, Persistent — and argues a single ReAct loop cannot deliver all four at once. Its proposed architecture borrows directly from computer systems: scheduling, caching, storage-compute separation, watchdog. The core move is a two-layer split: a resident Router layer handles all human interaction and task dispatch, and a Worker layer of context-isolated sessions does the actual execution. The Router is deliberately thin — it "may not even have a Bash tool," and a lighter model is often enough — while Workers carry the full tool set and the strongest model. DeepSeek's argument is that a session should be "an implementation detail of the system, not a cognitive burden for the user."

Around that split sit the other modules: an event-driven layer that turns chat messages, review comments and CI results into triggers, filtered twice (a fast program-level screen, then a semantic judgment by the model); thread subscriptions so follow-ups to a task go straight to the Worker that owns it instead of round-tripping through the Router; "Inline & Spill" context organization; background speculative execution. Compute, state and environment are separated: the loop runs in the cloud, state lives in a database, and a small daemon executes commands on the operator's machine. An external Watchdog session checks that Workers are making real progress (aibase summary, CellCog).

The numbers come from a preliminary experiment in the essay: a synthetic stream of about 300 group-chat and CI messages per run, about 20 of them real work requests, five runs per setup, with coding replaced by a tool that only consumes time — so it measures scheduling, not code quality.

Setup	p50	p95	Cache-read tokens
Super-agent	12.4 min	15.7 min	23.23 M
Super-agent without direct delivery	12.6 min	15.5 min	31.77 M
Single session + subagents, neutral prompt	20.4 min	29.5 min	6.05 M
Single session + subagents, delegation-first prompt	13.8 min	29.0 min	10.82 M

The single-session baseline is the telling row: with a neutral prompt the agent never delegated in five runs and kept getting interrupted by incoming messages; with a delegation-first prompt it delegated in four of five runs but still hit a 29-minute p95. Removing direct delivery (follow-ups no longer skip the Router) barely changed completion times but raised cache-read tokens from 23.23 M to 31.77 M — about 37% — and added roughly 30% more Router decisions (CellCog).

Why it matters

The essay's premise is that human attention, not the model, is the multitasking ceiling: "a person can usually follow only three to five active sessions at once," and "the ceiling of a single task is set by model capability, and the ceiling of multitasking is set by human attention" (translation). Anyone who has run a coding agent knows the failure mode: every new message interrupts the session doing the work, and delegation is a judgment call the model makes from the prompt.

The Super-agent design removes that judgment call structurally. The Router cannot do the work — it has no shell — so there is nothing to decide; requests simply go to an isolated Worker. That is why the p95 tail collapses: the long tail in the single-session runs came from the model occasionally judging a task "too small to hand off" and doing it alone while new messages piled up (CellCog).

The second transferable idea is the batching result. Triggers that arrive while the Router is thinking pile up and are merged into the next LLM call; because the merged backlog is computed in parallel during prefill, per-decision inference time falls as load rises — from about 6.4 seconds per decision at ~1 trigger/minute to 1.6 seconds at ~40 triggers/minute, with an average batch of 2.8 (CellCog, aibase). The Router does only light dispatch with long input and short output, which is exactly the shape that amortizes well.

The honest framing, which DeepSeek mostly keeps, is that this is a scheduling trade-off, not a free lunch. The p95 win costs roughly 4× the cache-read tokens of a non-delegating single session (23.23 M vs 6.05 M), because every Worker re-reads its own context. The essay's own open problems — scaling past one Router session, what interaction looks like once sessions disappear from the screen, context boundaries between agent instances, and security — read like a systems research agenda, which is the point: treating agent coordination as a systems problem with a vocabulary (scheduling, caching, watchdogs) that engineers already have.

Caveats

• The prototype is not the essay. The README says some designs in the article "are directions for future development and are not implemented in this prototype." What shipped is a single-repo coding agent, not the full five-module architecture.
• The numbers are vendor-reported and synthetic. Coding was replaced with a time-consuming tool, so the experiment measures scheduling and coordination, not code quality or real-world cost. Five runs per setup, labelled "preliminary" by DeepSeek itself. Three independent summaries of the essay (offloop, CellCog, aibase) report the same figures; none of them reports an independent reproduction of the experiment.
• The security model is "trust the operator's machine." The deployment docs are explicit: both presets run with danger-full-access as the operator's OS user, and a worker "can execute programs by path and read the operator's home directory" (006-deployment.md). The management API authenticates with a documented static header (x-orchestrator-request: 1) plus a localhost check — any local process that knows the header value gets panel permissions. The essay itself concedes that if the cloud loop is compromised, every machine connected to it is at risk (CellCog).
• There is no official English version. The essay is Chinese-only; the English translation used here is AI-generated and unreviewed, so treat specific wording as approximate.

Sources

• dsh-superagent-prototype (GitHub)
• Repo metadata: license, stars, dates (GitHub API)
• Original essay, WeChat (Chinese)
• Unofficial English translation of the essay
• Offloop: DeepSeek Harness — New Infra for Super Agents
• CellCog: DeepSeek's Super-agent — One Router, Many Workers
• AIBase news summary
• docs/006-deployment.md (security and execution model)
• docs/000-philosophy.md