On November 1, the DeepSeek Harness team published a long post on X, “Exploring Super-Agent Design,” about Super-agent architecture. Roughly 15 hours after publication, the post had about 1.3 million views and 9.4K likes. This is an article about architectural concepts, not a product feature announcement.
In a nutshell: This design puts the system in charge of session management, so users interact through a single entry point. The Router handles incoming requests and assigns work, while Workers—sessions running in the background—execute tasks in parallel. People make high-level decisions and give final approval.
Why DeepSeek’s Super-agent Moves Beyond a Single Session
Today’s mainstream Agents still operate one session at a time. When users run multiple tasks, they have to switch sessions and keep track of context themselves. The DeepSeek Harness team’s experience is that one person can usually handle only three to five active sessions at once. That’s the team’s experience, not a universal statistic, but it points to a bottleneck: a single task is limited by the model’s capabilities, while multitasking is limited by human attention.
Adding command-line tools and external connectors to a local Agent only lets it receive external messages. Three limitations remain:
- Synchronous blocking: A classic ReAct loop, which alternates between reasoning and calling tools, waits for time-consuming operations to finish and can’t respond to new messages in the meantime.
- Context contamination: Intermediate details from different tasks get mixed together in the same window and interfere with one another.
- Device dependence: If the local device goes to sleep or offline, the Agent stops working.
The article therefore proposes decoupling the Agent from any single manually driven session and making it a continuous entity. It needs all four characteristics below. A single ReAct loop can’t deliver them on its own; they require supporting system architecture.
| Super-agent characteristic | In plain English | Main supporting modules |
|---|---|---|
| Continuous | It feels like the same Agent whether you’re talking in IM or on GitHub | Two-layer architecture, multichannel interaction |
| Efficient | It can accept new instructions before the previous command finishes and run tasks in parallel | Two-layer architecture, full-duplex interaction |
| Proactive | It monitors environmental events and acts when something needs attention | Event-driven architecture |
| Persistent | It stays online and recovers automatically from failures | Compute-state separation, Watchdog |
Breaking Down the Five Modules of DeepSeek’s Super Agent
Let’s start with an overview. Pay particular attention to the “Available now?” column: this article describes a design direction, not necessarily features you can use today.
| Module | Problem it solves | Key approach | Available now? |
|---|---|---|---|
| Two-layer architecture | Hard to balance continuity and concurrency | The Router handles interaction and delegates tasks; Workers execute them in isolation | The prototype has a similar workflow, but the full design requires a custom build |
| Event-driven operation | Agents can only wait for instructions, and events create too much noise | Code performs a quick filter, the model makes a considered judgment, and subscribed Threads are routed directly | The prototype can listen to GitHub, with optional Feishu support |
| Full-duplex, multichannel communication | Long-running tasks block conversations, while logs interrupt users | Asynchronous tool calls and response rules tailored to each channel | DeepSeek Harness supports asynchronous tasks, but they’re disabled by default |
| Separation of compute, state, and environment | Tasks stop when a device goes offline and can’t reach other environments | Run the loop in the cloud, store state in a database, and leave endpoints where they are | The original article doesn’t say this is publicly available; it requires a custom build |
| Watchdog | A process is still running, but the task is stuck or has gone off track | An independent session outside the main system checks on it periodically | The original article doesn’t say this is publicly available; it requires a custom build |
Module 1: DeepSeek Super Agent’s Two-Layer Router/Worker Architecture
Analogy: The Router is like a restaurant’s front desk: it welcomes guests and passes along orders. Workers are like the kitchen, where each station handles one dish.
Putting every event into one session preserves the most continuous context, but limits throughput. Starting a new session for every event increases concurrency, but loses global context and can lead to the confusion of multiple sessions replying to the user separately. The two-layer architecture separates these responsibilities: a long-running Router handles human interaction and global coordination, and it can even operate without a Bash tool. Workers have isolated contexts, each handles one task, and none speak directly to the user. Instead, they all report their status to the Router. The point is that sessions should be an implementation detail, not something users have to keep track of.
The Router might look like a bottleneck, but Triggers (events in the environment) that arrive during an inference round are queued and processed together in the next round. Its requests typically have long inputs and short outputs. The combined events are computed in parallel during Prefill (the first stage, when the model processes its input), so request time grows more slowly than batch size. The team’s experience is that the Router’s job is often simpler than expected, and a lightweight model is usually enough. To get started, you can access deepseek-v4.1-flash through APIYI · apiyi.com, try it as the Router, and measure how accurately it dispatches tasks.
Workers directly determine task outcomes and code quality, so the original article recommends using the strongest model available for them. On APIYI · apiyi.com, you can compare deepseek-v4-pro and claude-opus-5-5 on the same set of tasks before choosing a default model.
Module 2: Event-Driven Triggers for DeepSeek Super Agents
Analogy: A security guard checks visitors against a list and asks a manager about uncertain cases. Follow-up requests from existing clients go straight to the person already handling them.
For an Agent to work proactively, its primary input needs to shift from human prompts to events in its environment, such as group chat messages, CI results, and code review comments. Real-world event streams are noisy, though, and asking a Large Language Model to evaluate every event would be too costly in latency and compute. The article therefore proposes two layers of filtering:
- Fast Path (code-based filtering): Runs deterministic checks against allowlists for sources, groups, users, or bots. Each source can be configured to “respond only to explicit requests,” “treat as a candidate event,” or “ignore.”
- Slow Path (model-based evaluation): Only candidate events that pass the fast filter are sent to the LLM, which uses context and policies written in prompts to decide whether to act.
Routing also has fast and slow paths. Consecutive events on the same PR, IM topic, or email chain form a Thread. Once a Worker subscribes to it, subsequent events are passed directly through code without another Router decision. When multiple Workers subscribe to the same Thread, they receive the same notifications and can independently identify and resolve conflicts.
Context is managed like a cache. Information likely to be needed soon goes directly into the context window (Inline), while full details that are rarely used stay outside it, with only references or summaries kept in the window (Spill). The article also discusses acting ahead: checking calendars or reproducing issues in the background, delivering useful results and discarding the rest. This trades extra compute for less human waiting and intervention.
Module 3: Full-Duplex, Multi-Channel Interaction for the DeepSeek Super Agent
Analogy: You don’t need to stand by the kettle while it boils. It’ll let you know when the water’s ready, and you can keep talking to someone in the meantime.
Asynchronous ReAct replaces time-consuming calls with start() and stop(). start() returns immediately while the tool runs in the background. Once it finishes, the result is sent back to the conversation as a new event. The model can also use stop() to end a command that’s taking too long. This lets the agent process new user input as soon as the current reasoning step finishes. The original article explicitly says that DeepSeek Harness has implemented this asynchronous task mechanism, but it isn’t enabled by default yet.
Multi-channel interaction addresses how the agent communicates. On IM, messages should be lightweight and unobtrusive, with notifications only when a decision or sign-off is needed. One hard rule the team validated is a maximum of 100 words per reply. GitHub, email, and documents, on the other hand, need structured, information-dense output—for example, a PR should clearly explain the problem, the changes made, and the verification results.
Module 4: Separating Compute, State, and Execution Environments for the DeepSeek Super Agent
Analogy: Files are kept in the company archive, so employees can pick up where they left off even if they move desks. When a tool is needed on a particular machine, someone goes to that machine to use it.
The article describes decoupling in two steps. First, the agent loop runs in a stateless cloud container, while session state is stored in a database. Restarting or replacing the container doesn’t interrupt the task. Second, execution environments stay where they are. Each endpoint only needs a lightweight daemon—a small program that runs in the background. It doesn’t store session state; it only executes commands and returns results.
This design also supports BYOM (Bring Your Own Machine), connecting your own computer to a cloud-based agent. You don’t have to sync all your uncommitted changes and local credentials to the cloud. Once the device comes back online, the cloud agent can continue tasks that need to run on it. Anthropic’s “Decoupling the brain from the hands” takes a similar approach and is worth reading for comparison.
Module 5: External Monitoring with the DeepSeek Super Agent’s Watchdog
Analogy: A shift supervisor doesn’t do the work themselves. They check in regularly to see who’s stalled and who’s gone off track.
Many Agent failures aren’t crashes. The process is still running, but the model is stuck in a loop that produces no useful work—something traditional liveness probes can’t detect. The Watchdog is an independent session that runs outside the main system and is driven by scheduled messages. It handles infrastructure failures such as API errors and failed state recovery, while also using a model to judge whether each Worker is making meaningful progress. Maintainers can ask it “Why did this fail?” in plain language, or have it adjust prompts and trigger rules while the system is running.
What Can You Try with the DeepSeek Super Agent Prototype Today?
The companion repository is github.com/deepseek-ai/dsh-superagent-prototype. It’s licensed under MIT and had 8,636 stars and 863 forks when the data was retrieved on November 2, 2026. It’s a research prototype, not an official DeepSeek product, and it isn’t equivalent to the team’s internal version or the full implementation described in the article. Some of the designs discussed are future directions and haven’t been implemented in the prototype.
The prototype is a proactive coding Agent for a single GitHub repository, packaged as a DeepSeek Harness bundle. It monitors GitHub and can optionally connect to Feishu. When someone assigns it a task, it creates a work item, completes it in its own session and directory, then replies in the original conversation—for example, with a submitted PR. There’s also a web dashboard showing items that need human attention.
What Do the Two DeepSeek Super-Agent Experiments Show?
All figures below were reported by the authors in the official article. The experiments used synthetic workloads and simplified environments, and the authors say the results are for reference only. In the first experiment, each run involved about 300 messages, including roughly 20 work requests. Each design was tested five times. Coding work was simulated using tools that simply took time to run, so the experiment measured scheduling and coordination—not task quality.
In the table, p50 means half of the tasks were completed within that time, while p95 means 95% were completed within that time. Cache-read tokens are tokens read from the cache—reusing cached context directly rather than processing it again. The figures here are totals across all sessions.
| Design | p50 (minutes) | p95 (minutes) | Cache-read tokens / run |
|---|---|---|---|
| Super-agent | 12.4 | 15.7 | 23.2M |
| Without Pass-through | 12.6 | 15.5 | 31.8M |
| Single session + sub-Agents (neutral prompt) | 20.4 | 29.5 | 6.1M |
| Single session + sub-Agents (delegation-first prompt) | 13.8 | 29.0 | 10.8M |
With the neutral prompt, the model didn’t invoke a sub-Agent in any of the five runs. With the delegation-first prompt, it delegated in four of the five runs; in the other, the model considered the task small enough to handle itself. This suggests that, under this workload, the single-session design depended heavily on the prompt and the model’s judgment at runtime, while the two-layer architecture built delegation into the system. The trade-off is clear: Super-agent consumed significantly more cache-read tokens in exchange for shorter, more consistent completion times.
Removing Pass-through barely changed completion times, but increased Router decisions by about 30% and cache-read tokens by about 37%. So, under this workload, Pass-through didn’t speed things up—its main benefit was reducing Router overhead.
The second experiment stress-tested the Router layer on its own: the Router called a real model, while Workers used simulated models. The arrival rate of Triggers requiring Router decisions was gradually increased.
| Arrival rate (per minute) | Average batch size | Time per request | Amortized inference time per decision |
|---|---|---|---|
| About 1 | 1.0 | 2.5 seconds | 6.4 seconds |
| About 40 | 2.8 | 3.9 seconds | 1.6 seconds |
A single decision can involve multiple LLM requests, so the amortized time can be longer than the time per request. These figures support the conclusion that automatic batching can increase the Router’s effective throughput during bursts of events. But they don’t prove the same results would hold in a real production environment, and they don’t tell us about task quality or performance across different codebases.
Four Open Questions About the DeepSeek Super-Agent
The article explicitly acknowledges that the following questions remain unresolved. They should be factored into any implementation assessment:
- How should the architecture scale? For larger, more tightly coupled tasks, there’s no clear answer on whether to shard the Router, how granular those shards should be, or when Workers should communicate directly. Finer-grained sharding increases concurrency, but leaves less shared memory and context. Long-term memory is also a major bottleneck.
- How do you use it without sessions? New interaction methods are needed to show tasks and let people intervene on key details without interrupting background work.
- Context boundaries and A2A: A2A (agent-to-agent) broadly refers to communication and collaboration between agents. As an organization grows, configuring a Super-agent effectively means deciding which context to share and which to isolate. How to collaborate securely across permission boundaries remains an open question.
- Security and privacy: This is the issue that most urgently needs assessment. The cloud loop continuously receives external events, while endpoints hold private code and local credentials. If the server is compromised or the loop is breached through prompt injection (malicious instructions hidden in inputs), connected endpoints could be taken over. The article argues that agents need a way to “use credentials without seeing them.”
A Minimal DeepSeek Super Agent Checklist for Small Teams
The sequence below is our suggested approach based on the original article, not an official roadmap. Start with a pilot in a single repository and within a trusted environment. Hold off on Router sharding for now.
Step 1: Separate the Router and Workers
- Code: Set up an always-on Router entry point without access to Bash tools. Create a separate Worker for each task, with its own context and working directory. Workers report results only to the Router.
- Models: Use a lightweight model for the Router and a more capable model for Workers. Configure them separately so you can replace either one independently.
- People: Communicate only with the Router. Define task boundaries, handle requests for decisions, and give final approval.
Step 2: Add Trigger Filtering
- Code: Configure a source allowlist and a three-tier policy. Map PRs and IM topics to Threads, and pass subsequent events for subscribed Threads directly to the Worker.
- Models: Use semantic evaluation only for candidate events to determine whether to act and whether to start a new Worker.
- People: Use prompts to define the conditions for action. Regularly spot-check false triggers and missed triggers, then adjust the allowlist and policies.
Step 3: Add a Watchdog
- Code: Deploy it outside the main system and drive it with scheduled messages. Have it check for infrastructure issues such as API errors and failed state recovery.
- Models: Read Worker progress logs to determine whether a Worker is making meaningful progress, stuck, or drifting away from its goal.
- People: Set the Watchdog’s remediation permissions, approve its changes to prompts and trigger rules, and review the causes of failures.
From day one, avoid putting production credentials directly into model context, and configure permissions according to the principle of least privilege. Asynchronous tool calls and compute separation can wait until the first three steps are running reliably and you’ve actually encountered blocking or device-offline issues.
Model Choices and Cost Estimates for a DeepSeek Super Agent
The table below shows prices from the APIYI · apiyi.com model list as of 2026-11-02, in $/1M tokens. Check the platform’s model list for current availability and pricing; actual charges are shown in the console.
| Model | Input | Output | Cache Read |
|---|---|---|---|
| deepseek-v4.1-flash | 0.3 | 1.2 | 0.006 |
| deepseek-v4-flash | 0.44 | 1.32 | 0.01408 |
| deepseek-v4-pro | 1.32 | 3.96 | 0.043996 |
| claude-opus-5-5 | 4 | 20 | 0.2 |
The figures below are estimates based on published prices, not measured results. They assume 20,000 input tokens and 2,000 output tokens per call, excluding cache costs:
deepseek-v4.1-flashcosts approximately $0.0084,deepseek-v4-proapproximately $0.0343, andclaude-opus-5-5approximately $0.12.- One Router call using
deepseek-v4.1-flashand one Worker call usingdeepseek-v4-procost approximately $0.0427 in total. Usingclaude-opus-5-5for both costs approximately $0.24, about 5.6 times as much. - At 20 sets of calls per day with the same usage, the mixed setup costs approximately $0.85, while using
claude-opus-5-5for everything costs approximately $4.8. A real Worker often makes more than one call, so recalculate using the token counts in your own logs.
For long-running systems, calculate cache-read costs separately. Based on the 23.2M cache-read tokens in the experiment, the estimated cost would be approximately $0.14 if all were billed at the deepseek-v4.1-flash rate, $1.02 at the deepseek-v4-pro rate, or $4.64 at the claude-opus-5-5 rate. These figures are only order-of-magnitude estimates: the experiment didn’t disclose the token distribution across layers, and they don’t include input or output costs.
It’s best to make the Router and Worker models configurable. With APIYI · apiyi.com, you can switch between these models using one API key. The OpenAI-compatible interface uses https://api.apiyi.com/v1 as its base_url, so switching mainly involves changing the model name. That makes it easy to compare quality and cost on the same set of tasks. Price is only half the decision, though: the Worker’s default model should also depend on task success rates and how much rework it requires.
The chart above is estimated using the default prices in the APIYI · apiyi.com model list. Substitute your own token usage before budgeting.
DeepSeek Super-Agent FAQ
Q1: Is this a new model?
No. The article discusses Agent system architecture, focusing on how the surrounding system organizes sessions, events, state, and monitoring. No new model has been released.
Q2: Can developers use it directly?
The five modules aren’t available as an out-of-the-box solution. For now, you can try the research prototype or build your own system based on the ideas in the article. The only existing implementation explicitly mentioned in the original article is DeepSeek Harness’s asynchronous task mechanism, which is disabled by default.
Q3: Is dsh-superagent-prototype an official product?
No. Its README states that it’s for research reference only. It’s not an official DeepSeek product, nor is it equivalent to an internal version or the complete implementation described in the article.
Q4: Does using multiple Agents cost more?
In these experiments, cache-read token usage was indeed higher: 23.2M for the Super-agent versus 6.1M to 10.8M for the single-session approach. In return, completion times were shorter and more consistent. Actual total costs also depend on the mix of models and the scale of the task. Using a lightweight model for the Router and enabling Thread passthrough can both help control costs.
Q5: How can I access these models from China?
You can sign up through APIYI · apiyi.com and get an API key. New users receive free test credits. Then change your client’s base_url to the address provided above and enter a model from the table in the model parameter. These DeepSeek and Claude models support the chat and messages endpoints. It’s a good idea to test with low traffic before going live.
Summary
The value of the DeepSeek Super Agent article lies in applying classic systems engineering principles to agents. Here are the key takeaways:
- The problem: Individual tasks need less human involvement, so human attention is becoming the bottleneck when managing multiple tasks.
- Five modules: A two-layer architecture, event-driven design, full-duplex multi-channel communication, separation of compute, state, and environment, and a Watchdog support four characteristics: continuity, efficiency, proactivity, and persistence.
- Limits of the evidence: Both experiments are based on synthetic workloads reported by the author, so they should be treated as design references only.
- Implementation order: Start by separating the Router and Worker, add Trigger filtering, and then add a Watchdog. Keep security boundaries front and center throughout.
You don’t have to settle on a model combination all at once. Use APIYI · apiyi.com to run a small-scale comparison on the same set of tasks, then choose your configuration based on success rates and costs.
First, stop being the “human Router.” Then think about adding more agents.
Author: APIYI Technical Team
Technical discussions: Contact us through the APIYI website homepage. For more resources, visit the documentation center at docs.apiyi.com.
