DeepSeek open-sourced DeepSeek Harness in August. Its core idea: make everything a plugin.
The LangChain paradigm introduces various abstractions to reduce the complexity of Agent development; DeepSeek Harness is designed to reduce the complexity of optimizing the Agent experience and costs. The finer the granularity of plugins, the more transparent an Agent's operation becomes. Different stages give frameworks different missions, leading to different architectural ideas. Substantially improving an application's intelligence requires architectural innovation.
But both lie on the Pareto frontier: there is no absolute best, only trade-offs. DeepSeek Harness increases architectural transparency, but also introduces engineering complexity. The newly open-sourced dsh-superagent-prototype breaks down the engineering required for an Agent's “continuous entity” capabilities.
The dsh-superagent-prototype introduces the concept of a Super-agent:
“Break the binding between an Agent and a single manually initiated session, turning it into a ‘continuous entity’ that can retain context across sessions and advance multiple complex tasks simultaneously without them interfering with one another. We call this form of Agent and its system architecture a Super-agent.”
That sounds a little abstract. Let's look at a concrete office scenario.
In the morning, my manager asks me in an IM group to prepare materials for a quarterly presentation, keeping it to 20 minutes. I then hand the task to the Agent. But in the afternoon, my manager forwards an email from my manager's manager (+2), asking for a 10-minute presentation focused on future plans instead. At this point, I need to manually synchronize context from outside the Agent interface.
If we follow DeepSeek's “continuous entity” approach, when I receive the changed requirements in the afternoon, the Agent automatically recognizes that they concern the same matter discussed in the IM group that morning and updates the task autonomously. No human intervention is needed along the way. After all, the limit on multitasking is determined by human attention.
DeepSeek open-sourced a dedicated plugin package for this “continuous entity” scenario to move Agents beyond long-horizon tasks within a single session, toward continuously advancing multiple tasks across sessions, applications, and devices, unlocking more scenarios in life and work.
The scenario above is relatively simple. In real work and life, tasks involving multiple entities are far more complex. Today, humans transfer and process context between different entities, which clearly limits the autonomy Agents can exercise.
Even this simple office example requires several things to happen in its engineering implementation: receive the email, recognize it as new requirements for the same quarterly presentation, find the task already in progress, and continue the subsequent work under the new requirements.
DeepSeek summarizes the technical characteristics of this form with four adjectives: Continuous, Efficient, Proactive, and Persistent. But adjectives are among the hardest things to make concrete in Chinese. We will continue using scenarios to deepen our understanding.
Continuous: IM and email are different interaction channels. “Continuous” means that the same Agent can connect information about the same matter across different channels and keep the task moving, without requiring users to repeatedly carry context from one place to another.
Efficient: Respond quickly to interactions while completing multiple complex tasks in parallel and to a high standard. Accept the next instruction without waiting for the previous command or task to finish. For example, an Agent may take several hours to complete a complex task and receive requests through different channels in the meantime. It must support “interjections”, handling new requests efficiently rather than waiting until the current task is finished.
Proactive: Rather than waiting for users to issue instructions one by one, continuously observe events in the environment and proactively advance matters worth handling, while staying quiet when intervention is unnecessary. Let's extend the office scenario above. At 11:20, people in the same IM group are discussing where to go for Friday's team outing. This is unrelated to the presentation, so the Agent does not need to reply, nor should it affect the work in progress. At 13:10, Finance posts the final third-quarter data in the group, with two figures differing from those used in the first draft. This is directly relevant to the presentation, so the Agent needs to proactively update the charts and record what it changed.
Persistent: Stay online at all times, connect directly to the user's real working environment, and automatically recover from anomalies encountered during long-running operation. A Personal Agent is a typical example of always-online, or around-the-clock, tasks, unlocking everyday-life scenarios with low cognitive value, fragmented experiences, and high process friction. This persistent capability is also very helpful for research conducted over weeks, months, or years.
Of these characteristics, continuity is particularly easy to confuse with an Agent's global memory. Memory provides continuity at the knowledge level; continuity at the operational level depends on more engineering mechanisms.
Human attention is limited. With Agents, we have taken on the role of transferring and processing information between different messaging channels and tasks. The Continuous, Efficient, Proactive, and Persistent characteristics of Agents are precisely intended to free up our attention, thereby unlocking more scenarios.
DeepSeek believes that a single ReAct Loop cannot support all four characteristics above simultaneously; a corresponding underlying architecture is needed. Although this architecture may have different variants in practice, the following five modules form the basic framework supporting those four foundational characteristics: a two-layer architecture, event-driven operation, human-oriented interaction, separation of compute, state, and environment, and Watchdog.
But whether the task is simple, long-horizon, or autonomous and cross-entity, it always depends on the main thread of Agent action: tasks, information, and actions. Tasks define how work advances, how it resumes after interruption, and how completion is determined. Information defines the trade-offs between a limited model context window and a continuously growing task world. Actions define how intent is authorized, executed, and verified.
Figure 1: Alibaba Cloud AI Agent Handbook, Building section
Next, we will use some classic software design ideas to deepen our understanding of these modules.
| Module | Familiar Software Design Concepts | Problem Solved in Agents |
|---|---|---|
| Two-layer architecture | Separation of scheduling and execution | Keep the coordinator responsive while executors work in parallel |
| Event-driven operation | Message queues, asynchronous communication, publish–subscribe, caching | Support diverse ways of driving program operation |
| Separation of compute, state, and environment | Stateless services, shared storage, remote execution | Preserve necessary state when replacing compute instances, without migrating the entire working environment |
| Watchdog | Health checks, external control loops | Check not only whether services are alive, but also whether tasks are making progress |
The definitions of these modules have much in common with concepts in the Alibaba Cloud AI Agent Handbook's Operations section. But in Super-agent scenarios, there is still considerable room for system architectures to evolve.
Figure 2: Alibaba Cloud AI Agent Handbook, Operations section
Let's return to the earlier office example and add an event: the Agent is working on the first draft, I also ask it to organize a batch of customer feedback, and in between I casually ask, “What was the product retention rate in Q2?” Three things arrive almost simultaneously. How should the Agent arrange them?
One approach is to put everything in the same session. Context is most continuous this way: it knows what was written in the morning and what changed in the afternoon. But a ReAct Loop can only proceed step by step. While the presentation is being revised, customer feedback has to wait in line. The disadvantages are low throughput and intermediate details from multiple tasks getting mixed together, which can affect the quality of the results.
Another approach is to open a new session for every incoming message, maximizing concurrency. But that afternoon email will be treated as a new matter. The new session relies on global memory to maintain output quality; once the context extends beyond the boundaries of global memory, the Agent's results will suffer.
The first approach prioritizes context consistency; the second prioritizes throughput. We call this a trade-off in session organization.
This closely resembles the separation of scheduling and execution in software systems: one part receives requests and arranges work, while another focuses on execution. From the perspective of team collaboration, Chapter 11 of the Alibaba Cloud AI Agent Handbook, “Multi-Agent Collaboration and Orchestration,” identifies three common topologies: supervisor–executor, peer collaboration, and hierarchical orchestration.
Figure 3: Alibaba Cloud AI Agent Handbook, Chapter 11, “Multi-Agent Collaboration and Orchestration”
Of these, supervisor–executor is the closest to DeepSeek's two-layer architecture: a single entry point coordinates while multiple tasks advance independently. But DeepSeek narrows the responsibilities of the “supervisor.”
In a typical Agent Team, the Team Lead often needs to understand task details deeply, break tasks into subtasks, and coordinate members frequently, taking on a heavy reasoning load itself. If all information must first be collected by a single supervisor Agent, which then decides every step, the supervisor becomes a new bottleneck for both context and execution.
DeepSeek's Router layer does only two things: handle human interactions from all entry points, and manage assignment and coordination between tasks. It does not get involved in how an individual task is broken down, nor does it execute the task itself. It may not even need a Bash tool, and a lighter-weight model is often sufficient. The actual work goes to the Worker layer. Each Worker has isolated context, a full set of execution tools, and usually the most capable model available. Workers do not communicate directly with the outside world; they report to the Router, which provides a unified response to the user.
The two-layer architecture also incorporates strengths from the other two topologies. A Worker can create a Subagent internally, or even be an Agent Team itself. These internal arrangements are transparent to the Router, somewhat like the groups in hierarchical orchestration. When multiple Workers subscribe to the same discussion, they receive the same event notifications and have opportunities to discover and resolve conflicts themselves, resembling the shared discussion spaces used in peer collaboration.
At this point, you may have two questions.
First, if all entry points converge on the Router, won't it become overloaded?
DeepSeek's answer is batching. Messages arriving during the Router's previous round of reasoning accumulate and are processed together in the next round. Each Router step typically has a long input and a short output. Combining multiple messages into one model call means latency grows much more slowly than the number of messages. In stress tests, messages requiring decisions increased from about 1 per minute to about 40 per minute. The average batch grew from 1.0 messages to 2.8, while the duration of a single request rose only from 2.5 seconds to 3.9 seconds. The reasoning time allocated to each decision actually fell from 6.4 seconds to 1.6 seconds.
This resembles batch writes in a database: combine multiple operations to amortize the overhead of each call. But batching improves effective throughput; it does not guarantee a shorter wait for every message. At still larger scales, the Router can also be split into multiple sessions. But the finer the split, the less continuous the context between shards becomes. DeepSeek believes this trade-off will persist until the global memory problem is solved.
Second, can't a single session with a Subagent tool also divide up the work?
DeepSeek compared the approaches. Around 300 messages contained about 20 work requests, and each approach was run 5 times. With only a neutral prompt, the main session never called a Subagent in any of the 5 runs. It did all the work itself and was repeatedly interrupted by new messages, reaching a p95 completion time of 29.5 minutes. After the prompt was changed to prioritize delegation, it divided up the work in 4 of the 5 runs, but was still slower overall than the two-layer architecture. In the 1 remaining run, it judged the job “very small” and did it itself again. The two-layer architecture achieved p50 and p95 completion times of 12.4 minutes and 15.7 minutes, respectively.
Figure 4: “Exploring Super-agent Design: Toward More Autonomous Agent Systems”
Whether work is delegated should not depend on how well a prompt is written or what the model decides; the architecture should guarantee it.
I first encountered the term “event-driven” in Function Compute. Its runtime is not always resident; it depends on external events, such as changes in a database or network, to trigger execution.
What can drive an Agent's work? Human instructions, and events in the environment: an email, a DingTalk group message, a calendar reminder, a PR from GitHub, or even a repayment reminder.
DeepSeek collectively calls environmental events such as group chat messages, emails, schedule reminders, code review comments, and CI run results a Trigger. From entering the system to being processed, a Trigger must answer four questions in sequence.
Question 1: Does this message need the Agent's attention?
Once connected to real group chats and inboxes, the vast majority of messages have nothing to do with the Agent. The discussion about where to go for the team outing at 11:20 is one example. If a large language model has to evaluate every message from scratch, both latency and cost become bottlenecks.
DeepSeek borrows the Fast Path and Slow Path ideas from computer systems to implement two-stage filtering.
This is much like inbox rules plus a secretary. Advertising and subscription emails are automatically archived by rules; the secretary then decides which of the remaining messages need the boss's personal attention.
Question 2: Who should receive this message?
A filtered message needs to find the task it should affect. If every message requires the Router to make a fresh decision, the Router becomes a bottleneck again.
DeepSeek introduces the concept of a Thread: messages within the same IM topic, the same email exchange, or the same PR form a Thread. After the Router creates a Worker based on the first message in a Thread, that Worker subscribes to the Thread. Subsequent messages in the same Thread are delivered directly to the Worker by the program, bypassing the Router. This is called subscription-based direct delivery. Only new messages that are not yet covered by a subscription need the Router's judgment and assignment.
Returning to our office scenario: in the morning, the manager assigns the presentation in the IM group. The Router creates a presentation Worker, which subscribes to that IM topic. The afternoon email belongs to a new Thread, so it goes to the Router first. The Router determines that it concerns the same presentation and hands it to the presentation Worker, which then subscribes to the email exchange. Subsequent replies in that exchange also use direct delivery.
Subscriptions are many-to-many. A Worker can subscribe to multiple Threads—the presentation Worker subscribes to both the IM topic and the email exchange—and a Thread can have multiple Worker subscribers. The Router still sees all messages and retains a global view. If a new message falls outside the scope of the current task, the Worker can unsubscribe or return it to the Router for reassignment.
This closely resembles subscription relationships in messaging systems: first determine where a message belongs and establish a subscription, then deliver subsequent messages through the existing relationship rather than making a new decision for each one. Here, DeepSeek leaves known relationships to the program and unresolved assignments to the model. It borrows the publish–subscribe idea, but that does not mean the implementation must depend on any particular message queue.
The value of direct delivery is mainly reflected in cost. In DeepSeek's ablation experiment, removing direct delivery left task completion times essentially unchanged, but increased the number of decisions required of the Router by about 30%. Cache-read tokens rose from 23.23 million to 31.77 million, an increase of about 37%.
Question 3: How do we find that earlier matter?
For the Router to determine that “the afternoon email and the morning presentation concern the same matter,” it must still be able to find that morning's task. But as the system runs over time, historical tasks accumulate. The Router cannot fit all that history into its context window.
DeepSeek manages the context window as a cache, borrowing two terms from compiler optimization. Inline means placing information likely to be needed in the near future directly in the window, saving a tool call. Spill means keeping full content that does not fit or is rarely used outside the window, retaining only summaries and references and reading the content when needed.
More importantly, every message, Thread, and Worker session has its own ID. When an object is injected into context, the IDs of closely related objects are included. Once the afternoon email has been linked to the presentation task, the model can follow the email's Thread to the presentation Worker, then follow the Worker to the morning's IM topic. DeepSeek calls this chained recall.
This is a little like following references when researching a subject. Each article lists the source for the next one at the end; there is no need to bring the entire library to your desk at once. Chained recall mainly addresses retrieval of recent tasks and session history. Long-horizon memory spanning months or longer remains an open problem.
Question 4: Can we prepare before a formal instruction arrives?
CPUs use a technique called speculative execution: before the outcome of a branch is known, computation proceeds along the most likely path. If the guess is correct, use the result; if not, discard it. DeepSeek applies this idea to Agents, making preliminary attempts in the background based on environmental signals, trading additional compute for less human waiting time.
Let's extend the office scenario again. At 14:30, the manager casually remarks in the group, “+2 seems more interested in next year's plans lately.” This is not yet a formal requirement, so the Agent does not need to change the presentation. But it can prepare an outline of future plans in the background. At 16:10, the forwarded email arrives, requesting a 10-minute presentation focused on planning, and the outline is immediately useful. If the email never arrives, the outline need not disturb anyone.
Speculative execution changes when preparation happens, not who has the authority to decide. Until confirmed, material prepared in the background is only a draft and cannot be treated as a formal requirement for changing deliverables.
These four questions describe an event's complete journey through a Super-agent: first filter, then route, then retrieve context, and act ahead of time if necessary. These mechanisms have much in common with service communication and message queues in classic internet architectures.
Looking at the reach of Personal Agents, around-the-clock tasks have already become a standard capability for Agents; without them, more scenarios cannot be unlocked.
An Agent typically comprises three modules: the compute that advances the Agent Loop, session state that must be stored persistently, and the execution environment containing local files, code repositories, and various tools. At 18:30, I turn off my office computer and leave work, but the presentation revisions are not finished. We want work that does not depend on the local device to continue in the cloud. Steps such as reading local files or accessing a specific intranet, however, still have to wait for this computer to come online.
To achieve this, we need the following:
Step 1: Separate compute from state.
Place the compute that advances the Agent Loop in stateless, elastic cloud containers, and store state that needs persistence, such as a Session, in a database. Containers can scale horizontally, restart, or be replaced. New instances can read existing state rather than treating the task as a new matter all over again.
This follows the same principle as handling login state in Web applications. If a Session exists only in one server's memory, subsequent requests need to return to a node that can access that state. If that server restarts, state that has not been persisted may also be lost. A common approach is to put the Session in shared storage such as Redis, allowing different servers to retrieve the same login state instead of binding it to a particular machine. The cloud Agent Loop and external session storage adopt a similar division of responsibilities.
However, a shared Session solves the problem of finding state after moving to another server; it does not guarantee that work in progress will automatically resume. The Agent also needs to know which step to execute next and whether the previous tool command has already taken effect. Saving state is the foundation of recovery, not the whole of recovery.
This also explains why the Router can be “always resident” while compute containers remain stateless: what persists is the coordination responsibility and session state, not a requirement that any particular hosting process never exits.
Step 2: Separate compute from the execution environment.
Once the Agent Loop moves to the cloud, a new problem appears: the first draft of the presentation is on my office computer, and the finance system is accessible only from the company intranet. Much of the context an Agent needs must be obtained from these environments through tools. In a broader sense, context also includes the execution environment itself.
There are two common approaches.
DeepSeek's choice is to leave the environment where it is. Only a lightweight daemon is installed on the device; it does not store session state and is responsible only for executing commands and returning results. This is somewhat like a Runner in a CI system: scheduling is centralized, work runs on individual machines, and the Runner itself does not remember which step the pipeline has reached.
This follows the same idea as Anthropic's proposed “separation of brain and hands”: the brain makes decisions, the hands execute, and a unified interface connects them. The difference is that Anthropic discusses sandboxes created on demand in a managed service, while DeepSeek connects to the personal computers users work on every day, which may alternate between being online and offline—in other words, BYOM (Bring Your Own Machine).
After this separation, an Agent can choose a device with the files, tools, and permissions required by a task to execute commands. Not just any machine can replace the original environment. It can also wait for a device to come online: when I turn on my office computer the next morning, the cloud Agent checks the pending steps again, writes the revisions back to the local PPT, verifies figures against the intranet finance system, and completes the final delivery.
This design assumes mutual trust between the cloud and devices. If the cloud is compromised, whether through intrusion or prompt injection, all connected devices are at risk. Credentials that enter the model's context may also leak.
Staying online persistently requires not only continuous observation, but also recovery from anomalies during long-running operation.
Embedded systems have a classic component called a watchdog timer. The main program must regularly “feed the watchdog.” If the program hangs and fails to feed it before the timeout, the watchdog restarts the system.
Similarly, always-online distributed systems struggle to guarantee long-term reliability using only the main system's internal logic. They need an independent external control loop—a Control Loop—outside the main system.
The challenge in Agent scenarios, however, is that many failures are not process crashes.
At 20:00, the cloud presentation Worker's process is running normally, but it is changing the colors of the same retention chart in cached data for the fifth time. Meanwhile, the email interface has been reporting intermittent errors since the early evening. Traditional liveness probes cannot detect the first situation: the process is alive, but the task is not progressing. Restarting the Agent cannot solve the second situation either, because the problem is external. Long-running Agent systems therefore need to monitor not only whether infrastructure is alive, but also whether the tasks themselves are making progress.
DeepSeek's approach is to configure an independent Watchdog Session outside the main system and drive its periodic inspections with scheduled messages.
When an anomaly is found, intervene to fix it. For intermittent external failures, keep checking until normal operation resumes. In the office scenario, when Watchdog sees the presentation Worker spinning its wheels on the chart, it reminds the Worker that this presentation should focus on future plans. When the email interface reports errors, it checks again at intervals until the interface recovers.
This is much like Kubernetes control loops: continuously compare the desired state with the actual state and adjust when they diverge. The difference is that Kubernetes examines metrics that programs can evaluate, such as replica counts and health checks, whereas judging “whether there is substantive progress” or “whether the direction has drifted” requires a model.
Another interesting point: Watchdog itself is an Agent Session with a full set of tools. Maintainers can ask it in natural language, “Why did the presentation task get stuck last night?” They can also have it modify the main system's behavior while it is running, for example by adding or removing prompts or adjusting trigger rules.
Agents have evolved from conversation to action, and from simple tasks to long-horizon tasks. They have now entered the stage of solving cross-entity tasks. This stage places higher demands on software system architecture and engineering capabilities, which still need more engineering practice to establish constraints and standards. We will continue documenting the latest industry practices in the open-source Alibaba Cloud AI Agent Handbook project, and try to distill engineering-oriented design standards and architectural ideas.
818 posts | 61 followers
FollowAlibaba Cloud Community - April 2, 2026
Alibaba Cloud Community - May 21, 2026
Alibaba Cloud Native Community - November 11, 2026
Alibaba Cloud Community - August 3, 2026
Alibaba Cloud Community - June 17, 2026
Alibaba Cloud Community - September 25, 2026
818 posts | 61 followers
Follow
AgentCore
AgentCore unifies agent construction, governance, and execution capabilities so enterprises can deploy diverse agents with confidence.
Learn More
Token Plan
Build more, spend less. One plan, every modality.
Learn More
QwenWork
QwenWork is dedicated to helping employees strengthen their professional competitiveness in the AI era and to enabling enterprises to improve organizational effectiveness.
Learn More
Managed Service for Prometheus
Multi-source metrics are aggregated to monitor the status of your business and services in real time.
Learn MoreMore Posts by Alibaba Cloud Native Community
