On the evening of October 31, 2026, the DeepSeek Harness team published the underlying architecture of Super-agent, an autonomous agent exploration project. The design thinking is laid out in a technical article titled "Super-agent Design Exploration: Toward a More Autonomous Agent System." What makes this open source release worth attention is not another chatty model. It is that the team hands the job of "conversation orchestration" back to the system layer, the part that used to sit on human shoulders. In other words, it lets AI manage AI. The companion DeepSeek Super-agent open-source repository is already public. According to a direct GitHub API check, the repository is released under the MIT license, was created on October 31, 2026, and had gathered roughly 9,374 stars as of November 2, 2026. Its primary language is TypeScript, its default branch is main, and its description reads "Towards a More Autonomous Agent System." That means you can clone the code today and, following its blueprint, build an agent that stays online, runs multiple tasks at once, looks for work on its own, and recovers from its own failures.
What It Tries to Solve: The Human Becomes the Bottleneck
In many multi-agent systems today, the real bottleneck is not the model. It is the human. You assign a task to an agent, it finishes one job and then stalls waiting for your next instruction. You assign another, it waits again. Once tasks grow in number and complexity, the human becomes the slowest node in the whole chain: constantly distributing work, collecting results, and deciding what comes next. The DeepSeek Harness team says in its technical article that what they want to build is an agent that stays online, handles many things at once, actively looks for work, and recovers from failures on its own.
Notice that the goal is not a "smarter single-point model." It is a scheduling system that looks more like a computer system. The team ports ideas that have been proven repeatedly in classical engineering, such as scheduling, caching, storage-compute separation, and the Watchdog, directly into the agent architecture. This is also why the center of gravity in this release is the "architecture" rather than "model weights." What it delivers is a methodology for making agents run autonomously, with the focus landing on how the system layer takes over conversation orchestration.
Looking back at the trajectory of agent development, the past year was largely spent racing on single-agent tool use, context length, and reasoning depth. Super-agent points to a different dimension. As the number of agents grows and tasks get longer, the bottleneck shifts from "how smart a single agent is" to "whether the whole system can orchestrate itself." This open source release puts that long-overlooked dimension squarely on the table.
The Two-Layer Architecture: Router Dispatches, Worker Executes
The core layer of the whole architecture is a two-layer structure, the pairing of Router and Worker.
The Router layer is a permanently resident global router. It handles human interaction and global coordination. Its principle is clear: it only dispatches tasks, it does not do the work itself. This yields two direct benefits. First, because the Router performs no concrete execution, it can batch multiple decisions together and amortize the inference cost. Second, the Router can avoid mounting dangerous execution tools such as Bash, and can even run a lighter-weight model, so it runs faster and consumes fewer resources. A lightweight role that only schedules is naturally suited to staying online all the time.
The Worker layer is context-isolated from the Router. Each Worker mounts a complete set of execution tools and runs concrete tasks concurrently. After a Worker finishes, it reports the result back to the Router, which then replies to the outside in a unified way. This avoids the chaos of multiple sessions each replying on their own and talking over one another. There is a single outward mouth, while internally everything can run in parallel without limit.
You can understand the division like this: the Router is like a project manager who is always on duty and never writes code, only breaking down tasks, assigning them, and wrapping up. The Workers are like engineers working in parallel, each focused on finishing their own assigned piece, and finally everything is consolidated and shipped out by the manager. This separation of duties is the key landing point for "the system layer taking over conversation orchestration." What it solves is the old problem of "agents fighting their own battles while the human tires of coordinating them."
Event-Driven: Don't Let the Agent Wait for Orders
If an agent can only wait passively for human instructions, it is still just a slightly smarter script. Super-agent introduces an event-driven mechanism precisely to make the agent proactive.
Various events in the environment, a new message popping up in a group chat, a newly arrived email, a CI build result, are all abstracted into a unified Trigger. These Triggers are not dumped on the model all at once. They first pass through a two-level filter: a program performs fast screening to block obviously irrelevant noise, and then a semantic model makes a slower judgment to decide which events truly deserve the agent's attention. This wastes no inference and misses no critical signal.
More interesting is the "subscription and direct delivery" mechanism. Once a Thread has been picked up by a Worker, subsequent events from that Thread are sent directly to the corresponding Worker, bypassing the Router and its global routing. It is as if, once the agent claims a thing, it keeps watching it, instead of starting from zero and queuing up again every time. The GitHub repository shows that this subscription direct-delivery mechanism significantly reduces the Router's redundant decisions, and is a key design for easing pressure on the global router.
On top of that there are two more threads: asynchronous multi-channel interaction and storage-compute separation. Asynchronous multi-channel lets the agent watch multiple sources, email, group chat, code repository, at the same time. Storage-compute separation splits "state storage" from "compute execution," so Workers can scale up and down statelessly while state is managed centrally. Add to this the external Watchdog mechanism. The Watchdog touches no business logic. It specializes in watching whether the whole system has frozen or gone off track. Once it finds a Worker making no progress for a long time, or a flow falling into an anomaly, the Watchdog can step in to interrupt, restart, or reassign the task, giving the system self-healing ability. This too is the classic watchdog idea from the computing world, moved wholesale into the agent system.
What the Experiment Says: Faster, but More Tokens
Architecture alone is not enough. The team offers a set of preliminary experimental numbers. We have to emphasize up front: these numbers are based on synthetic workloads and a simplified environment. They are a preliminary reference and cannot be treated as a formal product conclusion.
Look at speed first. In the experiment, half of the tasks were completed within 12.4 minutes, and 95 percent of the tasks were completed within 15.7 minutes, clearly beating the single-session approach that uses a Subagent tool. At the same time, Router batching brought the amortized inference time per decision down from 6.4 seconds to 1.6 seconds. This is the direct manifestation of the Router's ability to merge multiple decisions into one pass.
Now look at the cost. After turning off subscription direct delivery, the Router's decision count rose by about 30 percent, and the tokens read from cache climbed from 23.23 million to 31.77 million. In other words, the system trades more tokens for a more stable and faster response. This is precisely the core trade-off of the architecture: spend more tokens to buy time and stability. For a real engineering team, this trade-off is often worth it. One stable push that does not require rework is worth far more than the few tokens saved.
It is worth reminding that "fast" and "cheap" are a contradiction in this design. Router batching and subscription direct delivery both spend space, tokens and state, to buy time, latency and stability. If you chase extreme cost savings, this architecture may not be optimal. But if what you want is "stable progress over long periods with no one watching," then this is exactly the scenario it targets.
Already in Use: Continuous Progress Between IM and GitHub
This architecture is not paper theory. Zhizhiandongxi reported on November 1 that DeepSeek has already built an internal Super-agent instance on top of DeepSeek Harness and uses it in daily research and development collaboration.
This instance drives tasks continuously between IM group chats and GitHub PRs. More importantly, it does not need to be pinged by someone to move. The system can proactively identify defects in the code and submit fixing PRs on its own. This embodies the design goal of "actively looking for work and recovering from failures on its own." It has already connected to GitHub and Feishu, which means it can both read discussions in group chats and touch changes in the code repository, stringing previously scattered workflows into one line.
From an engineering perspective, this is the most convincing part of Super-agent. Many agent demos stop at "give a prompt and run a segment." This internal instance demonstrates a real usage pattern that is cross-system, long-cycle, and lightly supervised. It proves that "the system layer taking over conversation orchestration" is not just a pretty phrase on an architecture diagram, but something that can actually run inside a research and development pipeline.
Can This Approach Be Copied Directly
To answer this, you have to see its positioning clearly. The DeepSeek Harness team explicitly positions it as "an engineering-practice-oriented architecture exploration plus an open-source prototype." It is not yet a formal standalone product from DeepSeek. What sits at the repository path github.com/deepseek-ai/dsh-superagent-prototype is exactly such a prototype. To be precise, its ownership is deepseek-ai/dsh-superagent-prototype, released under the MIT license, and anyone can build on it for secondary development at a fairly low barrier.
So the answer to "can it be copied directly" is: the architectural thinking can and should be copied, but do not treat it as a ready-to-use finished product. For small teams and individuals, the most valuable part is not replicating the whole system, but borrowing a few principles. Separate scheduling from execution. Drive the agent with events rather than polling. Give the system a Watchdog that can catch and restart it. Even if you only have a single model in hand, applying these ideas can help you avoid many pitfalls.
You must also stay clear-headed: the experiment is based on synthetic workloads, so the conclusion cannot be directly extrapolated to real and complex business. When you actually land it, you will find that the event noise, long-tail tasks, and permission boundaries of the real environment are all far more complex than in the experiment. Try it in a small scope first, then scale up slowly. That is the more prudent rhythm.
FAQ
Q1: How is Super-agent different from a common Agent Team?
A1: A common Agent Team is usually human-driven. The human assigns work, summarizes, and decides the next step, while the agents are more like tools chained together. Super-agent hands the job of "conversation orchestration" to the system-layer Router. A resident Router dispatches uniformly, isolated Workers execute concurrently, the Router provides a unified outlet, and event-driven logic plus an external Watchdog support the whole thing. The core difference is that scheduling moves from "human" to "system."
Q2: Will the Router layer become a performance bottleneck?
A2: In theory, if every event passes through the Router, it could indeed become a bottleneck. The team eases this with two measures. First, the Router only dispatches and does no concrete execution, so it can run a lighter-weight model. Second, it introduces "subscription direct delivery," where after a Worker claims a Thread, subsequent events go straight to that Worker and bypass the Router. The experiment shows that turning off direct delivery raises the Router's decision count by about 30 percent, which shows how much the direct-delivery mechanism relieves Router pressure.
Q3: Can this architecture be used directly now, is it a product?
A3: It is not a formal product. It is positioned as an engineering-practice-oriented architecture exploration plus an open-source prototype. The repository deepseek-ai/dsh-superagent-prototype is released under the MIT license, and anyone can clone it and build on it, but DeepSeek has not released it as a standalone product. Those who want to use it are better off treating it as a reference implementation to learn from, rather than as a ready-to-use service.
Q4: Are the experimental numbers reliable, what was the evaluation environment?
A4: They need to be treated with caution. The team itself stresses in its technical article that the experiment is based on synthetic workloads and a simplified environment. It is a preliminary reference, not a formal product conclusion. The reported figures, half of tasks within 12.4 minutes, 95 percent within 15.7 minutes, and per-decision time down from 6.4 seconds to 1.6 seconds, reflect trends under a specific workload and cannot be simply extrapolated to real complex business.
Q5: How can ordinary users or small teams borrow this thinking?
A5: You do not need to replicate the whole system. Focus on borrowing three principles. First, separate scheduling from execution and let a lightweight role specialize in dispatching. Second, trigger the agent with events instead of waiting through polling, so the agent responds proactively. Third, add a Watchdog as a safety net that can interrupt and restart when something freezes. Even with a single model, these ideas can significantly improve the stability of an agent system.
Related reading