On October 31, the DeepSeek Harness team published a design essay on WeChat, "Exploring Super-agent Design: Towards a More Autonomous Agent System", and open-sourced a runnable reference implementation the same day: deepseek-ai/dsh-superagent-prototype. The repository README states up front that this is a research prototype, not an official DeepSeek product.
The essay opens with a plain observation: a person can typically only keep track of 3 to 5 active sessions at a time. In agent designs built around a single session, the ceiling for one task is set by model capability, while the ceiling for many tasks is set by human attention. Changing your mind over IM, then reviewing a pull request on GitHub, means remembering for yourself what each session said. The proposed fix is to pull sessions out of the user's view and demote them to an implementation detail inside the system.
A two-layer split: Router and Worker
The first design choice is to split the work across two layers. A resident Router layer absorbs human interaction from every entry point, aggregates cross-task information and decisions, and acts as the global ordering point, coordination point, and memory. It does not execute concrete tasks and need not even carry a Bash tool. The team's read is that the Router's job is often less complicated than it looks, and a lighter model usually balances speed and effect well enough.
The Worker layer does the actual work. Each Worker has isolated context, mounts the full set of execution tools, and focuses on a single task; because it directly determines task results and code quality, it usually needs the strongest available model. Workers never block each other, and a Worker can spin up Subagents or be an Agent Team itself while staying transparent to the Router above. The user keeps talking to one assistant while several sessions advance in parallel behind it.
Event-driven: two-stage filtering and direct Thread delivery
The second design choice makes the agent driven by environment events instead of waiting for instructions. Triggers include group chat messages, email and calendar reminders, code review comments, and CI results.
Real group chats are extremely noisy, so the team applies a two-stage filter borrowed from computer systems, the Fast Path / Slow Path split. A programmatic layer checks deterministic conditions first: source, group scope, allowlists. Surviving candidates then go to an LLM that decides whether to act according to a strategy written in the prompt. That semantic layer doubles as a natural-language extension point, so behavior can be switched on and off through prompts at any time.
Consecutive events under one GitHub pull request, one IM topic, or one email chain form a Thread. After the Router creates a Worker from the first event, that Worker subscribes to the Thread and later events are delivered to it directly, no longer passing through the Router. Only events nobody has subscribed to come back for the Router to dispatch. Context is managed like a cache: Inline pulls in information likely to be needed soon, while Spill keeps content that exceeds the budget outside the window as a reference only. Unique IDs on Triggers, Threads, and Workers link these into a reference graph, supporting on-demand multi-hop retrieval.
The ablation: 12.4 minutes against 29.5 minutes
The team's self-reported experiment drives group chat and GitHub CI message streams simultaneously. A single run contains about 300 messages, roughly 20 of which are work requests; coding work is replaced by a tool that only consumes time, so the measurement targets scheduling and collaboration rather than the execution quality of any single task. Message intervals and work durations are scaled to 1/4 while model call latency stays real, and each configuration is repeated five times.
By the team's own numbers in the original essay, Super-agent's task completion time comes out at p50 12.4 minutes and p95 15.7 minutes. In the same ablation table, a single session with the Subagent tool under a neutral prompt reaches p50/p95 of 20.4/29.5 minutes, and under a delegate-first prompt, 13.8/29.0 minutes. The essay explains why: under the neutral prompt the model never invoked a Subagent across five runs, so all work stayed in the main session and was repeatedly interrupted by new messages. After switching to delegate-first prompting, four of five runs delegated, and the one run where the model judged the work "small" and did it itself produced the p95 long tail.
The authors themselves label these results preliminary reference only: the load is synthetic, the environment is simplified, and each configuration ran five times.
The bill arrives on the same table
The same table lists the other half of the ledger. Super-agent reads more cache tokens per run than the single-session setups; the essay gives only the direction, while a third-party reconstruction of the same ablation table puts Super-agent at 23.23M tokens against 6.05M and 10.82M for the two single-session prompt configurations. Removing the Thread direct-delivery mechanism barely changes completion time, but the Router has to make about 30 percent more decisions and total read-cache tokens rise from 23.23M to 31.77M, roughly 37 percent more. Direct delivery does not speed anything up or improve quality; it simply saves the Router tokens and inference overhead.
The Router has a batching layer of its own. The team's data: as the arrival rate of Triggers needing a decision climbs from about 1 per minute to about 40 per minute, average batch size grows from 1.0 to 2.8 while per-request latency rises only from 2.5 seconds to 3.9 seconds, so inference time amortized per decision falls from 6.4 seconds to 1.6 seconds. On that basis the team concludes one resident Router suffices at their current team size, with no horizontal partitioning needed yet.
What the open prototype gives you
The repository is MIT licensed and written in TypeScript, positioned as a proactive coding agent scoped to a single repository per deployment. It listens to GitHub events and can optionally connect to Feishu. An incoming request becomes a work item, executes in its own session and directory, and returns to the original conversation with a usable result such as a pull request; a web panel lists only the items still waiting on a human, and in a healthy deployment that panel can stay empty. The repository reports 4.1k stars and 375 forks.
The design philosophy is stated plainly: take as little human attention as possible, and give as much value as possible. The rules that follow: act only when named or when a written team rule allows it, stay quiet while working, speak only when someone must decide or can use the result, and ask one concrete question at a time. The disclaimers are equally plain: this is a research prototype and not an official product, much of the engineering was done by coding agents, it may still contain bugs and its style may be inconsistent, and it is not identical to the internal version. Some designs discussed in the essay are not implemented.
Three things left unresolved
Security is the hardest one: the Agent Loop runs in the cloud while only a lightweight daemon stays on the device, a design that assumes the cloud and the endpoint trust each other. Once a cloud Agent Loop is compromised through a server breach or prompt injection, every endpoint it is connected to faces the risk of being controlled. Even without a cloud compromise, credentials entering the model context risk leaking, and the team still needs a mechanism letting the agent use credentials without ever seeing them. The rest are long-term memory, how to present tasks to users once sessions are hidden, and the context boundaries and A2A collaboration between isolated instances inside one organization.
So what
This design proposes no new theory, as the authors say plainly: it carries classic computer systems engineering ideas into agent construction. What is genuinely interesting is the observation about 3 to 5 sessions. Over the past two years model capability flattened the barrier to any single task, and the bottleneck moved up to human attention. This time DeepSeek treats that as a problem solvable with system design, pushing session management, context synchronization, and event routing down into the architecture so that people only decide and accept.
The experiment is synthetic and ran five times, and the prototype says outright that it is not a product. The team's internal instance built on these ideas is already running continuously, taking part in issue reproduction and fixes, responding to code reviews, and helping iterate DeepSeek Harness itself. What this looks like once outside teams actually run it remains unanswered.