DeepSeek unveils “Super-agent” that finds bugs and submits its own fixes

What this is about

On the evening of October 31, 2026, the DeepSeek Harness team published a technical article on its official WeChat channel titled "Super-agent Design Exploration: Toward a More Autonomous Agent System." It is the team's first systematic description of an agent architecture for multi-task and team scenarios. According to DeepSeek, an internal Super-agent is already used in day-to-day development. It helps reproduce and fix bugs, responds to code reviews, and even drives iterations of DeepSeek Harness itself.

A key caveat (according to BigGo Finance): this is an exploration at the level of engineering practice, not a standalone, officially released product. Some parts are implemented in the open-source prototype plugin dsh-superagent-prototype (GitHub: deepseek-ai/dsh-superagent-prototype). As QbitAI notes, it is not the "dsh dot" some had expected.

The problem: humans can only keep track of a few sessions

Most agents today treat a session (a self-contained conversation and work context) as the smallest unit. Different sessions know nothing about each other. Developers, however, constantly switch between platforms. They discuss a solution in chat, push the code to GitHub, then make changes after comments on the pull request (PR, a proposed code change). With classic coding agents, these steps live in separate sessions, and you have to keep the overview and supply context yourself.

The team observes that a person can typically follow only 3 to 5 active sessions at once. So while models keep getting better at single tasks, human attention becomes the limit on how many tasks can run in parallel. Even with CLI and MCP integrations, the team says problems remain: serial processing within a session, mixed-up context across several tasks, and interruptions when the local device goes offline.

The architecture: router, workers and subscriptions

DeepSeek defines four properties of a Super-agent: continuous (context persists across sessions and platforms), efficient (multiple tasks run in parallel, and long tasks block nothing), proactive (it watches its environment and acts when needed) and persistent (it runs around the clock and tries to recover from errors).

There are two layers:

• Router: an always-on coordinator. It receives messages from group chats, GitHub and email, assigns tasks and holds the overall context.
• Worker: individual agent sessions with their own context and tools, for example for bug reproduction, code review or feature development. They can call subagents when needed and report results to the router, which talks to you with everything consolidated.

To you, it stays the same assistant, even though several agents may be working in the background. To cut coordination overhead, there is a subscription/direct pass-through mechanism: once a worker takes over a GitHub PR, later comments go straight to it without a detour through the router. According to BigGo, the article argues that the router mainly has to understand and distribute information, so a relatively lightweight model is enough. Stronger models are reserved for the actual execution.

Here is an example from the team: a group chat settles on solution A, and later someone asks for solution B in a GitHub comment. The Super-agent recognizes that both belong to the same piece of work and adjusts course.

Proactivity: filters, speculative execution, async loop

Chat messages, emails, calendar reminders, GitHub comments and CI test results count as triggers. Because most chat messages don't need AI, the system filters in two stages. First, programmatic rules weed out irrelevant items. Then a large model decides whether to act. This saves tokens.

Then there is speculative execution, an idea from computer engineering: the agent tries something in the background before it's clear whether the result will be needed. If a bug comes up in chat, the Super-agent reproduces it and looks for the cause. It only speaks up if the bug exists and there is a comparatively simple fix. Otherwise it stays quiet. Similarly, a personal assistant could check for conflicts, gather material and prepare a reply when someone asks for a meeting.

The async ReAct loop (ReAct: a pattern in which a model alternates between reasoning and using tools) moves time-consuming tool calls into the background, so the session keeps accepting messages. It is implemented in DeepSeek Harness but not yet enabled by default.

For continuous operation, DeepSeek separates compute, state and working environment. The execution loop runs in the cloud, session state lives in a database, and code, files and toolchain stay on your device. Only a lightweight daemon (background service) runs locally. If the device goes offline briefly, work can resume afterward. An independent watchdog acts as an AI supervisor. It checks whether tasks are making progress or stuck in endless loops, and tries to repair them.

Measurements

The team tested with simulated chat and GitHub CI message streams: about 300 messages per run, roughly 20 of them real work orders, five repetitions each. The baseline was a classic approach with one session plus a subagent.

According to BigGo, the difference comes mainly from how tasks are distributed. Under a neutral prompt, the model never called a subagent in five runs and was constantly interrupted by new messages in the main dialogue. The price: without event pass-through, router decisions rose by about 30% and cache-read tokens by about 37%. When the event rate rises from about 1 to 40 per minute, the latency of a single request grows only from 2.5 to 3.9 seconds, the team says, because the router batches messages. The team stresses that it used synthetic messages and simulated tools. Real code quality was not evaluated.

Background: DeepSeek Harness

According to InfoQ, DeepSeek Harness (dsh) is an open-source runtime for autonomous agents under the MIT license, released as a developer preview. It is built on the Cordis meta-framework and uses a micro-kernel architecture. Model adapters, tool registry, sandboxes, session state, event dispatcher and interfaces are all swappable plugins. An append-only event log records every message and tool call. Version 0.1 has four modes: Standard, Code, Minimal and Creator. InfoQ points out that extension interfaces may still change.

As an aside, Geeky Gadgets reports on DeepSeek 4 models (Pro with 1.6 trillion and Flash with 284 billion parameters, 1 million tokens of context). That is a separate topic and is mentioned here only for context.

Open hurdles

According to BigGo, DeepSeek itself names open problems. These include long-term memory over weeks or months, and security and privacy (prompt injection or server attacks could endanger repositories, sensitive data and local credentials). They also include new interaction concepts when many tasks run in parallel, such as how users see progress, step in, and which steps need manual approval. The team admits it is not offering an entirely new theory. Instead, it applies classic systems ideas (scheduling, cache management, event control, separating storage from compute) to agents.

Our take

This release is mainly an architecture paper with a prototype, not a product. It is interesting for developers building agent systems, because it shows how a router/worker split can ease the bottleneck of human attention. The numbers come from the vendor itself, from a small test (5 runs) with synthetic data. The baseline was also especially weak under a neutral prompt, because it never used subagents. Whether this works in real teams, with real code quality and acceptable costs, is an open question. So are the security issues of an agent that continuously reads external messages and accesses devices.