DeepSeek open-sourced a Super-agent prototype: Router answers, Workers work

On October 31 a new repository appeared in DeepSeek's GitHub organization: dsh-superagent-prototype, “Towards a More Autonomous Agent System”. One commit, MIT license, 2,345 stars at our observation time. The README's opening sets the identity precisely: a research prototype, for reference only, “not an official DeepSeek product” — it grew out of the team's day-to-day work, with much of the engineering done by coding agents, was adapted for publication, and matches neither the internal version nor the implementation described in the design article “Exploring Super-agent Design: Towards a More Autonomous Agent System”; some designs in the article are future directions the prototype does not implement. That disclaimer is not boilerplate: it decides what a reader can verify from the repo (the architectural skeleton, the domain concepts, the authorization flow) and what they cannot (the article's experiment environment and its numbers).

What the prototype is: a proactive coding agent for a single GitHub repository, packaged as a bundle for DeepSeek Harness. It listens to GitHub notifications, issues, pull requests and CI status, and optionally Feishu; when someone on the allowed list — or anyone in a conversation the team opened to requests — asks for work, it opens a work item, works in its own session and directory, and answers in the original conversation, for example with a pull request. Beside it, a web panel lists “what needs a person right now”. All of it runs on DeepSeek Harness: the official page states Harness is now in public preview worldwide and open source, startable as a desktop app or with one npx command for the Web UI, built as “everything is a plugin” on the Cordis microkernel; the page's trajectory view lays out every tool call's payload, result and timing for inspection.

The design article sets four target traits (per ITHome and QbitAI): continuous (across IM, GitHub and other channels), efficient (parallel execution), proactive (observing events and advancing valuable work on its own), and persistent (always on, recovering from failures). The README sets the project's unit of account in one line — “take as little human attention as possible, and give as much value as possible”: a message, a notification, a question, a setting, a panel element each cost someone's attention and must return more value than they consume, or they are removed.

The two layers take their names from the design article, but the skeleton sits in the repository docs. The Router layer is the code's main session (orchestrator): it handles human interaction, maintains global context and dispatches tasks, executing none itself — its tool set is deliberately smaller, built for routing. The Worker layer is one executor session per ticket (worker-<ticket>): an isolated session and directory with the full work tools, focused on a single task; it never talks to people, reporting only structured states to its ticket — progress, ready, blocked, failed, or dropped.

Taking on work runs through a full authorization chain. Events enter from sources and face two judgment layers: a deterministic gate — who may originate work on this source, in which identity, which bots may make candidates — then a model assessment of whether this batch of events is worth starting. The moment work is accepted, a Mandate is granted: it records the policy version, the scope, the strength and the matched rules — why this may be done and how far it may go. Then comes assignment: the domain only records which ticket is bound to which executor, while the real execution session lives outside the domain, with a ten-minute prepare command that may use git worktree to create a checkout. A person's stop is the only human action that withdraws a Mandate; a policy-version change does not revoke running authorizations, it delivers a notice to the affected tickets.

Two designs show how the attention ledger is kept. First, subscription fan-out: later comments on a ticket's own pull request, or a person speaking directly in a related thread, flow back to the ticket without another Router judgment — follow-up discussion needs no one to @ the agent again. Second, the panel: it lists only tickets waiting on people (awaiting an answer, awaiting review, blocked, failed) — “a healthy state takes no space”. The docs also state plainly that these wrappers and directories are defaults, “not a security boundary”, and blocked commands fail only when invoked by name; a worker can still execute a program by absolute path. Writing the boundary into your own docs is more useful than a vague security claim.

The design article includes experiments, but its original runs on the team's WeChat account, which we could not access; the numbers below were cross-checked between two independent reports, ITHome and QbitAI. The composite load test: about 300 messages and roughly 20 work requests, five repeats per configuration — the Super-agent finished tasks with a p50 of 12.4 minutes and a p95 of 15.7 minutes; a single-session baseline with neutral prompts reached a p95 of 29.5 minutes. Both reports state the boundary: a simplified synthetic load measuring orchestration ability, not per-task quality; QbitAI adds that these are preliminary experiments in a simulated environment, with efficiency gains coming at extra token cost.

A second set of numbers has only ITHome as its secondary source: stress-testing the Router alone, the event trigger rate rose from 1 to about 40 per minute, average batch size from 1.0 to 2.8, per-request latency from 2.5 to 3.9 seconds, while amortized inference per decision fell from 6.4 to 1.6 seconds — batching events buys effective throughput. QbitAI carries a third comparison: removing direct event routing raised Router decisions by about 30% and cached-token reads by about 37%. All three point the same way: this architecture's gains concentrate in coordinating multiple tasks, and coordination itself costs money — the drop in amortized inference is paid for by batchier, cache-heavier strategies.

Beyond the prototype, the design article lists open problems (per both reports): Router scalability, month-scale long-term memory, human–agent collaboration beyond sessions, agent-to-agent (A2A) communication, and safety — especially prompt injection, on-device credential leakage and cross-device permissions when a cloud agent connects to local devices. The team notes an internal Super-agent instance already runs continuously, joining defect reproduction, code review and iteration on Harness itself. These are direction statements, not delivered capabilities; against the README's disclaimer, a reader should keep “what the article says” apart from “what the repo runs”.

Read to the end, the design worth taking away is not “AI directing AI” but the treatment of human attention as a scarce resource: act only when asked or when a written rule allows, with unrequested work starting in record-only mode; speak only when a person must act or can use a result; ask one concrete question at a time; stop by impact, not effort — a local change goes as far as a reviewable result, a design decision stops at a clear question; drafts marked unfinished, failures reported as failures, limits never bypassed. The responsibility clauses are equally concrete: start with a short allowed list and record-only proactive work, widening only once what the agent would have done looks right; when the agent gets noisy, tighten its prompts or pause it instead of adding messages to explain the noise; never use it to mass-produce pull requests or broadcasts; and read what the agent posts in your name, correcting it in the prompts when wrong.

This thread connects to two existing lines on the site. Our personal-AI-companions topic follows how dots, Muse and LingGuang 2.0 handle “remembering you and managing your affairs” — attention management is their shared hard problem; what DeepSeek hands over here is one reference architecture for the same question: how a resident agent teams up, gets authorized, and isolates what needs a person. On the model layer, the Harness page's default session reads DeepSeek-V4.1-Flash High — the October 17 weights from our DeepSeek topic (the generation whose independent AA/max score is 45). From open weights to open agent infrastructure, DeepSeek is turning the integration layer into composable open-source parts.

Limits to keep while reading: the public prototype differs from the implementation described in the design article, and several designs (the Watchdog, the asynchronous ReAct loop enabled by default, long-term memory) are not implemented in it; the experiments are vendor-reported synthetic loads — we have not deployed, run or paid to verify anything; no usage pricing is known; the MIT license covers the code. For a team, the repository's value is a reference answer to “how to team up”; for readers, it opens up an engineering question usually hidden under marketing words — the more capable an agent, the more it can waste a whole team's attention, which is why authorization, reporting and stopping must be designed first.