DeepSeek’s Super-agent, explained

DeepSeek’s Harness team has designed a single coding agent that lives in a team’s chat and GitHub repository and handles many requests in parallel.

Based on the team’s design essay and open-source prototype, both published October 31, 2026, and on press coverage from November 1.

The whole system on one page. Every later diagram zooms into one part of this picture.

Overview

DeepSeek Harness (the dsh command) is DeepSeek’s open-source agent harness, the program around a model that reads your request, calls tools, runs commands, saves the session and repeats until the job is done. It came out in August 2026 under the MIT licence. Every part of it, from the model adapter to the agent loop, is a plugin you can replace.

Super-agent is what the Harness team wants to build next. Today you open one chat session per task. In their design, one agent sits in the team’s group chat and GitHub repository, picks up requests, starts workers for them in parallel, and replies in the thread where it was asked.

The team shipped two things: a long design essay and a prototype, dsh-superagent-prototype, packaged as a Harness bundle for one GitHub repository with optional Feishu chat. Both are labelled as research, and the prototype covers only part of what the essay describes.

The essay’s rule is to spend as little human attention as possible for as much value as possible. The agent acts only when asked or when a written team rule allows it, and posts only when someone has to act or can use the result.

Attention is the bottleneck

Today’s coding agents treat one session as one unit of work. Sessions don’t share memory, so when you run several in parallel you are the one carrying context between them and switching back and forth. The team puts the limit at about three to five sessions that one person can actively follow. Past that, more agents don’t get more done, because you can’t keep up with them.

Left: you coordinate everything yourself. Right: one Router holds the cross-task picture, so the number of parallel tasks is no longer capped by what you can track.

The essay asks for an agent with one memory across conversations and channels, that runs many tasks at once, notices work nobody assigned, and stays online. Its example is a group that agrees on plan A in chat and then switches to plan B in a pull-request comment. The agent should see that both are about the same work and change course.

Architecture

The essay compares two simple designs before settling on a third.

A is continuous but serial. B is parallel but fragmented, and you may get several replies to one question. C keeps memory and the voice in one place and pushes the work out to Workers.

The Router is one long-lived session. It receives every human message from every channel, keeps track of how tasks relate, decides who does what, and is the only part that talks to people. It doesn’t write code and may not have a shell tool at all. The team found the job easier than they expected, and a smaller, faster model often handles it well.

Each Worker gets a fresh context, the full tool set, and usually the strongest model, since Workers write the code. They never message people. They report to the Router, which answers for them. Inside a hard task a Worker can still start its own sub-agents or an agent team, and the Router never sees that detail.

In a typical “agent team”, a lead agent breaks one big task into parts and coordinates them closely. The Router never splits a task. It tracks how separate tasks relate to each other.

Choosing what to work on

Every piece of work starts as a trigger, such as a chat message, an email, a calendar reminder, a code-review comment or a CI result. Most of what happens in a group chat isn’t a request, so triggers pass two filters. The fast path is ordinary code that lets events through by source, group and allow-list. Whatever gets past it goes to the slow path, where an LLM reads the team’s written policy and decides whether to take the work on.

Top: the two-stage filter from the essay. Bottom: how the published prototype separates requests people make from work the agent spots by itself.

The prototype spells out who can start work. An explicit request is a person on the allow-list addressing the agent, and it is handled in every mode. An inferred candidate is something the agent noticed on its own, and it needs a matching written rule. Messages from bots always count as inferred candidates.

Inferred work then depends on the accept mode. off ignores it. observe, the default, records “would have accepted” and runs nothing. auto actually starts the work. The README suggests running in observe first, reading what it would have done, and switching to auto after that. Each work item also records which version of the policy it was accepted under, so tightening a rule can revoke work before it resumes.

Threads

Consecutive events in the same pull request, chat topic or email chain form a thread. The first event goes through the Router, which starts a Worker and subscribes it to that thread. Later events in that thread go straight to the Worker without passing through the Router.

e1 takes the slow path through the Router. e2 goes straight to Worker A. e3 reaches both Workers because both are subscribed, so they can see they’re touching the same code.

Subscriptions are many-to-many. Two Workers subscribed to the same thread both see its events, so they find out they are touching the same code without messaging each other. In the experiments, turning direct delivery off barely changed how fast tasks finished, but the Router had to make about 30% more decisions and read about 37% more tokens.

Memory

A Router that runs for weeks can’t keep everything in its context. The team treats the context window as a cache. Some information is placed in it directly, the rest is left out behind a reference, and every object has an ID the model can use to look it up.

Inline the likely-useful bits, spill the rest behind pointers, and let the model follow IDs from object to object. The essay calls that last part Chain of Recall.

When someone asks in chat whether “the font thing” is done, the Router doesn’t need last week’s conversation in memory. The message carries a thread ID, the thread carries the Worker’s ID, and the Worker’s record points at the pull request, where the answer is.

An asynchronous agent loop

Most agents run a ReAct loop: think, call a tool, wait for the result, think again. While a long build runs, the agent can’t read new messages. Super-agent replaces long commands and subtasks with start() and stop(). start() returns “Started” immediately, the result comes back later as a new event, and the model can cancel something that’s taking too long or is no longer wanted.

Top: a new instruction waits behind an 8-minute build. Bottom: the agent reads it right away, stops the build and switches plans.

This asynchronous mode already exists in DeepSeek Harness but is off by default. The Router uses the same mechanism to batch work. Triggers that arrive while it is in the middle of a call are added to its next one.

Where it runs

To keep the agent online, the design separates compute from storage, as many databases do. The code that drives the agent loop runs in stateless cloud containers. Every session’s state lives in a database. If a container crashes, another one loads the state and continues.

Three separate things: the loop (cloud, stateless), the state (database) and the place commands run (wherever a small daemon is installed).

The machines that do the work only run a small daemon that executes commands and returns results. That means your own laptop, with its uncommitted changes and local credentials, can be one of the machines the agent runs commands on. If a device goes offline, its tasks wait and catch up when it reconnects. The essay compares this to Anthropic’s “brain and hands” split, with the difference that the hands here are people’s own computers instead of hosted sandboxes.

The Watchdog

A separate Watchdog session runs on a timer. It handles infrastructure failures like API errors or failed state recovery, and it checks whether each Worker is making real progress or drifting. Maintainers can ask it in plain language why something failed and have it adjust prompts or trigger rules.

An example request

Here is how a bug report moves through the system. A person is involved in only a few of the steps.

The Router confirms once, then goes quiet. The Worker does the work and writes the pull request. Review comments go straight to the Worker because it subscribed to the PR’s thread.

The agent writes differently in each channel. Chat replies are informal and stay under 100 words. On GitHub and email it writes longer, structured text, for example a pull-request description with background, changes and how the fix was tested.

DeepSeek also uses the agent for speculative work. Their Harness user group has a “silently reproduce and fix” rule: when someone reports a problem, the agent tries to reproduce and fix it in the background and says nothing unless it confirms the bug and finds a simple fix. In one case, people were still discussing a bug where tildes rendered as strikethrough when the agent opened a pull request fixing it.

Results

The team ran a synthetic test. Each run fed in about 300 chat and CI messages, of which about 20 were real work requests and the rest chatter, follow-ups, stop requests and CI noise. The coding itself was replaced by a tool that waits for a set time, so the test measures scheduling and coordination and says nothing about code quality. Each setup ran five times.

Super-agent finished faster and, more importantly, more predictably. Its slow tail is about half the single-session setups’. It paid for that with two to four times the tokens. — Super-agent finished sooner and varied less between runs. Its slowest runs took about half as long as the single-session setups’. It used two to four times as many tokens.

With a neutral prompt, the model never used its sub-agent tool in five runs, so everything happened in one session that kept getting interrupted. With a “delegate first” prompt it delegated in four of five runs. In the fifth it decided a task was small enough to do itself, and that run was the slowest.

A separate stress test looked only at the Router. As triggers rose from about 1 to about 40 per minute, it grouped more of them into each model call (from 1.0 to 2.8 on average). Time per request rose from 2.5 to 3.9 seconds, while time per decision fell from 6.4 to 1.6 seconds. The team concluded that one Router session is enough for a team their size.

The authors call these results preliminary, given the synthetic load and simplified environment.

Sources

Written from public sources as of November 1, 2026. All numbers come from the DeepSeek Harness team.