DeepSeek Harness's "Super-agent" design: a Router with no Bash, and a single-session agent that never delegated

The DeepSeek Harness team has published a long design essay, "Exploring Super-agent Design: Towards a More Autonomous Agent System", as an X article on November 1, along with an MIT-licensed reference implementation, deepseek-ai/dsh-superagent-prototype. The article was written by Yujia Qiao, who also implemented the system, with review from more than a dozen colleagues on the team. It is explicitly not a feature announcement: DeepSeek says it describes architectural ideas, and the repository's README calls the code a research prototype, "not an official DeepSeek product", adapted for publication and not identical to the internal version.

The problem it starts from is one anyone running several coding agents at once will recognize. Agents still treat a single session as the unit of work, and sessions don't know about each other. In the team's experience a person can follow only three to five active sessions at a time. "A single task is limited by model capability, but multi-tasking is limited by human attention," the article says. Bolting MCP servers or chat connectors onto a local single-session agent doesn't fix that: it still blocks on long operations, mixes contexts from different tasks and stops when the laptop sleeps.

Two levels, and the top one has no Bash

The answer is a "Super-agent": one continuous agent that people talk to wherever they already work (an IM group, a GitHub pull request), split into two layers.

• A long-lived Router session receives every human message and every event, keeps the global picture and dispatches work. It deliberately does not execute tasks, and "can run without a Bash tool at all". DeepSeek says a lighter model is usually enough for it.
• Worker sessions each own one task with an isolated context and a full tool set. They never talk to humans directly; they report to the Router, which does all the replying. Workers usually need the most capable model.

The article is careful to separate this from the familiar "agent team" pattern, where a lead agent decomposes one task and coordinates roles. Here the Router doesn't break tasks down at all; it only routes independent ones and tracks how they relate.

The rest of the design borrows openly from systems engineering. Incoming events (chat messages, emails, CI results, review comments) pass a cheap code-based "fast path" filter by source and allowlist before any model sees them, and only candidates reach the LLM "slow path". Once a Worker owns a GitHub thread or chat topic, it subscribes to it and follow-up events go straight to it without a Router decision. Context is handled as a cache with "Inline & Spill": inline what is likely to be needed (IDs, the first 50 characters of a message, neighboring comments), truncate the rest and leave a pointer. Linking every object by ID gives what the team calls "Chain of Recall", multi-hop lookup through a reference graph. Long tool calls become asynchronous start()/stop() pairs so the conversation never blocks; DeepSeek notes that DeepSeek Harness already implements this but it is "not yet enabled by default". An external Watchdog session checks not just whether processes are alive but whether Workers are making progress or drifting.

There is also some speculative execution. In DeepSeek's internal Harness user group the agent runs a "silently reproduce and fix" policy: when someone reports a problem, it tries to reproduce it and find a fix in the background, and delivers a result only after it has confirmed the issue and found a simple fix. For chat channels the team names one hard rule it has verified: a cap of 100 words per reply.

The interesting result: the model wouldn't delegate

The essay includes two small experiments, which DeepSeek itself calls "indicative only": synthetic workloads, and coding work simulated by a tool that just consumes time, so what is measured is scheduling, not coding ability.

In the first, four designs each handled a stream of about 300 group-chat and CI messages, roughly 20 of them real work requests, five runs each. The Super-agent finished tasks in 12.4 minutes at the median and 15.7 minutes at p95. The comparison was a single session with a subagent tool, and here the detail is better than the headline. With a neutral prompt ("Use a subagent for a piece of work when appropriate..."), the model did not call a subagent in any of the five runs; it did everything itself, kept being interrupted by new messages, and p95 reached 29.5 minutes. With a prompt that told it to prefer handing each piece of work to a subagent, it delegated in four of five runs; in the fifth it judged the work "small" and did it itself, producing the long tail.

That is the real argument for the architecture. Whether a single-session agent delegates is left to prompt engineering and the model's judgment on the spot; a Router without execution tools can't make that mistake. The article doesn't name the models used in these runs, which limits how far the result travels.

The subscription pass-through earns its place on cost rather than speed. Turning it off left completion times about the same, but the Router made about 30% more decisions per run and total cache-read tokens rose from 23.2M to 31.8M, about 37% more.

The second test stressed the Router alone, with a real model on the Router and mocked Workers. As the rate of events needing a decision rose from about 1 to about 40 per minute, events queued during one inference turn were merged into the next call: average batch size went from 1.0 to 2.8, time per request only from 2.5 s to 3.9 s, and amortized time per decision fell from 6.4 s to 1.6 s. Router steps are long input and short output, and triggers merged into one call are processed in parallel during prefill. DeepSeek's conclusion is that at its current team size one Router session is enough, and there is no need to shard it "prematurely at the cost of global context continuity".

What's left open

The compute/state/environment split puts the agent loop in the cloud and a thin, stateless daemon on each machine it works on, including people's own laptops ("Bring Your Own Machine"). The article compares this with Anthropic's "Decoupling the brain from the hands" design, which targets managed sandboxes and customer VPCs rather than personal machines that are online only some of the time.

It is also where the article is most candid about risk. An event-driven agent takes in a lot more untrusted input, and the design "implicitly assumes that the cloud and the endpoints trust each other". In the authors' words: "If a server-side intrusion or a prompt injection compromises the Agent Loop, every endpoint device connected to it could be taken over." Credentials that can enter the model's context can leak during normal operation, so the agent needs a way to use credentials without ever seeing them. The article lists that as an open problem, alongside long-term memory and how separate Super-agents should talk to each other.

For now the prototype is narrower than the essay: a bundle for DeepSeek Harness that acts as a proactive coding agent for one GitHub repository, optionally listening to Feishu, with a web panel for things that need a person. Its README says much of it was written by coding agents, and setup is meant to be done by asking your own coding agent to read SETUP.md. The repository passed 6,900 stars in its first two days.