DeepSeek’s Super-agent is a design paper, not a release

DeepSeek’s Harness team described Super-agent in a WeChat post from DeepSeek on October 31. Super-agent is an always-on coding agent that sits in developer group chats and opens fix pull requests without being tagged. What you can install is a research prototype, not a product: an MIT-licensed bundle for DeepSeek Harness that works through one repository’s issues and pull requests. Its repository opens with “Research prototype for reference only, not an official DeepSeek product.”

The post opens by warning that it explores an architecture and does not describe current DeepSeek Harness features, and some of what it describes is not in the code yet. The only piece already built into Harness is an asynchronous agent loop. Long commands and subtasks start in the background and return “Started” at once, so the session keeps taking messages, and their results come back later as new events. It is implemented but not turned on by default.

What you can run

The prototype, dsh-superagent-prototype, listens to GitHub and, optionally, Feishu. It turns allowed requests into parallel work items, each in its own agent session. MarkTechPost reports that proactive work sits behind three accept modes: off, observe and auto. Observe is the default and only records what the agent would have accepted, so a fresh install watches before it acts. Shell commands move to the background after 5 seconds.

The prototype runs on Harness, the Node.js agent runtime DeepSeek put on GitHub under MIT in August as a developer preview. At that point the model adapter, tool registry, session log and agent loop were all replaceable plugins.

Inside the company, a Super-agent instance runs a “silently reproduce and fix” policy in DeepSeek’s internal Harness user group. When someone reports a problem or debates a change, the agent tries to reproduce it and find a fix in the background. It posts only after it has confirmed the bug and found a simple fix, and otherwise stays quiet. One example in the post shows it submitting a fix pull request while the group was still discussing solutions. The same instance carries a task between chat and GitHub, so if a user picks plan A in IM and switches to plan B in a pull request comment, the agent changes course.

Router, Workers and a Watchdog

The team’s starting point is a number from its own observation: one person can follow only three to five active sessions at a time. When each agent session handles a single task, the post argues, model capability limits what one task can achieve and human attention limits how many tasks run at once. Adding more CLIs, MCP servers or connectors to a local single-session agent doesn’t fix this. The session still handles one thing at a time, context from different tasks gets mixed together, and the agent stops when the laptop goes offline.

So the work splits in two. A resident Router session takes every message from people and hands out tasks. It doesn’t run tasks itself and may not even get a Bash tool, and the team found a lighter model is often enough there. Workers each handle one task in a separate context on the strongest model, and never post to chat directly. They report to the Router, which answers the user. Once a Worker takes a thread (one pull request, one IM topic, one email chain), code sends that thread’s later events straight to it, bypassing the Router. Several Workers can subscribe to the same pull request and see each other’s changes without messaging each other.

Chat messages, email, calendar reminders, review comments and CI results all enter the system as Triggers. Fixed rules on source, group and allowlists drop most irrelevant messages before a model sees anything. A model then judges what’s left against policies written as prompts. The Router keeps up with bursts by batching: events that pile up while it is working on one request go into its next model call together. The model reads them all in one parallel pass, so the call’s time grows much more slowly than the number of events in it.

A separate Watchdog session sits outside the main system and runs on timed messages. Besides handling infrastructure errors, it has a model judge whether each Worker is making real progress or drifting from the goal. Maintainers can ask it in plain language what went wrong, or have it edit prompts and trigger rules while the system runs. In chat channels the prompts enforce one hard rule the team says it tested: a single reply stays under 100 words.

Your machine stays put

Local agents today keep the loop, the session state and the repository on one device, so the agent stops when that device sleeps. Super-agent runs the loop in stateless cloud containers and keeps session state in a database. The repository, files and toolchain stay on the user’s machine behind a lightweight daemon that only runs commands and returns results. DeepSeek calls this BYOM, bring your own machine. A task meant for a laptop that is only online some of the time can be triggered and finished once the laptop reconnects.

The team says the approach matches Anthropic’s “decoupling the brain from the hands”: a stateless harness, session logs stored outside it, and execution environments reached through one interface. DeepSeek says the difference is the setting. Anthropic’s article covers a managed service with sandboxes created on demand and resources inside a customer’s VPC. DeepSeek wants first to reach personal machines that go offline now and then and hold uncommitted changes and local credentials.

What the 15.7 minutes measures

The team tested four setups on a mixed stream of group chat and GitHub CI messages: Super-agent, Super-agent without direct thread routing, and a single session with a subagent tool under two prompts. One prompt was neutral and the other pushed the session to delegate. Each run carried about 300 messages, about 20 of them work requests and the rest chatter, follow-ups, stop requests and CI messages. Each setup ran 5 times. Super-agent’s p95 was 15.7 minutes, against 29.5 minutes for the single session with subagents under the neutral prompt.

In that test, coding was replaced by a tool that only burns time, so the figure speaks only to how the system schedules and coordinates work and tells you nothing about the code a Worker would write. The load was synthetic and the environment simplified, and the team calls the results preliminary.

The team also names a scale limit. A single resident Router session is “already enough at our current team size.” Beyond that, the Router can be split into several sessions, and each split adds throughput while weakening the memory and context the pieces share. The post says that trade-off remains until someone solves global memory.