DeepSeek super agent design is quieter on purpose, but the download can still read a home folder.
A repository (the project’s files plus the history of every change, as GitHub stores them) named deepseek-ai/dsh-superagent-prototype was created at 09:32 UTC on 31 October. When I asked GitHub’s own API on 1 November it had 21,505 stars and 2,578 forks, one commit, and an MIT license (you may read, change, and ship the code, including in a product, if you keep the license notice). The first line of the README is the line the star count skips: research prototype, for reference only, not an official DeepSeek product.
The same README says the published code was adapted, so it is not the team’s internal agent, and it is not the system described in Exploring Super-agent Design. Some ideas in that essay are future work. They are not in this download.
A program already knows the steps. An agent asks again.
Start before the product name.
A program is a list of steps someone wrote in advance. Read this file. Change that line. Save. If the world is not the world the author imagined, the program does the steps anyway.
An agent (a program that chooses the next step by asking a model, then looking at what happened, then asking again) does not have the whole path written down. A model (a huge file of numbers, already trained, that guesses the next piece of text) is the part that answers. The loop around it is the agent. Training (rewriting those numbers on mountains of examples) already happened, somewhere else, before you opened the chat. Using the finished file is inference (read the numbers, do not change them).
A coding agent is that loop with permission to touch a project: read files, run commands, edit, sometimes propose a change. The conversation that holds the loop’s memory is a session (one chat’s running notes: what you said, what it tried, what came back). Today’s usual coding agent is one session and one folder. You type. It works. You read. If you look away, that session waits, or it keeps going inside a pile of notes you are no longer watching.
The scarce thing is you, not the model
DeepSeek’s essay, posted by @DeepSeekHarness on 1 November, opens with a limit from their own experience, not from a published study. A person can usually follow only 3 to 5 active sessions at once. One task is limited by how good the model is. Many tasks at once are limited by human attention (the minutes of your mind you can actually spend).
That sentence is the whole design. Everything after it is an attempt to stop the agent spending those minutes.
They name four properties they want, and they say no single ReAct loop can provide all four. A ReAct loop (reason, then act with a tool, then read the result, then reason again) is the ordinary heartbeat of an agent. It does one step at a time. While a long command runs, the classic version cannot hear you. That one-way-at-a-time wait is half-duplex (like an old radio: you talk, then you listen, not both).
The four properties, in their words and then in plain ones:
- Continuous. You talk to it where you already work, in chat or on a code review, and it still feels like one agent. You should not have to remember which session holds which fact.
- Productive. Several hard jobs run at once, and a new instruction does not wait for the previous command to finish.
- Proactive. It watches events and acts on what is worth doing. Otherwise it stays quiet.
- Persistent. It stays online, reaches the real machines the work lives on, and gets itself up after a fault.
The essay says these have to come from the system around the loop, not from a smarter paragraph in the prompt (the text you send in). Adding a connector to a single local session, they argue, does not fix it. The session still blocks, still mixes tasks, and still dies when the laptop sleeps.
Learn the nouns in the order the prototype uses them
The download’s own documents are numbered, and each one refuses to use a word the previous document has not introduced. That is a good way to read this. I am using the prototype’s nouns, from docs/001-domain.md, not the looser nouns in the recaps.
A Source (an ear: a stream of events, plus the identity the agent uses on that stream) is how the outside world gets in. This prototype ships two. GitHub is required, and only github.com. GitHub Enterprise Server is not supported. Feishu (the chat and documents product also sold as Lark; here, an optional second ear) is the other. Each Source drops the bot’s own messages before they become work, so the agent does not reply to itself.
A Trigger (one event, frozen: a comment, a chat line, a test result) is the unit they audit. Accepting the same Trigger twice must create one Ticket, not two. A Thread (the Triggers that belong together, in time order, as that Source defines “together”) is the conversation those events sit in. A pull request’s comment thread is a Thread. An Issue (a tracked request or bug on the repository) can be a Thread. So can a Feishu topic.
Eval (the judgement of a batch of Triggers: should new work start, continue, or stop) has two layers. The gate is code. It checks who sent the message and whether they are allowed. The assessment is the model, and it runs only on what the gate let through. Eval holds no memory of its own. The Thread does.
A Ticket (one unit of work that has been allowed) is created only by an accept. A Mandate (the permission slip on that Ticket: who asked, how strongly, how far the work may go, and which version of the rules was in force) is immutable. Wider scope means a new Ticket, not a quiet expansion of the old one. A person’s stop withdraws it. A policy that no longer allows it can revoke it when the Ticket is about to resume. A mere edit of the rules does not kill a job that is already running. The change is delivered as a notice instead, so half-finished work is not thrown away.
An Assignment (the binding of that Ticket to one Executor for a stretch of time) is how the job is handed over. The Executor (the worker: one session and one directory for that Ticket) is outside the domain model on purpose. The domain records who is executing. It does not pretend to be the model.
A Channel (the write side of a Thread: where a reply is allowed to go) is how the answer gets back. In this prototype that means a Feishu reply, a GitHub comment, or a review-thread reply. A pull request (a proposed bundle of changes, with a branch of its own, waiting for a person to take it or leave it) is one of the results the README says the agent may bring back to the conversation where you asked.
A Thread link (the link that says this Ticket is listening to this Thread) is the part that saves your attention after the first message. A later comment on a linked Thread is delivered to the worker as context. It does not have to mention the agent again, and it does not grant new authority. The Mandate still limits the Ticket. Messages from bots and from CI (continuous integration: the automatic test run that starts when code changes) ride along as context. They do not, by themselves, resume a finished Ticket.
The router is not a team lead
In the code and the prompts, the main session is called the orchestrator. In the essay it is the Router. Same job: the long-lived session that sees people and decides. The worker session is the Executor.
The essay is sharp about what the router must not do. It must not carry out the task. It can, they say, run with no shell (the text window where commands run) at all. A lighter model is often enough, because the job is dispatch, not the code. Workers get the strong model, because they are the ones whose output you will have to read.
That is the opposite of the usual “agent team.” A team lead is asked to break one hard task into steps and keep the roles in line. Those steps are tangled, so the lead has to understand the task. DeepSeek’s router does not break a task down. It only decides which worker gets which request, and it talks to people. If two workers collide, the essay wants them to notice because they both follow the same Thread, not because the router narrates every keystroke.
In the essay, workers never speak to you directly. Their tool logs stay inside their session. The router is the only voice, so five jobs do not become five people talking in the chat. The philosophy document speaks for the agent as a whole, and it is the sentence worth keeping: confirm once, name what you will do, stay quiet while working, write again only with a result, a decision, or a failure. Short. In the conversation where the request was made. One concrete question at a time.
A local change may go as far as a reviewable result. A change that needs a design decision stops and asks. A draft is marked unfinished. A limit is not bypassed to avoid asking.
Unasked work has three switches. The default is a diary.
Strength is how solid the request is.
Explicit (a person on the allowed list addressed the agent, or a cell of the admission table says this mention counts as a real request) can start work in every mode. Inferred (a guess: an unlisted person’s follow-up, a message that did not address the agent, or a bot the team listed) cannot start work unless the mode allows it. A bot can never make an explicit request, and it cannot stop a Ticket. A GitHub App cannot be the agent account at all, because the prototype reads that account’s notifications, and an App does not have them.
The accept mode is part of the Policy (the versioned rules: who may ask, which bots count, and what unasked work is allowed).
off means nothing inferred even becomes a candidate. observe, the default, assesses those candidates and, if the rules would have accepted, records the decision as ignore marked “would accept.” Nothing is started. auto turns a positive assessment into a real Ticket, and only if at least one written rule matched. The deploy guide says to start in observe and move to auto after the recorded decisions look right.
The philosophy document tells the operator (you, the person who turned it on) to start narrow: a short allowed list, and proactive work only recorded. Widen both once what it would have done looks right. When it is noisy, shorten the prompts or pause it. Do not add more messages to explain the noise. Do not use it to produce volume. Mass pull requests cost the team more attention than they give. You own what it posts under accounts your colleagues already see every day.
The fast number is a stopwatch, not a code review
Section 7 of the essay is labeled preliminary. The workloads are synthetic (made up for the test, not a real team’s week). Coding was replaced by a tool that only consumes time. Each design ran 5 times. Each run had about 300 messages, of which about 20 were work requests. The rest were chat, follow-ups, cancellations, and CI. They say parts of the setup could be more rigorous, and the results are indicative only.
Read that before the minutes.
p50 (the middle result if you line the runs up: half finished sooner, half later) and p95 (near the slow end: only about one run in twenty is slower) are the two columns they published.
Super-agent: 12.4 minutes at p50, 15.7 at p95, and 23.2 million cache-read tokens (chunks of text, often a word or part of a word, that the system could reread cheaply because that prefix was still in memory). The same design without pass-through (follow-ups handed straight to the worker, skipping another router decision) finished in about the same time, 12.6 and 15.5, but cache-read tokens rose to 31.8 million. About 30 percent more router decisions. Pass-through did not make the fake tasks finish faster. It made the router cheaper.
A single session with a subagent tool and a neutral prompt (“use a subagent when appropriate”) delegated in 0 of 5 runs. All the work stayed in the main session, new messages kept interrupting it, and p95 was 29.5 minutes. A prompt that begged it to delegate succeeded in 4 of 5 runs and still had a p95 of 29.0, because the fifth run decided the work was small and did it itself. That is the essay’s real claim about the architecture. A prompt can ask a session to hand work off. The session often does the work anyway. A router that is not allowed to do the work does not get to make that mistake.
A second test stressed the router alone, with a real model on the router and mock models on the workers. As triggers that needed a decision rose from about 1 a minute to about 40, the average batch grew from 1.0 to 2.8, time per request grew from 2.5 seconds to 3.9, and the amortized time per decision fell from 6.4 seconds to 1.6. Bursts got cheaper per decision because the waiting events were merged into the next call. They conclude that, at their current team size, splitting the router would throw away shared context for a bottleneck they have not hit.
None of those minutes is a claim that the GitHub prototype writes better code than Claude Code, Codex, or a person. The essay says it measured scheduling. 7 and 29.5 into “twice as good.”
What the essay wants, and what the zip file is
The essay describes five modules. Two levels, router and workers. Event-driven triggers, with a fast path in code and a slow path in the model. Full-duplex chat, so a long command does not block the next sentence. They say DeepSeek Harness (the program that hosts sessions, tools, and the model; this prototype is a bundle for it) already has that asynchronous mechanism, and that it is not on by default. Then a split between cloud compute, stored session state, and the machine where the code actually lives, including BYOM (bring your own machine: a small daemon on your computer runs commands, and the loop stays elsewhere). Then a Watchdog (a separate session, outside the main system, that notices both crashes and the quieter failure where the process is alive but the model is stuck).
The essay says this is not an introduction to existing features of DeepSeek Harness. Their internal instance, they say, already continues one task across chat and GitHub, and sometimes opens a pull request without an @-mention. That instance is not the repository.
The download is narrower, and the README says so. One GitHub repository. Feishu if you turn it on. A web panel on 127.0.0.1 (your own machine only; not a public address). Unasked work starts in observe. Setup is meant to be done by a coding agent reading SETUP.md and asking you one question at a time.
The open problems in the essay are still open: how to split the router when one session is no longer enough, how a person works with an agent once sessions disappear from the screen, how two agents with different permissions talk, and security. The English post I read was cut off inside that security section.
The login wrapper is not a wall
This is the paragraph the star-count posts leave out. It is in docs/006-deployment.md.
Both the router preset and the worker preset run with danger-full-access, as the operator’s OS user (the account on the computer that owns your files). A wrapper script chooses which GitHub login the gh command uses. The document says the wrappers do not isolate the process. A worker can execute programs by path and read the operator’s home directory. The isolation they recommend is a dedicated OS account that contains only the agent’s credentials.
So the honest install, if you install at all, is not “point it at the repo where I keep my keys.” It is a separate computer account, a separate GitHub user with write access only to the one repository you mean, and your personal gh listed as a blocked command so the worker cannot pick it up off the path. The panel’s API is local and refuses a browser page from another site. That is a real control. It is not a sandbox (a box that cannot see the rest of the machine).
What the deploy doc says you need, before any of the ideas above matter:
- Node.js 22.19 or newer, or Node 24, plus pnpm, git 2.32 or newer, Python 3.8 or newer, and tmux (a program that keeps a terminal session alive after you close the window).
- GitHub CLI 2.48 or newer, signed in only as the agent account, through a wrapper. The install snippet pins
@deepseek-ai/dshat0.2.1-rc.3. Other versions have to matchengines.dshin the package. - A model provider already configured for that Harness profile. The prototype uses the profile’s default model unless you name another for Eval or for workers.
- A local clone of the one repository, so each Ticket can get its own worktree (a second checkout of the same history, in its own folder, so two jobs do not edit the same files).
- For Feishu,
lark-cli, tested by them at 1.0.90, and a bot app. Skip it if you do not need a second ear.
The panel, once it is up, answers three questions in order. Does anything need me now? Is the system healthy? What is the history of this one piece of work, from Trigger through Eval to Ticket? A healthy state is supposed to take no space. That rule is in docs/005-panel.md, and it is stricter than most admin screens.
What is worth copying if you never clone the repo
The minutes will be outdated. The nouns are the part I would keep.
Give unasked work a diary mode before you give it hands. Observe is that diary. A prompt that says “be proactive” is not.
Make the first yes a permission slip that cannot quietly grow. If the job gets bigger, that is a new slip, with a person’s name on it.
Send follow-ups to the worker that already has the thread. Do not make a person mention the bot again, and do not make the follow-up a new grant of power.
Speak once at the start, once at the end, and in between only for a decision or a failure. A panel that lists what needs a person, and hides the rest, is the same rule in pixels.
Do not measure that quiet with a star count, and do not measure it with a stopwatch that never compiled. The prototype had not been asked, in any number I could verify, whether the code it writes is any good. The essay says the internal system is already doing real work. The README says the file you can clone is not that system.
If you run it, run it as someone else, on one repository, in observe, until the would-accept list is boring. Boring is the feature.
Common questions about the DeepSeek super-agent prototype
Is the GitHub zip the same as the essay’s internal system?
No. The README says the published code was adapted for reference, and it is not the system described in the essay.
Should I run it against my real home folder?
Not first. The docs emphasize observe mode and a narrow would-accept list. Treat it as a research prototype with broad file reach until you have read the authorization docs.
What did we check?
GitHub API on 9 November 2026: deepseek-ai/dsh-superagent-prototype reported 21,505 stars, 2,578 forks, created 31 October 2026 09:32 UTC, MIT license.
