DeepSeek's Super-agent: a blueprint for a background agent

The bottleneck is human attention

A coding agent now handles a single task with less and less supervision. The trouble starts with several tasks at once: each session has its own context, and a person has to switch between them and remember what is where. The DeepSeek Harness team's experience is that someone can follow three to five active sessions this way.

Their answer is a Super-agent: one agent with a continuous memory of conversations across every channel, which reacts to events on its own, works on several tasks in parallel and does not shut down when a laptop does. DeepSeek's internal Super-agent instance reads issue reports in a group chat and opens pull requests with fixes even when nobody has tagged it.

A Router assigns, Workers work

The architecture has two layers. The Router is one long-running session that talks to people, knows the state of every task and hands tasks out. It executes nothing itself, so the authors find a lighter, faster model usually serves it well. Workers get one task each, their own context and a full set of tools, and they reach people only through the Router. They decide the quality of the code, so they usually need the most capable model.

Why not one session that starts subagents? In the authors' experiment, a model with a neutral prompt ("Use a subagent for a piece of work when appropriate") did not delegate in any of five runs and did everything itself, interrupted by every new message. A prompt that pushed delegation worked in four runs out of five. In the fifth the model judged the work "small", did it itself, and the 95th percentile of task time again reached 29 minutes.

The lesson: delegation that depends on the model's judgement in the moment is unreliable, so build it into the architecture. It costs tokens: the Super-agent's sessions together read 23.2 million cached tokens per run, against 6.1 million and 10.8 million for the single-session designs.

Code filters, the model judges

A Super-agent's input is events: group chat messages, emails, calendar reminders, code review comments, CI results. Most of them are noise, so the first filter is plain code. It checks the source, the group and allowlists of people and bots, and each source has one of three settings: respond only to explicit requests, assess as candidates, or ignore. Only what passes is judged by the model, against rules written in plain language that the team can change at any time.

Later events on the same pull request or chat topic go straight to the Worker already handling it, bypassing the Router. Without this shortcut tasks finished just as fast, but the Router made about 30% more decisions, and total cached-token reads rose about 37%. The Router copes well, because events that arrive during one step reach the model together in the next. In a separate stress test of the Router alone, with mock Workers, the rate rose from about 1 to about 40 events needing a decision per minute, and the amortised inference time per decision fell from 6.4 to 1.6 seconds. Before you split a central session into several and lose the shared context, measure whether it really cannot keep up.

Context served in pieces

The authors treat the context window as a cache. The model gets an event's ID and a short summary, plus what it will most likely need next: the IDs of related objects, the neighbouring messages and the one being replied to. Everything else is replaced by a reference the model can follow with a tool when it needs it. Every event, thread and Worker session has an ID, so the Router can follow references back to an old task's history when someone raises it in another channel. The original calls these mechanisms Inline & Spill and Chain of Recall.

The prototype puts numbers on it: when assessing a candidate task, the model sees the first five messages of the thread and five on either side of the event, and long messages are shortened with their full length stated. Rather than pasting a whole thread into the model, give it a summary, the IDs and a tool to read the rest.

The agent says less than it does

Long commands do not block the conversation. start() returns "Started" at once, the result arrives later as a new event, and stop() ends anything that runs too long. DeepSeek Harness already has this mechanism, though it is off by default. The agent can also work ahead. DeepSeek's internal group runs a "silently reproduce and fix" policy: when someone reports a problem, the agent tries to reproduce it and find a fix in the background, and speaks up only once it has confirmed the bug and has a simple fix. Otherwise it stays quiet.

Each channel has its own style. In chat the agent writes only when a decision or sign-off is needed, briefly and with a direct question. DeepSeek found a hard cap of 100 words per reply effective. In a pull request or an email it is the opposite: the full problem, change and verification. The prototype closes a task in chat with one sentence holding the result, its link and any next step, and opens every GitHub message with a line saying an automated agent wrote it.

The brain in the cloud, the hands on your machine

A local agent goes to sleep with the laptop. A Super-agent separates three things: the agent loop runs in stateless cloud containers, session state lives in a database, and the repository and tools stay on the developer's machine, where a lightweight daemon only executes commands. Uncommitted changes, local credentials and intranet access never have to move to the cloud, and tasks waiting on a laptop that was off start when it comes back online. The authors call connecting your own machine BYOM (Bring Your Own Machine). Anthropic described a similar split for its managed agents in April.

A Watchdog oversees the whole: a separate session, run on a schedule outside the main system. Besides API errors, it checks whether each Worker is making real progress and has not drifted from its goal, because a process can be alive while the model goes in circles.

The prototype: safeguards worth copying

dsh-superagent-prototype is a TypeScript plugin for DeepSeek Harness, an open-source, MIT-licensed agent harness. It works with one GitHub repository and, optionally, Feishu chat, and its principle is to take as little human attention as possible and give as much value as possible. The safeguards are the most valuable part. Code enforces the allowed lists and permissions; the merge and screenshot rules are default instructions in the team prompts:

• The agent has its own GitHub account, never the operator's, because everything it writes appears under that name.
• By default, only someone on the allowed list can request work, by addressing the agent directly. Message content and quoted documents are inputs to a decision and cannot change permissions.
• Work nobody asked for has three modes: off, observe and auto. The default, observe, only records that the agent would have taken the task. You move to auto after reviewing those records.
• The agent does not merge its own pull requests. Without a configured merge tool a person does it, and auto-merge applies only to a change under 200 lines whose required approvals cover the latest commit.
• A UI change needs before and after screenshots of the same scenario. An after-only screenshot means the work is unfinished.
• Variables with KEY, PASSWORD, SECRET or TOKEN in their names are stripped from the command environment. The docs point out, though, that a Worker is not isolated: it runs as the operator's OS user with full access and can read their home directory, so the docs recommend a separate OS account holding only the agent's credentials.

Limits the authors state themselves

The authors call their results indicative only. The test was synthetic, about 300 messages per run with about 20 work requests, and it measured coordination, because coding was replaced by a tool that only consumes time. The text on X is a machine translation from Chinese. The published prototype differs from the internal version, leaves out some of the designs described, and according to its README was largely engineered by coding agents.

For a company, the most pressing open question is security. The cloud loop takes in outside events and has access to machines holding private code and credentials. A successful prompt injection or server intrusion therefore opens a path to every connected device, and a credential that reaches the model's context can leak with no attack at all. The agent would have to use credentials without seeing them, and the authors admit they have not solved that yet. Long-term memory over months of running is still open too.

Where to start in your own team

Before you connect an agent to your chat and repository:

• Count the sessions. If anyone on your team runs more than five agent sessions at once, attention is the limit, and a stronger model will not fix it.
• Write in code which channels the agent reads, whose requests it accepts and which bots it ignores. The model judges only what passes that filter.
• Separate assigning from executing. The session that talks to people does no work itself, and Workers do not write to people.
• Start unrequested work in observe mode and read what the agent would have done before you let it act without being asked.
• Give the agent its own GitHub account, block it from merging its own pull requests and run its commands under a separate OS account with no access to your secrets.
• Monitor task progress, not only whether the process is alive.