By Zheng Tian
This article is excerpted from the Alibaba Cloud AI Agent Handbook; project address: https://github.com/aliyun/ai-agent-handbook
Alibaba Cloud AgentCore now supports DeepSeek Harness deployment, accelerating enterprise productionization validation.
After DeepSeek released SuperAgent, the prevailing view in the industry was that Agent design had largely converged. We share that view. In addition to introducing DeepSeek SuperAgent's design, this article focuses on our exploration of similar SuperAgent technologies and their productization.
Consider an afternoon familiar to many developers. You use an Agent for three things at once: fixing a Bug, writing a proposal, and running data analysis. Below are two ways to spend that same afternoon:
Figure 1 · Two Ways to Spend the Same Afternoon
The problem on the left is not that the Agents are insufficiently capable. The Agent in each window does a good job. The problem is that the burden of scheduling falls on the person: you have to remember who is waiting for you, which message relates to which task, and where a conclusion was reached. The DSH team observed that one person can usually follow only 3 to 5 active conversations at once. Their conclusion is apt: the ceiling for a single task depends on the model; the ceiling for multiple tasks depends on human attention.
So the goal of a Super Agent can be expressed in one sentence: Make the user feel they are always working with just one Agent, even while it handles many things at once. To achieve this, it must meet four requirements:
The DSH team shared an internal example: no one @mentioned it in the group, yet it identified the issue itself and submitted a fix:
Figure 2 · Without an @mention in the Group, Super Agent Proactively Identifies the Root Cause and Submits a Fix (Source: Original DSH Article)
Many first-time readers of Super Agent interpret it as "one Agent distributing tasks to multiple Agents." Distribution is only a means. Its real objective is to increase Agent autonomy and remove human bottlenecks at each stage. People hold Agents back in more than one place; the four characteristics map neatly to four bottlenecks:
Figure 3 · Four Human Bottlenecks and the Corresponding Super Agent Designs (Author's Synthesis)
DSH was not the first to discover these bottlenecks; earlier efforts each addressed part of the problem. Cursor's Background Agents run tasks in the cloud so that people do not have to watch them constantly, but initiation and scheduling still fall to the person:
Figure 4 · Cursor Background Agents (Source: madewithlove hands-on evaluation, 2025)
LangChain's proposed Ambient Agents address the need for "human initiation": events drive the Agent, while people handle its requests in an inbox. The wave of Personal Agent products in September this year, such as Muse, dots, and Grok Bot, addresses the need for "people to remain online": work continues after the App is closed.
| Approach | Representative Products | Problem Targeted | Conversation (Session) | Limitations |
|---|---|---|---|---|
| Background Agent dashboard | Cursor | Requires human supervision | Becomes a task list | Initiation and scheduling still fall to the person |
| Event-driven Agent | LangChain Ambient Agents | Requires human initiation | Hidden behind events and an inbox | Multi-task coordination must be built separately |
| Always-on personal Agent (Personal Agent) | Muse, dots, Grok Bot | Requires the person to remain online | Hidden behind the main conversation or Bot | Personal focus; team accountability is not the priority |
| Router + Worker | DSH Super Agent | Addresses the problems above | Becomes a system implementation detail | Long-term memory, organizational boundaries, safety |
The original DSH article presents six modules. Some descriptions are somewhat convoluted, but the underlying ideas are actually quite simple. We will provide a simplified version below.
Figure 5 · Architecture in the Original Super Agent Article
Start by imagining a small team: the always-on Router acts like a receptionist, receiving everything new and deciding who should handle it; the Worker acts like a specialist, with each handling its own work. The receptionist does not do the specific work, and specialists do not speak directly to customers. Events in the environment are called Trigger events; before entering, they pass through a filter to determine who should respond.
The entire design can be understood simply as deciding which real-world occurrences deserve an Agent's attention and which Agent should attend to them, then finding a balance between a vast event stream and limited context: from rules and LLMs to assignment by a routing Agent.
Figure 6 · Simplified Super Agent Architecture
Below, we examine what problem each part solves and why it is designed that way.
Agent system design faces an unavoidable tension between continuity and throughput. Putting everything in one Session gives the greatest contextual continuity, but a single ReAct Loop runs serially: everything queues up, and tasks interrupt one another. Starting a new Session for each task enables concurrency, but the Sessions do not know what the others are doing, and each speaks to you independently.
Figure 7 · Continuity and Throughput Compete, So Two Layers Address Them Separately
The solution is to separate the two: Router provides continuity, handling all communication with people and coordination between tasks, serving as the system's global serialization point and memory; Worker provides concurrency, with an isolated Session for each task. To keep Router from blocking, it does not perform specific work. DSH can even withhold Bash access from it; a lighter model often suffices. Workers use the strongest model, keeping reasoning and tool calls inside their own Sessions. Once they reach a conclusion, they report to Router, which provides a unified external response.
A passage from the original article helps clarify this. One frequently asked question is: How is this different from the Team Lead in an Agent Team? A Team Lead goes deep inside a task to break it down, while Router manages only relationships between tasks. Whether a Worker uses a Subagent or Team internally is transparent to Router. One key statement in the original article is that, if prompts constrain a Team's main conversation from doing work itself, "it can also be regarded as this two-layer architecture." Thus, the two-layer architecture describes a division of responsibilities, not a specific component.
To eliminate the bottleneck of "requiring human initiation," the environment must be able to wake the Agent. What drives it is no longer a command typed by a person, but Triggers such as group messages, code comments, and CI results. In a real environment, however, the event stream has "high noise and a low trigger rate." Asking a model about every event would be both slow and expensive.
DeepSeek Super Agent sends simple cases through a Fast Path and only a few complex cases through a Slow Path. That sounds complicated, but it is straightforward. Here, the Slow Path is the model and the Fast Path is rules. Rules might tell the Agent to pay particular attention to messages in certain groups or remarks by certain users—for example, requests from the product manager or the boss 🤣. In DSH's experimental workload, only about 20 out of approximately 300 messages were work requests:
Figure 8 · Place the Model at the End of the Funnel. The Figures 300 and 20 Come from DSH's Experimental Workload and Are Synthetic Data
The most ingenious part is routing. A sequence of events under the same PR or group-chat topic is called a Thread. After receiving a task, the Worker subscribes to that Thread. Subsequent events are delivered to it directly by the program, bypassing Router; this is subscription passthrough. Workers and Threads have a many-to-many relationship. Two Workers subscribed to the same PR can see each other's actions, answering the question, "If Workers do not communicate with each other, won't they conflict?"
DeepSeek also conducted an ablation study showing the value of passthrough. Removing it barely changed task completion time, but required Router to make roughly 30% more decisions and read about 37% more cached Tokens. In other words, it reduces Router load, not task duration.
Once an event enters a Session, the next question is how much to put in the context window. Too much consumes the window and dilutes the model's attention; too little forces repeated tool calls and adds steps. DSH manages the window as a Cache, borrowing two terms from compiler optimization: Inline places information likely to be needed soon directly in the window, saving a tool call; Spill keeps over-budget or infrequently used content outside the window, leaving only a summary or reference. Locality determines what is included—for example, messages immediately before and after an IM message, or neighboring comments in the discussion containing a code comment.
Applying this rule consistently to objects such as Trigger, Thread, and Worker Session creates a reference graph: each object inlines the ID of the next-hop object. Starting from the current event, the model follows references and expands them hop by hop. This is Chain of Recall. Router can retrieve an old task when someone mentions it without putting the entire history into its window:
Figure 9 · Example of Chain of Recall (Illustration)
The original article also acknowledges its limits: this primarily addresses recent tasks; beyond a month, long-term memory remains a bottleneck.
Those who have used Codex may ask: does full duplex simply mean being able to interject while it is running? They are related, but not identical. Interjection addresses "whether a message can come in"; full duplex also addresses "how long the message waits before being processed."
Codex's steer can inject a message into an ongoing turn so that the model sees it at the next reasoning step; DSH's documentation also uses the term steer. But the model's loop is "reason, call a tool, wait for the result, then reason again." If it is waiting on a synchronous tool, the next reasoning step cannot start until that tool returns. With interjection alone, your request to "stop for now" might still wait 20 minutes for tests to finish.
Figure 10 · The Three Modes Differ in When the Model Sees "Stop for Now" (Illustration)
The original article's "full duplex" targets precisely this blocking. It turns time-consuming commands and subtasks into asynchronous start and stop operations: a call immediately returns "started," and the loop continues; the tool runs in the background, and its result is delivered as a new event; the model can also actively stop it. This keeps reasoning steps short, allowing new messages to be processed after the current step ends. The model itself still runs one step at a time; it is not doing two things simultaneously.
The prototype implements this directly: a Worker's foreground command automatically moves to the background after 5 seconds. The documentation states the reason explicitly: to let it receive new messages at the next step.
A local Agent ties the computation that advances tasks (the Agent Loop), conversation state, and the actual working environment to a single computer. Consider a concrete scenario to see what changes when they are separated:
Figure 11 · One Task Spanning a Weekend (Scenario Illustration; the Approach to Intermittently Online Devices Comes from the Original Article)
This example has two layers of decoupling. First, separate compute from state: the Agent Loop runs in stateless cloud containers, while Sessions are stored in a database; restarting or replacing a container does not affect progress. Second, separate compute from the environment: your local machine has uncommitted changes, private credentials, and internal-network dependencies. Rebuilding it in the cloud is costly and prone to omissions. Since the environment itself is hard to synchronize, leave it where it is and install only a lightweight daemon that stores no conversation state, executes commands, and returns results. When the device comes back online, the cloud Agent resumes the work that needs to be done on that device. This is also a general BYOM (Bring Your Own Machine) solution. Put plainly, rather than rebuilding the environment, send operations that must interact with the local environment to the local machine for execution, keeping the overall environment lightweight. (The trade-off is dependence on the device being online. When the local machine goes offline, the step that needs it pauses until the device reconnects. Progress is not lost because state is stored in the cloud. Cursor Background Agents and Codex cloud tasks take the other route: rebuilding the environment in the cloud. The benefits are independence from your computer, parallelism, and good isolation; the cost is the replication effort described above. The two approaches offer different trade-offs; neither is inherently better)
Figure 12 · Anthropic's "Brain–Hands Separation" Follows the Same Idea: Session, Harness, and Sandbox Become Independent Interfaces. DSH Differs by Prioritizing Intermittently Online Personal Machines (Source: Anthropic Engineering)
Another easily overlooked issue is that Agent failures often do not mean the process has crashed: the process may be perfectly alive while the model goes in circles. Liveness probes cannot detect this. DSH therefore places an independent Watchdog conversation outside the system to periodically assess whether each Worker is making meaningful progress and staying on course.
The most eye-catching number in the original article is "nearly twice as fast," but the full table should be read as follows. Here, P50 is the time by which half the tasks finish, while P95 is the time by which almost all tasks finish, indicating how slow the slowest group of tasks is:
| Approach | P50 (Minutes) | P95 (Minutes) | Cached Tokens Read |
|---|---|---|---|
| Super Agent | 12.4 | 15.7 | 23.23 million (3.8×) |
| Single Session, with Prompts Instructing Delegation First | 13.8 | 29.0 | 10.82 million (1.8×) |
| Single Session, with Neutral Prompts | 20.4 | 29.5 | 6.05 million (baseline) |
By changing just one sentence in the prompt, half the tasks finish only 11% slower than with Super Agent, using less than half as many Tokens. What, then, does the architecture buy? It buys stability: at some point, the model will decide, "This is a small job; I will do it myself," and that one decision pushes the slowest task to 29 minutes. Prompts cannot eliminate this randomness. The cost is more than doubling the Token count. Also, this is a synthetic workload: coding is replaced by a tool that merely consumes time. The test measures scheduling capability; it does not directly establish that a real team would be this much faster.
DSH also open-sourced a prototype, containing about 16,000 lines of code. Here is a source-level analysis:
The prototype is organized around a few objects. Each corresponds to a very straightforward real-world question:
Figure 13 · The Prototype's Core Concepts and Their Relationships
Why separate Ticket and Mandate? Imagine this scenario: a fix has been merged and the Ticket has ended. A week later, someone comments under that PR, "There is still a problem here." What should the system do? Repeating the entire assessment is too slow, but starting work directly could exceed its authority. With a separate Mandate, it can resume work under the original Mandate, first checking it against the latest rules to see whether it remains valid. Whether a piece of work may continue and what state it is currently in are two separate questions.
With these concepts in mind, let us follow a message through the system:
Figure 14 · From Arrival to Starting Work. Only One Step in the Entire Flow Calls the Model
The first step is "registration at the door": useful or not, every message is stored in the database, and duplicates are counted only once. This prevents messages from being replayed after a system restart and allows you to trace "where this message went" afterward. This is also the Append Only approach familiar from classic engineering design. The second step checks the owner: if a person's follow-up message lands in a Thread being tracked by a Ticket, that Ticket is its owner. The message goes directly to the corresponding Worker for assessment, without involving Router. The third step is the Gate, where code determines whether the sender is eligible. The model is not used until the fourth step. In the fifth step, when work is opened, the Ticket, Mandate, subscriptions, and acknowledgment reply are created atomically, avoiding an intermediate state in which "the Ticket exists, but nobody knows about it."
I consider this the prototype's most fundamental architectural decision. The system has a deterministic core, which is the only component allowed to write Ticket state. When the Router model "accepts work," it is essentially only submitting a request. The core checks permissions, rules, parameters, and the current state, rejecting any request that fails these checks.
Figure 15 · The Model Provides Flexibility; the Program Provides Reliability
The benefit is that, even if the model makes a mistake or is compromised by prompt injection, the worst it can do is submit a request that gets rejected. This is consistent with the experimental findings in Section 2: since the model may "think this is a small job," do not rely on its self-discipline. Router's prohibition on doing work is therefore not just a prompt instruction; operations such as long waits are rejected at the code level.
For a long-running system, a crash halfway through execution is a major concern. For example, the state may already have changed to "accepted," but the acknowledgment has not yet been sent. After a restart, the system does not know whether to send it again. The prototype treats pending external actions as data too, recording them in the same transaction as the state changes. After the transaction commits, a background process executes them one by one:
Figure 16 · Log External Actions First, Then Execute Them After Commit. After a Crash and Restart, Resume Unfinished Actions
In distributed systems, this is called the Outbox pattern. It is not a new technology, but another classic engineering design. DeepSeek applies it thoroughly: starting Worker, delivering messages, and sending IM messages all follow this path. The model's work cannot be replayed in full, however, so after a restart, Worker receives a prompt to inspect the code directory and the actual state of the PR before deciding whether to redo the work.
Super Agent spends all day reading group chats and comments, any of which may contain malicious instructions. The prototype explicitly defines precedence; the defense is shown in this diagram:
Figure 17 · Higher Layers Always Override Lower Ones; External Text Is at the Bottom
There is another easily overlooked detail: when Router hands off a task, its note is limited to 30 words and may not include an implementation plan or acceptance criteria. Worker must read the original messages itself. This guards against distortion in relaying information. As in human teams, the more a message is retold, the more it drifts.
Proactivity is the capability most likely to go wrong: a team will quickly disable an Agent that opens PRs indiscriminately. The prototype separates "judgment" from "execution." New rules default to a dry run: the model evaluates them as usual, but only records, "I would accept this work if execution were enabled," without actually starting. Once the team reviews the records and finds the judgments accurate, it enables execution. The model must also reach a conclusion for each rule individually and quote the original message as evidence when accepting work. This follows the same logic as a staged rollout and is one of the more interesting designs in the current prototype.
The original DSH article calls for saving human attention. In the code, this takes three concrete forms:
It also makes clear simplifications. State is stored in a single-machine database, and each deployment corresponds to only one repository and one set of accounts. Worker runs under the operator's system identity, and the documentation explicitly says that command wrappers are not a security boundary. I found neither the Watchdog nor the speculative execution mentioned in the article in the prototype's code, documentation, or prompts. Completion also depends mainly on external facts, such as a PR being merged. This is natural for development, but insufficient for business work. These are precisely the areas we need to address.
Over the past two years, many products have called themselves digital employees. Open them, though, and most are a chat box plus a knowledge base, with a few tools attached. You ask a question, they answer; close the window, and it ends. Next time, you have to explain the background all over again. These products are useful, but calling them employees is not quite appropriate.
Figure 18 · My Four-Level Classification of "Digital Employees" (Personal View)
I use four questions to judge whether something qualifies as a digital employee:
A true digital employee should therefore be Always-on by design, and Super Agent is moving in exactly this direction. Its proposed qualities—"continuous, efficient, proactive, and persistent"—are simply the basic qualities of a good colleague, expressed another way. Next, I will discuss how I view several of its technical choices.
When reading the original article, it is easy to focus on the Router component. Unpack it, however, and it bundles three jobs: front-end interaction with people, routing decisions, and global memory. These three jobs do not have to live in the same persistent Session. The original article itself says that "some of Router's logic may not require an LLM call."
Figure 19 · The Same Three Jobs, Assigned to Different Components in Our System
Our approach is this: the front end is the Channel itself, where people and Agents see the same timeline. Code calculates whom to wake based on task state. Work requiring judgment goes to Coordinator (the coordinator), an ordinary member of the Channel whose responsibilities are explicit: "not personally executing specific business operations, but decomposing, assigning, tracking, and summarizing." Memory lives in Quest and files.
This replacement has gains and losses. The gains are that the coordinator need not remain resident, its context does not grow indefinitely, it wakes when needed and exits when done, and permission boundaries are clearer. What we lose is the sense of continuity provided by a persistent Router and the batching benefit of "processing accumulated events together in the next round." At present, we largely use one wake-up and one execution per message. This is precisely where we need to learn from DSH.
Anyone with organizational management experience is naturally wary of centralization: if everything goes to one person, that person will inevitably be overwhelmed. This conclusion is correct, but its premise is that human bandwidth is narrow. One manager can follow only a few things at once, so human organizations need layers that compress information at each level.
Figure 20 · Both Are Centralized, but Their Cost Structures Differ. Figures on the Right Come from DSH's Router Load Test
An Agent does not have this constraint. It reads quickly, does not get tired, and does not need meetings to synchronize. DSH's load test also produced a counterintuitive result: as events increased from 1 to 40 per minute, average reasoning time per decision fell from 6.4 seconds to 1.6 seconds. Events accumulated while Router is thinking are processed together in the next round. Human decision quality declines under heavy workloads; within a certain range, the model instead becomes cheaper through batching.
Figure 21 · Router Batching Load Test: More Events Make Each Decision Cheaper (Source: Original DSH Article)
The lesson is this: Do not transplant human organizational structures directly onto Agents. Hierarchies, weekly meetings, and reporting up the chain were invented to accommodate human bandwidth. Many multi-Agent systems model their roles on corporate organization charts and may be learning exactly the wrong lesson. Centralization is a bottleneck for people, but for Agents it may well be the simplest and most effective structure.
Of course, this does not mean the center has no problems. That load test used a mock model for Worker, and the rate went only as high as 40 events per minute; its results cannot be extrapolated to arbitrary scale. I see at least four bottlenecks in centralization:
| Bottleneck | Why It Arises | How DSH Responds | How We Respond |
|---|---|---|---|
| Context capacity | Everything passes through it; sooner or later, the window runs out of space | Send follow-up messages directly to Worker; use Chain of Recall; acknowledge memory across months as a bottleneck | Keep the coordinator non-resident, partition by Channel, and retrieve information only when needed |
| Decision quality | Judging too many things in one round invites errors, and a single error has a broad impact | Assign a message to a Ticket only when it explicitly refers to that Ticket | @ counts only as communication; only formally creating a task counts as delegation |
| Cost | A large context must be reread each time | Accept 3.8× as many cached Tokens read | Call the model only when needed, but wake-ups are not yet batched |
| Blast radius | All events and permissions converge at one point; prompt injection there affects the whole system | Treat external text only as data; enforce permissions in code | Isolate by Channel; crossing a Channel boundary requires authorization from both sides |
DSH also says that finer partitioning increases throughput but reduces continuity, and that "this trade-off will persist until the global memory problem is solved." Assigning a coordinator to each Channel means we shard along business boundaries from the start. The cost is that users must know which Channel to go to. Neither choice is perfect; in an enterprise, I would simply rather establish boundaries first.
This is the point I agree with most, and one DSH and we reached independently. Once the center starts caring about "how to do it," it has to read details and plan, quickly degenerating into a heavyweight Team Lead and bringing the bottleneck back. To remain lightweight, the center must focus only on outcomes.
Figure 22 · The Coordinator Provides a Contract; Execution Is a Black Box; the Center Reenters Only When Results Return
In our Collaboration Space, a task defines only its goal, acceptance criteria, owner, and dependencies. There is no "implementation plan" field. The Agent receiving the task decides how to do it: reading materials, using sub-Agents, running workflows, or even delegating part of the work to someone else. None of this requires the coordinator's involvement. Once it has decomposed the task, the coordinator can end its turn without polling; the platform wakes it when all subtasks have ended. DSH goes further: Router may not even write acceptance criteria. Worker must return to the original request and judge for itself; even "Router accepting a Ticket does not prove that the work should be done."
The difference between the two is also interesting. DSH can omit acceptance criteria because development has objective facts such as PRs and CI. We must specify them because much business work has no objective completion signal. Acceptance criteria are the task's interface.
There is a prerequisite for "looking only at outcomes," however, and this brings us to a well-known industry debate. In June 2025, Anthropic unveiled its multi-Agent Research system, in which the main Agent decomposes tasks and sub-Agents search in parallel.
Figure 23 · Architecture of the Anthropic Research System (Source: Anthropic Engineering)
At almost the same time, Cognition published "Don't Build Multi-Agents," arguing the opposite. Its example was building Flappy Bird: one sub-Agent created a Super Mario-style background, while another created a bird that did not fit. Every action carries implicit decisions that the other Agents cannot see.
Figure 24 · Cognition's View: Parallel Decomposition Is "Unreliable," While a Single Execution Path Is "Good" (Source: Cognition)
My view is that both sides have a point: research can be split up, but a game's visual style cannot. So the question is not whether to use multiple Agents, but where to draw the boundary: only work that can be independently checked and accepted can be delegated.
The views above did not emerge only after reading the original article. Many came from pitfalls we encountered while building Collaboration Space. The question Collaboration Space needs to answer differs slightly from DSH's. DSH asks, "How can one Agent do many things at once?" We ask, "How can a group of people and a group of Agents take end-to-end responsibility for a piece of work?"
Let us start with the big picture. The system has four layers. Following the numbers in the diagram takes us through the complete process for a piece of work:
Figure 25 · Collaboration Space Architecture and Execution Flow.
The most important point here is separating the control plane from the execution plane. The control plane holds business facts: who is responsible, how far the work has progressed, and which version of the result is current. The execution plane is concerned only with completing the current run; model calls, tool execution, and checkpoint recovery all happen here. Execution can fail, restart, or switch executors, while responsibility and progress remain in the control plane and are not lost. This is the same idea as DSH's "Ticket does not follow the Session," except we have made it a product that people can also see and operate directly.
Unlike DSH's "single center," we have many Channel spaces. Each Channel corresponds to a project or business scenario and contains people, a coordinator, and various Agents, even including local Qoder on a user's computer. They share a timeline, and context and permissions stay within that space by default.
Figure 26 · Channel and Cross-Channel Collaboration
After isolation comes the need to support collaboration across boundaries. DSH leaves this as an open question; we have an initial implementation. When a development Agent needs the business side to take over, it does not bring the other party into its own space. Instead, it creates a task in the other party's Channel, where that party executes it in its own space. There is a small design detail I particularly like: if exchanges along the same interaction chain exceed the limit, which defaults to 6 rounds, further exchanges are rejected and merging the spaces is suggested. If the two sides need that many rounds of discussion, the boundary was probably drawn incorrectly.
Local Qoder also deserves mention. It corresponds to DSH's idea of "connecting the machines used every day." The difference is that we make it a member of the Channel, using the same task and acceptance mechanisms as platform Agents. It simply pulls tasks proactively and executes them on the user's computer.
You would not "create a new colleague" every time you wanted to discuss something with a colleague. This is what we mean by Sessionless. It does not mean there is no Session underneath; rather, a Session no longer represents identity or a task, but is merely a disposable resource for one execution. Here is what a round of work looks like in the system:
Figure 27 · The User Sees One Continuous Timeline; the System Runs Several Session Segments
These Session types follow different rules for good reasons. Chat needs continuity, so the conversational Session is resumed. Task execution starts a new Session for each round whenever possible, because inheriting an old Session "causes context to accumulate across rounds." It resumes a Session only in cases such as consolidating subtasks back into the parent task or restarting from a manual checkpoint. Acceptance always starts a new Session, because the reviewer should not carry the executor's context and has no execution permissions.
The conversational Session best illustrates this approach. The user has no "New Session" button at all. The system computes a key from several facts; if the key is the same, the conversation continues:
Figure 28 · The System Computes Whether to Start a New Session; the User Does Not Choose
Among these facts, "who can see it" is an easily overlooked privacy boundary. When Channel membership changes, new conversations automatically switch to a new Session, so newcomers cannot read the previous context. A single-instance DSH does not need to consider this, but a Channel with multiple people and Agents must.
Once the Session is hidden, another question arises: how do you investigate when something goes wrong? In September, we therefore added a lineage table. Nodes can be either Session instances or tasks, and every edge records who triggered it. After someone @mentions an Agent, a single query can show everything that grew out of that round of work.
If a Session is disposable, what stays stable? The answer is Quest. The three-character Chinese label we used in its table definition means "accountability record." It is a piece of work that can be assigned, tracked, and accepted, with a goal, acceptance criteria, and a single owner. Like the Ticket proposed by DSH, it is a structured task. At heart, the aim is to turn our chats and conversations into a structured, explicit task list.
Figure 29 · The Quest Lifecycle
The key design here is the "awaiting acceptance" state: a successful Agent run does not mean the task is complete. It only means that a version of the result has been submitted. The task is complete only when a person or a designated acceptance Agent approves it. If the result is unsatisfactory, it is sent back for another execution, while the previous version is retained. In an enterprise, someone must acknowledge that the work is "done."
Many orchestration systems require a flowchart to be drawn first and then executed. Complex tasks, however, often cannot be mapped out in advance. We do the reverse: each action records only its relationships to other work, and the graph grows naturally as the work proceeds.
Figure 30 · The Structure That Grows out of a Goods Pickup Task
The mechanism is simple, with just three rules. First, when an Agent creates a task while executing another task, the new task defaults to being a subtask of the current one. Second, dependencies are specified when a task is created; downstream work is woken only after upstream work finishes. Third, once all subtasks have ended, the platform wakes the parent task and provides the accepted results for consolidation. The "failed order review" in the diagram was a subtask created by the executor midway through the work; the coordinator did not know about it at the outset.
The "execution overview" seen by the manager simply expands these relationships into a DAG. The system does not maintain a separate flowchart. Of course, "growing naturally" does not mean anything goes: if an Agent cannot identify which task a new task belongs to, the platform rejects its creation. Otherwise, orphaned tasks could leave the parent task waiting forever for consolidation.
Figure 31 · The Actual System Graph
The Quest chain has another by-product. DSH uses references between events for Chain of Recall, while our task chain is itself a reference graph, with edges representing work relationships, which are more stable than event relationships. Let us look at a more complex question:
Figure 32 · Answering a Question from Two Weeks Ago Along the Quest Chain (Scenario and Figures Are Illustrative)
The answer to this question is scattered across three places: a clue in the comments on the second version, evidence in the upstream failure details, and the reason in a reply from a business user. The Agent does not need to remember what happened two weeks ago; it only needs to follow the work relationships.
Many people understand proactivity as a process constantly thinking, "What should I do?" Our implementation is much simpler: task state lives in a ledger; each state change determines whom to wake, and the model is called only when needed. The output of one execution becomes the trigger for the next, and work moves forward on its own in this way.
Figure 33 · The Proactive Progress Loop
The biggest pitfall we encountered here was Agents waking one another, a problem that a single Agent does not face. In the staging environment, a task to "organize a roll call" should ideally have taken 3 executions: the coordinator @mentions two Agents, each gives a one-line reply, and the coordinator summarizes. In reality, it ran more than 10 times. The same task generated 8 execution instances, and an Agent even @mentioned itself. The root cause was not a foolish model. The platform had put "being mentioned" and "being assigned a task" into the same flow. The @mentioned Agent received the instruction, "You must submit deliverables upon completion," so it diligently started decomposing tasks and sending notifications.
The fix was to separate the semantics: @ is communication; Quest is delegation. An @mention calls only for a reply and grants no execution authority; to do work, create a task first. We also made copied messages non-waking and set a default limit of 3 consecutive wake-ups between Agents, with the count reset whenever a person intervenes. This matches DSH's conclusion: hard platform constraints are more reliable than prompts.
This is the hardest problem, and DSH also acknowledges that long-term memory across months is a bottleneck. We went through a turning point here. Our early approach seemed natural: every time we woke an Agent, we inserted the member list, today's messages, and recent activity, fearing it might not know enough. The result was an increasingly bloated context and persistent unnecessary chatter. Later, we slimmed it down and removed all of these:
Figure 34 · From Push to Pull. The Same Conclusion as DSH's Inline and Spill; Production Problems Drove Us Here
We also retained a small detail in the tools: long messages are no longer simply truncated. Instead, the beginning and end are preserved, while the middle is collapsed with instructions on how to retrieve it. Because the Agent starts fresh at every wake-up, retrieval is its only route to understanding the past. Truncation would cause it to mistake incomplete content for the whole.
The next step is the MDC (Meta-Dance-Context) approach: do not make the Agent remember; make it able to find what it needs. Memory does not live in the model's head or depend on an infinitely long Session. Instead, it sits behind a file interface that the Agent can browse for itself. Each wake-up compiles a clean context window, and the Agent reads more as needed.
Figure 35 · Turning Memory into a File Interface (Directories Illustrate the Planned Design). Results Can Be Audited and Cited, and Carried Over When Switching Models
First, Agent architectures are converging. After SuperAgent was released, a quick scan told me that DSH and we were solving the same problems. Others in the community independently commented that it resembled their own work as well. Later, comparing the source code further confirmed this view. Among these similar solutions, ours may be almost identical to DSH's work. Even task objects such as Ticket and the organization of call chains are highly similar. I do not think this is coincidence or mutual borrowing; rather, the constraints have narrowed the solution space:
Once a problem is clearly defined, the answers converge, just as databases ultimately move toward write-ahead logging and operating systems toward processes and schedulers.
Second, Agents are returning to traditional engineering. When an Agent changes from "a single conversation" into "a long-running process," it must face the old problems of distributed systems: processes crash, machines go offline, messages are duplicated, and side effects must not execute twice. Increasingly, what we see in DSH's code and our own are classic database and distributed-systems techniques: write-ahead logs that record actions before carrying them out, Outbox to ensure side effects execute only once, leases to prevent duplicate claiming, and replayable event records.
The model is the only nondeterministic component in the system; engineering's job is to wrap it in a deterministic shell. The model can make mistakes, but the system must be able to converge. Reliability no longer depends only on whether the model can get things right; it also depends on whether the system can recover from mistakes or interruptions. Agents will increasingly be a matter of systems engineering: the model is the CPU, and Harness is the operating system and database.
[1] madewithlove hands-on evaluation — https://madewithlove.com/blog/using-cursor-background-agents/
[2] Ambient Agents — https://blog.langchain.com/introducing-ambient-agents
[3] Anthropic Engineering — https://www.anthropic.com/engineering/managed-agents
[4] a prototype — https://github.com/deepseek-ai/dsh-superagent-prototype
[5] Anthropic Engineering — https://www.anthropic.com/engineering/multi-agent-research-system
[6] Cognition — https://cognition.ai/blog/dont-build-multi-agents
Alibaba Cloud Launches Full-stack AgenticOps, Making the Agent the First User in Operations and R&D
822 posts | 61 followers
FollowAlibaba Cloud Native Community - November 11, 2026
ApsaraDB - December 29, 2025
Alibaba Cloud Native Community - February 13, 2025
Alibaba Cloud Community - October 20, 2026
Alibaba Cloud Native Community - February 13, 2026
Alibaba Cloud Community - September 14, 2026
822 posts | 61 followers
Follow
Qoder
From Assisted to Autonomous — Adapting to Every Programming Need
Learn More
AgentCore
AgentCore unifies agent construction, governance, and execution capabilities so enterprises can deploy diverse agents with confidence.
Learn More
DeepSeek
DeepSeek-V4.1-Flash is the lightweight flagship of DeepSeek's new architecture family, packing 552B total MoE parameters to deliver flagship-surpassing intelligence across key benchmarks.
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 MoreMore Posts by Alibaba Cloud Native Community
