DeepSeek's Super-agent, decoded: what happens when the bottleneck isn't the model, it's you

What happened

On 31 October 2026, DeepSeek's Harness team published an essay called Super-agent Design Exploration: Towards More Autonomous Agent Systems. The same day, it put dsh-superagent-prototype on GitHub under the MIT licence. The repo is a coding agent for one GitHub repository, packaged for DeepSeek Harness, the company's open-source agent tool.

The prototype listens to GitHub and, optionally, the workplace chat app Feishu. When an allowed person asks for work, it opens a work item, does the job in its own session and directory, and replies in the original conversation, for example with a pull request.

DeepSeek says an internal instance built on the same idea is already running continuously, handling work such as reproducing and fixing issues and responding to code review. That's DeepSeek's claim. The public repo is something else: its README calls it a research prototype, not an official product, and says it isn't identical to the internal version.

The problem: attention, not intelligence

Most coding agents today live in a session: you open one, give it a task, and keep an eye on it. That works until you run several at once. DeepSeek's team observes that a person can typically follow only 3 to 5 active sessions, and argues that human attention, rather than model capability, is becoming the main limit.

So why not have one agent handle everything? The essay lays out two obvious designs, and each breaks in its own way:

• One shared session keeps all the context, but work happens one thing at a time.
• A new session for every event gets through lots of work, but the context ends up scattered.

The core idea: split talking from doing

Super-agent uses two layers. Each one gets the part of the job it's suited to.

• The Router is always on. It handles all human contact, keeps the view across every job and hands work out. It doesn't do the jobs itself, so the essay says a lighter model is often enough.
• The Workers each run one job in an isolated session, with full tools and usually the strongest model. They don't talk to users. They report to the Router, which replies.

How an event moves through the system

Everything starts as a Trigger: a chat message, email, calendar reminder, code review comment or CI result. Most of these shouldn't start any work, so filtering is half the design.

1. Fast path. Plain code checks deterministic rules, such as the source and an allowed list. No model is needed.
2. Slow path. A model judges what's left against a written policy.
3. Dispatch. An accepted request becomes a work item, which the prototype calls a Ticket, and a Worker takes it.
4. Subscription. The Ticket subscribes to its Thread, such as one pull request. Later messages there go straight to the Worker and skip the Router.

That last step does more than it looks. It stops the Router being pulled into every follow-up, and the test numbers below show why that matters for cost.

Going deeper: context as a cache

A Router that runs forever can't keep everything in its context window, so DeepSeek treats that window like a cache, with three techniques:

• Inline. Pull in what's likely to be needed, such as related object IDs, adjacent messages or the first 50 characters of some content.
• Spill. Keep full content outside the window, leave a summary or reference inside, and let the model read more on demand.
• Chain of Recall. Triggers, Threads and Worker sessions all have IDs, and each recalled item carries the IDs of its neighbours. The model can follow them hop by hop to find old work without loading all of it.

The essay also describes a Watchdog: a separate session that wakes on a timer, handles infrastructure failures, and checks that Workers are making real progress and staying on goal.

Going deeper: how the prototype stays out of your way

The most readable part of the repo isn't the code. It's docs/000-philosophy.md, which sets one rule for the project: take as little human attention as possible, and give as much value as possible. From that come some concrete behaviours:

• It acts only when asked, or when a rule your team wrote allows it.
• It speaks only when a person must act or can use a result, and stays quiet while it works.
• It asks one concrete question at a time.
• It stops by impact, not effort: a local change goes as far as a reviewable result, while a change needing a design decision stops with a clear question.

Long shell commands also move to the background after 5 seconds, so a Worker can receive new messages at its next step instead of being stuck waiting.

What the test shows, and what it doesn't

DeepSeek compared four setups on a simulated stream of chat and CI messages. Each run had about 300 messages, about 20 of them work requests, and each setup ran 5 times. The headline comparison is p95, the time by which 95% of tasks are done, which is a good measure of how bad the slow cases get.

Three findings are worth more than the headline:

• The subagent tool wasn't enough. With a neutral prompt, the model in the single-session setup never called it across 5 runs. With a delegate-first prompt it delegated in 4 of 5 runs, and the essay says that setup was still slower overall.
• Batching helped under load. Events that pile up during one model call get merged into the next, so time per decision fell as traffic rose. Each individual request got a little slower, though.
• Skipping the Router saves tokens. Removing direct thread routing barely changed completion time, but Router decisions rose about 30% and cache-read tokens about 37%.

What you can actually do with it

• Read the docs in order. The repo has nine numbered documents, from 000 Philosophy through to a cookbook for adding a new Source. They're useful even if you never install it.
• Try it on a test repo. Setup is built to be run by your coding agent, which reads SETUP.md and asks you one question at a time.
• Give it its own account. The setup guide recommends a dedicated GitHub account, a short allowed list, and leaving auto-merge off until its pull requests have been right for a while.
• Keep proactive work in `observe` mode. This is the default. It records what the agent would have done without doing it, while direct requests still work.

To run it you'll need Node.js 22.19+ or 24+, pnpm, git, Python 3.8+, tmux, the GitHub CLI, DeepSeek Harness and a model provider.

Limitations worth knowing

• It's a prototype. The README warns that it may contain bugs, and asks you to review and adapt it before use.
• It's not a sandbox. Workers run commands without approval as your OS user. The docs say the command wrappers and directories set defaults, "not a security boundary", and that a worker can still run a program by its absolute path.
• It's not the whole essay. The prototype covers a single GitHub repo, and the README says some designs in the essay are future directions that it doesn't implement.
• Async tools aren't on by default. DeepSeek says its asynchronous tool mechanism exists in DeepSeek Harness but isn't enabled by default yet.
• Security is still open. The essay names prompt injection, credential leaks and a compromised cloud loop controlling connected machines as unsolved problems.
• Agents act under your name. The docs are blunt about this: you're responsible for what it posts, and every message costs your colleagues attention.

The takeaways

1. 01Once agents get capable enough, your attention becomes the constraint. Judge an agent by what it costs you to supervise, not only by what it can do.
2. 02Separate the part that talks from the part that works. A Router that never does the job can stay available, and Workers can focus.
3. 03Let follow-ups go straight to the Worker that owns the thread. In DeepSeek's test, removing that raised cache-read tokens by about 37%.
4. 04Treat the numbers as a scheduling result from a synthetic test. They say nothing about code quality, so test on your own work.
5. 05Even if you never install it, you can copy the rule: agents act when asked and speak only when you must act or can use the result.