# DeepSeek Super-agent: Moving Agents from One-off Conversations to Continuous Autonomous Operation


![](https://leafw-blog-pic.oss-cn-hangzhou.aliyuncs.com/deepseek-superagent-cover.png)

On October 31, the DeepSeek team published an article, "Exploring Super-agent Design: Toward More Autonomous Agent Systems," discussing what architecture the next generation of agent systems should adopt.

The article also released an open-source research prototype: dsh-superagent-prototype.

What makes this article interesting is that it doesn't keep talking about how to improve a model's reasoning, how to design prompts, or how to get multiple agents to collaborate better on a single task. Instead, it focuses on a more fundamental question:

Once agents can already complete complex tasks on their own, how do we design an agent system that can run for long periods, handle multiple tasks at once, and minimize human intervention?

This involves not only an agent's reasoning ability, but also classic software engineering problems such as task scheduling, event-driven design, context management, and system reliability.

This post introduces the Super-agent architecture proposed by DeepSeek and several of its designs worth paying attention to.

## 1. What's Wrong with Today's Agents?

Over the past year, coding agents have become noticeably more capable.

For example, with tools like Claude Code and Codex, we can hand over a fairly complex development task and let the agent read the code, modify files, run tests, and finally submit the result on its own.

But problems show up when we handle multiple tasks at the same time.

Suppose there are three tasks:

1. Fix a bug in production.
2. Build a new API endpoint.
3. Review a Pull Request.

We usually need to open three separate agent sessions.

Each session has its own context, and we have to follow up on each one's progress separately. If one task needs to reference another task's result, we may even have to copy information over by hand.

Worse, when a task has been running for ten-plus minutes, we may have to go back and check whether it has finished or run into trouble.

DeepSeek notes in the article that, based on their observations, a person can typically keep track of only 3 to 5 active sessions at once.

This leads to a problem:

Single-task execution is mainly limited by the model, while multi-task execution starts to be limited by human attention.

Traditional agents also have a few other issues:

- Synchronous blocking: while a session is running a long task, new requests often have to wait.
- Context confusion: multiple tasks sharing context can easily interfere with each other.
- Lack of proactivity: most agents need the user to explicitly start a task.
- No persistence: once the local device shuts down, the agent stops too.

DeepSeek believes that solving these problems requires freeing agents from the limits of a single session.

Hence the Super-agent.

## 2. What Is a Super-agent?

DeepSeek defines four basic characteristics of a Super-agent:

| Characteristic | Meaning |
| --- | --- |
| Continuous | Maintains a unified task context across different sessions and communication channels |
| Efficient | Responds to users quickly while executing multiple complex tasks in parallel |
| Proactive | Observes external events and initiates tasks on its own at the right time |
| Persistent | Stays online long-term, with support for failure recovery and cross-device operation |

A software development scenario helps illustrate this.

Suppose a team is discussing a bug in a Feishu group chat.

A traditional coding agent works like this:

A developer finds the bug, opens the coding agent, describes the problem, and asks it to analyze the code and fix it.

A Super-agent aims for a different way of working:

It continuously watches authorized team messages. When it spots a message that may involve a software defect, it proactively analyzes the issue and, when necessary, spins up an independent Worker to reproduce the problem and attempt a fix.

Once the fix is done, it can create a Pull Request and report the result back in the original Feishu discussion.

If someone leaves review comments on GitHub, the agent can keep handling them.

The whole process can span different platforms such as Feishu and GitHub.

DeepSeek's article shows similar practice from its internal instance, including identifying an issue in a public group chat and submitting a fix PR without being explicitly @-mentioned.

However, achieving this clearly takes more than adding a few tools or MCP servers.

This brings us to the most important design in Super-agent: the two-layer architecture.

## 3. Two-Layer Architecture: Router and Worker

DeepSeek splits the Super-agent into two logical layers:

- Router: handles unified interaction, global context, and task dispatch.
- Worker: handles the execution of specific tasks.

The overall structure is shown below:

![The Router layer handles unified routing and external interaction, while multiple Workers execute concurrently in isolation](https://leafw-blog-pic.oss-cn-hangzhou.aliyuncs.com/deepseek-superagent-router-worker.jpg)

### 3.1 Router: Coordinates Only, Doesn't Execute

The Router is a resident global coordination layer.

It receives messages from different channels, understands user intent, maintains cross-task information, and hands concrete work off to Workers.

There's an important design choice here:

The Router stays out of the execution of specific tasks as much as possible.

For example, suppose a user asks to fix a bug.

The Router doesn't need to read the entire code repository, analyze call chains, or modify files itself.

It only needs to determine that this is a development task requiring execution, then create or find the corresponding Worker.

The Worker does the actual work and reports the result back to the Router.

This division of responsibilities prevents the Router from being blocked by time-consuming tasks.

DeepSeek even mentions that the Router can be configured without a Bash tool, since it doesn't need to operate on the execution environment directly.

Because the Router handles high-level task association and interaction, a lighter-weight model can be considered for it to reduce response latency and inference cost.

### 3.2 Worker: Independent Context, Parallel Execution

Workers are the agents that actually do the work.

Each Worker has its own session and execution environment and can use tools like the file system, terminal, and code repository.

For example:

- Worker A is investigating a database connection pool issue.
- Worker B is building a new endpoint.
- Worker C is reviewing a Pull Request.

All three Workers can run at the same time without their contexts interfering with each other.

Because Workers directly determine the quality of task completion, they usually need a more capable model.

In addition, Workers don't message users directly; they report task status and results through the Router.

This prevents multiple Workers from messaging the user at once and creating a chaotic interaction.

### 3.3 Why Not Just Use Multi-Agent?

At this point, you might think this looks a lot like a traditional multi-agent architecture.

Indeed, both have one coordinator and multiple executors in form.

But their design goals differ.

A traditional agent team usually revolves around a single complex task.

For example, when building a system, a main agent handles planning and then assigns different sub-agents to build the frontend, backend, and tests.

The main agent must be deeply involved in task decomposition, progress coordination, and result integration.

The Super-agent's Router, by contrast, focuses more on continuity across tasks.

It doesn't need to know how each step inside a Worker is executed; it only needs to know what the task is, who's responsible, what the current progress is, and when the user needs to be notified.

So the separation of Router and Worker is essentially isolating global coordination from concrete execution at the system architecture level.

This also means a Super-agent doesn't require every task to use multi-agent internally.

A Worker can perfectly well use a single-agent loop, combined with skills and tools, to complete its task.

## 4. Event-Driven: Giving Agents Proactivity

The main interaction model for traditional agents is the user initiating a request.

A Super-agent, on the other hand, needs to continuously observe the external environment.

For example:

- A new issue appears on GitHub.
- A Pull Request receives a new review comment.
- Someone in a Feishu group reports a system anomaly.
- A background task finishes.
- A scheduled inspection finds an anomaly.

All of these can be events that trigger the agent to act.

But there's an obvious problem here.

If every event were sent straight to the LLM, cost and system load would be very high.

Especially in enterprise settings, a team may generate a huge number of messages every day, the vast majority of which don't need the agent's attention.

So DeepSeek designed an event filtering and dispatch mechanism.

### 4.1 Fast and Slow Paths

Event handling can be understood as two stages.

First, events are filtered with fast, deterministic rules.

For example:

- Is the message from a user who is allowed access?
- Does it belong to a task that's already subscribed?
- Is it a duplicate event?
- Does it meet a predefined trigger condition?

This logic can be handled by ordinary code without calling an LLM.

Events that can't be decided directly by rules are then passed to the model for semantic analysis.

For example, someone in a group chat says:

> Since yesterday's release, the report API seems to be timing out a lot.

This message doesn't explicitly ask the agent to fix anything, but it may be worth looking into.

The model can use the context to judge whether it's a software defect that needs handling.

The value of this design is that it minimizes pointless model calls while keeping the ability to process unstructured information.

### 4.2 Subscriptions and Pass-through

Not every event needs to go through the Router.

Suppose Worker A is working on a GitHub issue.

It can subscribe to the corresponding issue or Pull Request.

When someone comments on that PR, the event can be sent directly to Worker A.

This way, the Router doesn't have to re-decide which Worker should handle it every time.

For long-running agents, this subscription mechanism is important.

Because a task may last tens of minutes, or even span multiple days.

If a new session were created for every event, it would be hard to keep the task context continuous.

### 4.3 Speculative Execution

The article also discusses a rather interesting design: Speculative Execution.

The idea is that when the system thinks an event may need handling, it can start some of the work in advance without notifying the user right away.

For example, someone in a group chat reports that an API is misbehaving.

The agent can first read the relevant logs in the background, locate the code, and even try to reproduce the problem.

If it ultimately decides this is a task worth handling, it keeps going.

If it decides there's no need, it stops.

This resembles speculative execution in computer systems: doing potentially valuable work ahead of time to reduce later waiting.

Of course, speculative execution also consumes compute, so resource budgets and operation permissions need to be limited.

## 5. Full-Duplex Interaction: Communicating Anytime, Even While Tasks Run

A traditional ReAct agent usually runs in the flow of "user input, model thinking, tool call, observe result, keep thinking, final reply." The upper half of the figure below shows this synchronous approach:

![Classic ReAct vs. async ReAct: an async call immediately returns "started," and the agent can still respond to new messages while tools run in the background](https://leafw-blog-pic.oss-cn-hangzhou.aliyuncs.com/deepseek-superagent-async-react.jpg)

During a long task, the user often has to wait.

If they want to add requirements midway, they may find that the new input can't be handled in time, or that the current task has to be interrupted.

A Super-agent aims for full-duplex interaction.

For example:

> User: Help me fix the timeout issue in the order API.
>
> Agent: I've started investigating.
>
> User: Check the slow database queries first.
>
> Agent: Got it, I've passed that on to the Worker running the task.
>
> User: Also, take a look at yesterday's release records.
>
> Agent: I've created another task and started working on it.

Throughout this process, the original Worker can keep executing.

The Router always stays responsive.

The key here is that human interaction and background task execution have different lifecycles.

Sending a message doesn't require waiting for background tasks to finish, and background tasks don't need to be interrupted because the user sent a new message.

In addition, the agent needs to adjust how it communicates depending on the channel.

For example, it should be as concise as possible in an IM group chat, while on a GitHub PR it can provide more detailed technical analysis.

This design reduces how much of the user's attention the agent takes up.

## 6. Separating Compute, State, and Environment

If you want an agent to run continuously, you need to solve another problem:

What happens when the local computer shuts down?

Traditional coding agents usually run in a local terminal.

The local computer going to sleep, a network interruption, or a process exiting can all stop a task.

DeepSeek proposes separating compute, state, and the execution environment, as shown below:

![Decoupling compute, storage, and execution environment: the cloud agent loop is separated from persistent state and connects to execution environments on demand via an on-device daemon](https://leafw-blog-pic.oss-cn-hangzhou.aliyuncs.com/deepseek-superagent-compute-storage-split.jpg)

The agent's reasoning and task management can run continuously in the cloud.

The local device serves as a connectable execution environment, providing capabilities like file access and app operations on demand.

Even if the user shuts down their computer, the cloud agent can still handle tasks that don't depend on the local device.

From an engineering perspective, this design also helps with task recovery.

For example, after a Worker process exits abnormally, the system can resume execution from the persisted task state.

There's one thing to watch out for here, though.

Persisting a session doesn't simply mean saving the full chat history.

A real system also needs to save task state, tool execution results, event processing progress, and necessary context information.

Operations with side effects especially require thinking about idempotency.

For example, if the agent hits an error after creating a Pull Request, it must not create a duplicate PR when it recovers.

These are all engineering problems that need to be solved when building long-running agents.

## 7. Watchdog: An Agent That Supervises Agents

Long-running agents can also run into another kind of problem: execution spiraling out of control.

For example:

- Repeating the same tool call over and over.
- Staying stuck in a wrong direction for a long time.
- Retrying endlessly after hitting an error.
- Drifting away from the original task goal.
- Burning lots of tokens without making real progress.

Traditional agents can rely on users to notice these problems and intervene manually.

But the goal of a Super-agent is precisely to reduce human monitoring.

So DeepSeek introduced a Watchdog mechanism.

The Watchdog can be thought of as an external supervisor.

It periodically checks the agent's execution state and judges whether the task is progressing normally.

For example:

![Watchdog supervision flow: periodically check Worker status and execution records; continue if normal, trigger a recovery strategy if abnormal](https://leafw-blog-pic.oss-cn-hangzhou.aliyuncs.com/deepseek-superagent-watchdog-flow.png)

The Watchdog can watch signals such as task runtime, repeated behavior, error frequency, and progress changes.

When it detects an anomaly, it can take measures such as replanning, restarting the Worker, pausing the task, or requesting human intervention.

It's worth emphasizing that the Watchdog itself can also misjudge.

So for production systems, a more reasonable approach is to combine deterministic monitoring with model judgment.

For example, timeouts, resource usage, and retry counts can be checked by code, while whether a task has drifted from its goal may require semantic analysis by a model.

## 8. Experimental Results: What Does the Two-Layer Architecture Bring?

DeepSeek's article also compares the task execution efficiency of different architectures through experiments.

Task completion time is the metric worth focusing on.

According to the experimental results disclosed in the article:

| Metric | Super-agent | Single-session with sub-tasks baseline |
| --- | --- | --- |
| p50 task completion time | 12.4 min | ~20 min |
| p95 task completion time | 15.7 min | 29.5 min |

This shows that under their test conditions, Super-agent not only improved median task completion time but also significantly reduced tail latency.

More interestingly, the team also tried optimizing the baseline with prompts to make the main agent dispatch tasks more aggressively.

After optimization, p50 dropped to about 14 minutes, but p95 stayed close to 29 minutes.

This suggests that tweaking scheduling strategy through prompts alone may struggle to solve system-level blocking.

Of course, Super-agent has its costs too.

In the disclosed experiments, Super-agent's cache-read token volume was clearly higher than the baseline's, with some metrics approaching four times as much.

So there are still trade-offs among throughput, responsiveness, and inference cost.

These experimental figures also need to be understood in the context of the test tasks, concurrency scale, and execution environment; they can't be generalized to mean every agent system will see the same performance gains.

## 9. What's the Value of This Architecture from an Agent Engineering Perspective?

After reading the article, I think a few points stand out.

### 9.1 Sessions Should Become an Internal System Concept

Many agent products today expose sessions directly to users.

Users have to create sessions, manage context, and remember what each session is doing.

But from a product design standpoint, this actually pushes low-level implementation details onto the user.

For a long-running agent, what users really care about is tasks.

For example:

- How far along is the order API bug fix?
- Is the code review I scheduled yesterday done?
- Has the optimization plan mentioned last week been implemented?

How many sessions each of these tasks used is usually something users don't need to know.

So future agent systems may increasingly emphasize higher-level objects like Task and Project, while hiding sessions internally.

### 9.2 Agent Runtimes Will Look More and More Like Traditional Distributed Systems

Many of Super-agent's designs have counterparts in traditional computer systems.

| Agent system design | Similar concept in traditional systems |
| --- | --- |
| Router | Scheduler, coordinator node |
| Worker | Worker process, task executor |
| Trigger | Event, message |
| Subscription | Publish/subscribe |
| Session State | State persistence |
| Watchdog | Health check, fault monitoring |
| Speculative Execution | Speculative execution |
| Context Isolation | Process isolation, task isolation |

This means that as agent systems grow more complex, a lot of experience from traditional software engineering will become important again.

Things like message queues, task scheduling, state machines, idempotency, failure recovery, and resource isolation.

The model handles understanding and decision-making, while the system architecture ensures tasks run reliably.

### 9.3 Proactivity Needs Permission Boundaries

Super-agent's proactivity is very appealing, but it also brings risks.

For example, after the agent sees someone report a problem in a group chat, should it immediately modify the code?

Once the change is done, can it merge the PR automatically?

If the agent can operate on production, how should its permissions be limited?

These questions can't be left entirely to the model's own judgment.

In real deployments, clear permission controls, operation approvals, and audit mechanisms are still needed.

Especially for high-risk actions like production releases, data deletion, and financial operations, necessary human confirmation steps must be kept.

### 9.4 Proactive Execution Doesn't Mean Constantly Bothering the User

I think this is an easily overlooked aspect of Super-agent.

If an agent merely turns task statuses that users used to check on their own into a constant stream of messages, it hasn't really reduced management overhead.

A good Super-agent should be able to judge:

When does the user need to be notified?

When should it keep running in the background?

When does the user need to make a decision?

When does it just need to log the result?

So beyond task completion rate and execution time, the human attention consumed per task may also become an important metric for evaluating agent systems in the future.

## 10. The Open-Source Prototype and Real-World Adoption

DeepSeek also released a research prototype:

https://github.com/deepseek-ai/dsh-superagent-prototype

The project is built on DeepSeek Harness and targets development workflows for a single GitHub repository. It can listen to GitHub events and optionally integrate with Feishu.

It creates tasks based on authorized users' requests or preconfigured rules, executes them in independent agent sessions and working directories, and reports results back through the original interaction channel.

However, the official README also states clearly:

> This project is a research prototype and is not yet production-ready.

The public version isn't fully identical to the internal implementation, and some of the architectural designs in the article haven't been implemented in the open-source prototype yet.

So for now it's better treated as an architectural reference for agent runtimes than as something to use directly in production.

## Summary

The core question DeepSeek's article tackles is how to evolve agents from single-task execution tools into systems that can work continuously.

The key designs it proposes include:

1. A two-layer Router and Worker architecture that separates global coordination from task execution.
2. Event-driven and subscription mechanisms that let agents proactively respond to changes in the environment.
3. Full-duplex interaction so that user communication and background task execution don't block each other.
4. Separating compute, state, and environment to support long-running operation and failure recovery.
5. A Watchdog that supervises execution to reduce the cost of human monitoring.

None of these designs depend on a particular model.

As models keep getting better at tool use and complex task execution, the bottleneck of agent systems will gradually shift from single-pass reasoning to concurrent scheduling, context management, runtime reliability, and human-AI collaboration efficiency.

From this angle, the significance of Super-agent is that it starts designing agents as software systems that need to run for the long term.

Going forward, competition among agents will come down not only to how complex a task the model can complete, but also to how continuously and reliably the system can complete those tasks at how low a human management cost.

## References

- DeepSeek: "Exploring Super-agent Design: Toward More Autonomous Agent Systems" (in Chinese): https://mp.weixin.qq.com/s/zoS7GlReWPhfCjENGxXCdg
- DeepSeek Super-agent open-source prototype: https://github.com/deepseek-ai/dsh-superagent-prototype