Reads · saved 2026-11-01

Exploring Super-agent Design: Towards a More Autonomous Agent System

DeepSeek Harness @DeepSeekHarness ♥ 13.4k

Full captured text

**Shared by trevor:**

It would be interesting to try this locally. AI - when you get here, find the source article, translate it, and summarize it please. Don't use the derivative - go to the source please

This page holds our translation of the Chinese original. It replaced our copy of the X post on November 3, 2026. The X post (@DeepSeekHarness, November 1, 2026) is a machine translation of this article. Our copy of it stopped partway through section 8.4. This translation is complete through section 9 and the author credits. The summary is under [Key Takeaways](#key-takeaways).

| | |

|---|---|

| **Source** | <https://mp.weixin.qq.com/s/zoS7GlReWPhfCjENGxXCdg> (WeChat; a browser may ask for a quick check before it opens) |

| **Published** | October 31, 2026, on WeChat, by the DeepSeek Harness team (DeepSeek 产品部, DeepSeek's product department) |

| **Author** | Yujia Qiao built the system and wrote the article; 15 named teammates and others reviewed it |

| **Prototype** | <https://github.com/deepseek-ai/dsh-superagent-prototype> (MIT license; a research prototype, not an official DeepSeek product) |

| **Translation** | From the Chinese original by Crest Park AI, November 3, 2026 |

This article explores architecture ideas for engineering practice. It is not an introduction to existing features of DeepSeek Harness.

Over the past year, single-task agents, led by coding agents, have shown that models can use tools to solve complex problems, with less and less need for humans to watch them continuously or step in at each step. At the same time, models have become better at coordinating multiple agents, which makes it feasible to organize and schedule work across sessions. As humans take less part in low-level execution, their role is gradually moving up to higher-level decisions and the acceptance of results.

This rise in model capability has also given rise to new kinds of applications. Recently, personal agents have appeared in large numbers. They connect directly to everyday messaging, calendars, email and work platforms, keep watching the flow of information, and help handle tasks. This always-online, event-driven way of working is not limited to personal use; personal agents are only one kind of application of it. It is just as valuable in commercial settings such as software development.

However, today's mainstream agent designs still struggle to support this way of working at the scale of many tasks and team collaboration. Agents still work with a single session as the basic unit, and sessions are independent of one another. When users push several pieces of work forward in parallel, they must switch between sessions by hand and remember each session's context. In our observation, a person can usually follow only 3 to 5 active sessions at once. Under this design, the ceiling on a single task is set by model capability, but the ceiling on multiple tasks is set by human attention.

If we only extend an existing local single-session agent with CLIs, MCP or external connectors, the agent can receive external messages, but it is still held back by synchronous blocking in a single session, mixed-up context across tasks, and stopping whenever the local device goes offline. It needs a great deal of manual upkeep.

To break through these limits, the agent must be unbound from the single, manually run session. It should become one continuous entity that keeps context across sessions and pushes several complex tasks forward at once without them interfering with each other. We call this form of agent and its system architecture a **Super-agent**.

For example, in our internal Super-agent instance running on DeepSeek Harness, the same development task can move forward continuously between IM and GitHub. This instance also keeps watching feedback in public group chats and, with no one @-mentioning it, finds the root cause on its own and submits a Pull Request with the fix:

*Figure text, translated.* **Title:** One task, moving forward continuously between IM and GitHub. **Setting:** a font settings request, raised in an IM group chat and reviewed and revised on GitHub.

**IM, User B:** I'd like the fonts for body text, code and the terminal to be configurable separately.

**IM, Maintainer:** @Super-agent please support this.

**IM, Super-agent:** Pull Request ready: Settings now has three font rows, for body, code and terminal, each configured on its own.

**IM, User B:** Can the font sizes be set separately too?

**IM, Super-agent:** Yes, added to the same Pull Request: each of the three kinds of content has its own font and size.

**GitHub, Maintainer:** That's a lot of settings. Could a collapsible control tuck the extra appearance settings away?

**GitHub, Super-agent:** Got it. All the font and size settings are now in a collapsed "More appearance settings."

**GitHub, Designer:** These are font and size settings anyway. They can expand straight from the font size setting, with no separate section.

**GitHub, Super-agent:** Got it. The separate section is gone; they now expand directly from the "Font size" row.

**IM, Super-agent:** Pull Request merged.

*Figure text, translated.* **Title:** Listening silently in a public group chat, it spots a problem on its own and submits a fix Pull Request. **Setting:** a busy product user group; no one @-mentions or assigns the Super-agent.

**Everyday group messages:** Other members discuss daily use and feature ideas. The Super-agent listens silently and does not step in.

**User A:** On the macOS desktop app, clicking a conversation while the window isn't focused registers as a double-click and starts a rename. I trigger it by mistake dozens of times a day.

**Silent background work:** No one @-mentions the Super-agent. It recognizes a specific bug and reproduces and investigates it in the background automatically.

**Super-agent:** Fixed and submitted a Pull Request, with before-and-after screenshots. Root cause: by default Electron swallows the click that activates the window, and the next click carries `detail=2`, so it is read as a double-click.

Specifically, we think a Super-agent has the following four basic characteristics:

**Continuous:** Users can interact with it directly in the work surfaces they already know, such as IM chats and GitHub comments, and it always feels like there is only one agent. They never need to wonder, "Does session X have information Y in its context?" For example, if a user first proposes Plan A on IM and later switches to Plan B in a GitHub Pull Request comment, it understands and adjusts the direction of its work.

**Productive:** It responds quickly and completes several complex tasks in parallel to a high standard. It can take the next instruction without waiting for the previous command or task to finish.

**Proactive:** It doesn't wait for users to give instructions one by one. It keeps watching events in its environment, moves forward on its own with matters worth handling, and stays quiet when no intervention is needed.

**Persistent:** It is always online, connects directly to users' real working environments, and recovers automatically when it hits anomalies during long-running operation.

A single ReAct loop cannot support all four characteristics at once; underneath, it needs a matching architecture. Similar design constraints lead to similar architectural choices. We believe that whether it is a personal assistant or an agent for commercial settings such as software development, if the goal is a system that stays online and responds concurrently to environmental events, it is likely to adopt a similar architecture underneath. Many of the problems met along the way are also very similar to problems long studied in traditional computer systems, so many classic design ideas from computer systems apply here as well.

In practice this architecture will have different variants, but we believe the following five modules form the basic framework that supports the four characteristics above: a two-level architecture (Section 2) for both *continuous* interaction and *productive* concurrency; an event-driven design (Section 3) for *proactive* response; human-facing interaction (Section 4) that keeps the interaction itself both *continuous* and *productive*; and the separation of compute, state and environments (Section 5) plus a Watchdog (Section 6) for *persistent* online operation across devices and self-healing from anomalies.

The figure below shows the overall Super-agent system architecture. The module labels [2] to [6] correspond to Sections 2 to 6 below:

*Figure labels, translated:* [3] Environmental events (Triggers): group messages, PRs, CI. [3] Two-stage filtering: Fast / Slow Path. [2] Router layer: shared context, global routing and interaction. [4] Multi-channel interaction: IM, GitHub, email. [2] Worker Session 1 to N: isolated context. Blue dashed arrow: subscription pass-through. [5] Execution environment: a lightweight daemon connects it in place. [5] Session database: persistent storage of all Session state. [6] Watchdog: external monitoring and self-healing.

To achieve both *continuous* interaction across channels and *productive* concurrency across tasks, the system faces a fundamental trade-off between continuity and throughput in how it organizes sessions underneath.

If every event goes to the same session, the context is as continuous as it can be. But a single ReAct loop runs serially, which caps its speed: tasks take a long time and throughput is low, and the intermediate details of many tasks get mixed together, which also hurts the results.

Conversely, if every event opens its own new session, concurrent throughput is highest. But once tasks are not fully independent, the lack of global context leaves each session's results cut off from the others, and several sessions each answering the user also makes the interaction confusing.

To get both continuity and throughput, we can split "maintaining global continuity" and "highly concurrent execution" into two separate levels: a long-lived **Router layer** (Section 2.1) handles all human interaction and global coordination, and a context-isolated **Worker layer** (Section 2.2) executes specific tasks concurrently, as shown below:

With this two-level architecture, the system takes over context management and concurrent execution underneath. Sessions fade from the user's view, and users always face the same Super-agent. Seen this way, making users manage sessions by hand is largely design inertia carried over from low-level LLM APIs. Sessions should be an implementation detail of the system, not a cognitive burden on users.

In existing designs, a session carries both the technical job of context management and the user-facing job of project management. Once the product is decoupled from the sessions underneath, user-facing project management is no longer limited by sessions, and what interaction and task management to expose to users becomes a separate product question. We discuss it later.

The "two levels" here are a logical division of responsibilities. Neither level has to be limited to a single session in its implementation; each can have its own internal structure. The sections below cover the Router layer and the Worker layer in turn.

2.1 Router Layer

The Router layer is a long-lived global routing layer that receives human interaction from every entry point. All cross-task information and decisions come together in the Router layer, which acts as the global sequence point, coordination point and memory. To keep this global node from becoming the system's performance bottleneck, the Router layer is designed not to execute specific tasks. It handles only human interaction and task dispatch, and it may not even be given a Bash tool.

This structure, with one central node dispatching to several execution nodes, looks on the surface like a common Agent Team, but the two have different focuses. A common Agent Team is mainly used to break down steps and coordinate roles inside a single complex task. Because the substeps are usually tightly coupled, the Team Lead often has to understand the task's details in depth, plan subtasks and coordinate members frequently, so it carries a heavy reasoning load itself. In a Super-agent, the Router layer handles only the high-level relations between tasks and their dispatch, and does not get involved in breaking down any single task. Conversely, if prompts constrain an Agent Team's main session so that it does not execute specific tasks itself, and only handles external interaction and dispatches separate tasks to members who work on them independently, it can also be seen as this two-level architecture. In our practice, the Router layer's work is often less complex than one might expect, and a lighter model can often deliver both speed and good results.

In its internal implementation, the Router layer also need not be limited to a single session, and some of its logic may not need to call an LLM at all. We chose the most direct option, a single long-lived LLM session, as the core of the Router layer. We found that it does not become a throughput bottleneck as easily as it might seem, because environmental events (the Triggers of Section 3) that arrive during one inference turn pile up and are handled together in the next turn. This forms **batching**, and the extra cost of handling them together is small:

When the external event stream is steady, Triggers enter the Router Session one at a time, and each response has low latency.

When events pour in and the Router Session starts to queue up, the Triggers that piled up during the previous inference turn are merged automatically and injected together into the next LLM call. The Router Session only does lightweight interaction and dispatch, so each step usually has a long input and a short output. Merging the backlog of Triggers into one LLM API call means they are computed in parallel in the Prefill stage, so the time per request grows much more slowly than the batch size. Within a certain range, then, the bigger the backlog, the lower the inference time amortized over each decision. The upper limit depends on context length and on how many Triggers the model can handle accurately in one turn.

We show the effect of this batching quantitatively with an experiment in Section 7.2. Together with the subscription and pass-through mechanism and Chain of Recall introduced later (Sections 3.2 and 3.3), a single long-lived Router Session keeps context continuous and is already enough at our current team size.

When scale grows further and a single session really is not enough, the Router layer can be designed internally as a multi-level filtering structure, or **sharded** horizontally into several sessions. At that point, the Router layer's internal design is essentially the trade-off between continuity and throughput. The finer the sharding, the higher the Router layer's concurrent throughput, but the lower the continuity of memory and context between shards. Until the problem of global memory is solved, this trade-off will always exist.

2.2 Worker Layer

The Worker layer is made up of the sessions that do the actual execution. Workers' contexts are isolated from one another. Each carries a full set of execution tools and focuses on completing a single task in its own context. Because Worker Sessions directly determine task results and code quality, they usually need the most capable models.

Workers do not interact with humans directly. Their reasoning and tool calls are not output directly to external channels. Instead, they report status to the Router layer, which replies to users for all of them. This keeps concurrency and delivery quality while avoiding the confusion of several sessions each replying on their own.

When several tasks run concurrently, each Worker pushes its own task forward, and Workers at the same level usually do not need to communicate directly. Conflicts between Workers during execution tend to arise in a shared working environment, such as the same Pull Request. As long as they all subscribe to the matching Thread, they receive the same event notifications (see Section 3.2) and so have a chance to find and resolve conflicts on their own. The few cases that need cross-task coordination are relayed by the Router layer.

Like the Router layer, each Worker Session need not be limited to a single session internally. When executing a complex single task, a Worker can create Subagents inside it, or can itself be an Agent Team; all of this is transparent to the Router layer above. This structure fits code collaboration, where several independent issue reproductions, Pull Request reviews and feature developments move forward at once without blocking each other. It also fits personal assistants. A personal assistant usually offers only a single-session chat page in its interface. But when a user discusses several different topics at once in the same chat box, the single chat page in front keeps the interaction continuous, while underneath, a separate Worker can be dispatched for each topic to push tasks forward and draft replies in parallel.

To make a Super-agent *proactive*, we first need to change how the system is driven. The main input that drives the agent is no longer prompts a human types into a session one at a time, but semi-structured events from the environment. In a Super-agent, environmental events such as group chat messages, emails and calendar reminders, code review comments and CI results are called **Triggers**. By listening for and responding to Triggers, the agent no longer has to wait for a human instruction before each passive run, as it does in the single-session model.

Following the life cycle of an environmental event from entry to handling, the sections below take up four questions in turn, each building on the last: how to filter out the large volume of noise with a **two-stage policy** that combines code and models (Section 3.1); how to route events to Workers with a **subscription and pass-through** mechanism (Section 3.2); how to use **Inline & Spill and Chain of Recall** to inject context densely into the model and recall more on demand (Section 3.3); and how to use **speculative execution** to act ahead in the background based on environmental signals (Section 3.4).

3.1 Event Filtering

Once connected to real group chats and code platforms, the environmental event stream shows a clear pattern of "high noise, low trigger rate": the vast majority of everyday messages do not need the agent to step in. Calling a large model to judge every event from scratch would make the latency and compute costs hard to bear. Borrowing the **Fast Path / Slow Path** idea from computer systems, large-model reasoning can be seen as a flexible but costly Slow Path, while clear, stable, frequent judgments hardened into deterministic code make a low-latency, low-cost Fast Path.

So the first step after an event enters the system is filtering. The goal is to screen out noise with deterministic policies before calling a large model, and to send only the candidate events that need semantic understanding to the model for judgment. We use a **two-stage filtering** mechanism that combines programmatic policies with a large model:

**Programmatic policies (the Fast Path):** For deterministic conditions such as the event source, the group scope, and user or bot allowlists, code runs fast admission checks directly. For example, each source can be set separately to "respond only to explicit requests," "treat as candidate events" or "ignore." This filters out most irrelevant messages before any model is called.

**Semantic policies (the Slow Path):** Candidate events that pass the programmatic checks go to the LLM, which decides whether action is needed based on policies written as prompts and on the context. The semantic stage also serves as a natural-language extension point for humans, so policies can be switched on or off, or new ones added, through prompts at any time, as shown below:

3.2 Event Routing

The global Router layer introduced in Section 2 maintains continuity across channels. But if every follow-up event for an already-assigned task still had to be forwarded through the Router layer, this global node would still carry a heavy load and push up the system's response latency. So the Fast / Slow Path idea also applies to routing filtered events. The global Router layer handles only the cold start of new tasks and cross-task coordination. Follow-up events whose owner is already settled are sent by code directly to the matching Worker session, without passing through the Router layer.

In real workflows, consecutive events under the same GitHub Pull Request, the same IM topic, or the same email chain form an event stream, which we call a **Thread**:

*Figure text, translated.* **Thread #08 (IM group topic):** Trigger #39 (first message in the topic), Zhang San: "The page sometimes goes blank when switching conversations." Trigger #40 (reply), Li Si: "Reproduced it. The console shows a null pointer exception." Trigger #42 (reply), Zhang San: "@Agent please find the cause and fix it." **Thread #15 (GitHub Pull Request #128):** Trigger #51 (Pull Request opened): "fix: null pointer when switching conversations." Trigger #54 (CI status change): "unit-test run failed." Trigger #58 (code review comment): "This needs a test for the null check." (Zhang San and Li Si are placeholder names, like John Doe.)

After the Router layer creates a Worker Session from a Thread's first event, that Worker subscribes directly to the Thread. Event routing then splits into the two paths shown below:

**Subscribed (Fast Path):** Follow-up events in the same Thread are passed by code straight through to the subscribed Worker, with no need for the Router layer to call a tool again to forward them. If a new event falls outside the current task's scope, the Worker can also unsubscribe or hand the event back to the Router layer to be dispatched again.

**Unsubscribed (Slow Path):** The Router layer can still observe all events to keep track of global state, but it judges and dispatches only new events that no Worker has subscribed to yet.

In addition, subscriptions between Threads and Workers are many-to-many. One Worker can subscribe to several related Threads, and one Thread can have several subscribed Workers. When several Workers meet in the same working environment or discussion, new events in that Thread pass straight through to every Worker subscribed to it at the same time. This gives them a chance to learn what the others are doing and resolve conflicts themselves, with no point-to-point communication. On the output side, Workers still report key conclusions to the Router layer, which replies to users for all of them and keeps global memory in sync.

3.3 Context Organization

After an event has been filtered and routed into its target session, the next question is how much information to inject into the model's context window. Because the system's input has shifted from a limited number of human prompts to semi-structured events that the environment produces continuously, the design of tool calls and event injection matters more. Inject too much, and it crowds the window and dilutes the model's attention. Inject too little, and the model is forced to call tools again and again to read, which adds execution steps. Wasting the context window is wasting the model's intelligence.

So we can manage the limited context window as a cache. Borrowing concepts from compiler optimization and computer systems, the design of context injection comes down to two basic operations. **Inline** means putting information likely to be needed soon directly into the current context window, saving extra tool-call round trips. **Spill** means keeping full information that exceeds the window budget, or is rarely used, outside the window, and leaving only a reference or summary inside it for the model to read on demand.

Combined with the classic idea of **locality** in computer systems design, we can use **Inline & Spill** to improve event injection and tool calls step by step:

1. **Start with minimal information:** At first, give only the current object's ID and a summary of its content.

2. **Use locality to Inline related information step by step:** Inline information likely to be needed soon. First attach the IDs of closely related objects, then content that is adjacent in space or time: for example, the first 50 characters of the content, the messages just before and after an IM message plus the message it replies to, or the neighboring comments in the review discussion where a code comment sits.

3. **Spill what exceeds the limit:** Set a small length cap for long content that cannot be inlined in full, and Spill the excess outside the window. One simple, direct way is to truncate the excess and leave an entry point for reading on, so the model can call a tool to read the full content when it needs it.

Also, with many follow-up events passing straight through to Workers, and many past tasks building up over long-running operation, the Router layer cannot put the full history of every task into its own context window. Yet it still needs to recover a task's context when a user brings up an old task in another channel. Applying Inline & Spill consistently to every kind of object in the system yields a multi-hop retrieval mechanism that expands on demand: **Chain of Recall**. This chained recall eases the Router layer's problem of losing earlier information over long horizons, as shown below:

Specifically, the system gives objects such as Triggers, Threads and Worker Sessions unique IDs, and inlines the IDs of closely related objects when it injects one, so that underneath, these objects form a reference graph. Because every object recalled by a tool call also follows Inline & Spill, its returned result in turn inlines the summaries and IDs of the next-hop related objects. The model can then start from the current event and recall context step by step, on demand, along the references.

For example, from a current message it can read the Thread the message belongs to, follow an ID inlined in that Thread to a related Worker Session, and from there find another code review Thread linked to that Worker.

3.4 Acting Ahead

Borrowing the idea of **speculative execution** from computer systems, an agent can try work in the background ahead of time, based on environmental signals, before it knows whether the result will be used. It spends extra background compute to cut the time humans spend waiting and stepping in. If the result is valuable, it delivers it; if not, it throws it away.

In personal assistant scenarios, when a meeting invitation email or a to-do message arrives, the agent can first check for calendar conflicts in the background, gather relevant background material and prepare a draft reply. The user then only needs to look it over and confirm sending. The same holds in R&D collaboration. For example, in the company's internal DeepSeek Harness user group, we configured a "silently reproduce and fix" policy. When someone in the group reports a problem or discusses a proposed change, the agent first tries in the background to reproduce it and find a fix. Only after it has confirmed the problem and found a simple fix does it deliver the result to users; otherwise it stays quiet the whole time.

*Figure text, translated.* **Title:** The discussion is still going, and a reliable fix is already delivered. **Setting:** a user-group discussion about tildes rendered as strikethrough.

**User A:** Tildes in the model's output are rendered as strikethrough, which makes it hard to read.

**Group discussion:** Should this be fixed in training, by having the model escape them, or by changing the rendering rules?

**Super-agent:** Pull Request submitted: only `~~text~~` renders as strikethrough; a single `~` (as in `10~20`) stays as it is.

**User B:** A single tilde is a common way to write that too. What is this change based on?

**Super-agent:** Pandoc and markdown-it support only `~~`; GFM also accepts a single `~`. In model output, a single `~` mostly marks a range, which is exactly where the bad rendering comes from.

The two-level architecture in Section 2 keeps interaction *continuous* across channels at the level of context. But to be both *continuous* and *productive* in the actual experience of working with people, two more problems must be solved, in how the interaction works and where it happens. The first is to use an **asynchronous ReAct Loop** so that slow background operations no longer block the foreground conversation, and the session can accept new instructions at any time without waiting for the previous command or task to finish (Section 4.1). The second is, when interaction happens in the different work channels users already know, to match the system's output to each channel's bandwidth and to how people use it (Section 4.2).

4.1 Full-Duplex Interaction

In the classic ReAct Loop, once the model makes a synchronous `run()` tool call, the loop blocks until the tool finishes and returns its final result. During that time, the session cannot respond to any new user input. Removing this blocking means moving the conversation from a turn-by-turn, half-duplex mode to a full-duplex mode, as shown below:

To do this, we change slow command and subtask tool calls into asynchronous `start()` and `stop()` calls, forming an **asynchronous ReAct Loop**. When the model calls `start()`, it immediately gets back "Started," and the loop no longer waits for that tool. When the background tool finishes, the system delivers its final result into the session as a new event message. The model can also call `stop()`, based on the context, to end a background command that is running too long.

This decouples the foreground conversation from background task execution, so the agent can respond to human input while slow tasks run in the background. New input is handled as soon as the current inference step ends, without waiting for background tools to finish.

This asynchronous task mechanism is already implemented in DeepSeek Harness, but it is not yet on by default.

4.2 Multi-Channel Interaction

Different work channels have different information density and interaction habits, and the system's output needs to match them. If the interaction style meant for a single-user terminal is moved straight into a group chat, with lengthy reasoning and dense tool calls output as they are, it can easily overload people with information when many work together.

In a Super-agent, the two-level architecture already solves part of this problem. The lengthy reasoning and dense tool calls of each task are isolated inside the Worker Session and never go directly to external channels; the Router layer handles all external interaction. On top of that, the system needs to connect to the work environments users rely on every day, and use prompts to set interaction norms for each channel:

**IM and other instant messaging channels:** Favor light, low-interruption communication. Like a human colleague, send notifications only when a decision or sign-off is needed, ask only direct questions, and give short conclusions. One simple, effective hard rule we have verified: no more than 100 words per reply.

**Asynchronous channels such as GitHub, email and documents:** Favor structured, information-dense asynchronous delivery. For example, when creating or updating a Pull Request, write out the full problem background, the change description and the verification results according to the project's conventions; or, in personal assistant scenarios, draft structured emails and document summaries directly.

By default, existing local agents bind three things to the same device: the **compute** that drives the Agent Loop, the session **state** that must persist, and the execution **environment**, such as code repositories and local toolchains. Once the device sleeps or goes offline, the agent stops running, and it cannot reach environments on other devices. To keep a Super-agent *persistently* online and able to connect flexibly to all kinds of real working environments, we can borrow the idea of **compute-storage separation** from computer systems and undo the binding of these three in two steps. The first step separates the compute that drives the Agent Loop from the persistent session state. This frees the agent from the life cycle of any single machine, so it stays online in the cloud (Section 5.1). The second step decouples the cloud Agent Loop from state-heavy execution environments, so real working environments stay where they are and can be reached across devices (Section 5.2).

5.1 Separating Compute from State

The compute that drives the Agent Loop can be made stateless; what needs to persist is the session state. So the first level of decoupling puts the compute that drives the Agent Loop into stateless, elastic compute containers in the cloud, and stores persistent state such as Sessions in a database. The stateless containers can scale out, restart or be replaced, while persistent storage guarantees the continuity of sessions and tasks. The agent is freed from the life cycle of a single local device and stays persistently online in the cloud.

5.2 Separating Compute from Execution Environments

Once the Agent Loop and session state live in the cloud, the next question is how to reach the execution environments that tasks need. Much of the context a model works with has to be fetched through tool calls from execution environments such as code repositories, local files and dependent services. In that sense, context in the broad sense includes the execution environment itself.

There are two common approaches. One starts a sandbox in the cloud, pulls the code, and tries to rebuild and sync the environment. But real working environments often include uncommitted local changes, private credentials, dependencies on intranet services, and specific hardware or toolchains, so syncing such an environment is not only technically costly but also prone to missing things. The other simply asks users to give up their local environments and move their work to the cloud, but for many users that migration costs too much.

Since what is hard to copy and sync is the environment itself, there is no need for the execution environment to follow the Agent Loop to the cloud. The second level of decoupling runs the Agent Loop in the cloud and leaves state-heavy execution environments where they are. Each device runs only a lightweight daemon that keeps no session state and only executes commands and returns results. In effect, the execution environment stays outside the cloud, and the agent reads context from it on demand.

This approach matches Anthropic's "Decoupling the brain from the hands": it likewise keeps the harness stateless, stores session logs outside the harness, and connects execution environments on demand through a unified interface. The difference between the two is the scenario. That article describes a managed service and mainly discusses sandboxes created on demand and resources inside customer VPCs. What needs connecting here, first of all, are the personal machines people work on every day, which may be online only some of the time and hold uncommitted changes and local credentials. So this design supports **BYOM (Bring Your Own Machine)**, which connects the development machines or personal computers users work on every day to the cloud agent. It also supports cloud-hosted machines and compute environments created on demand.

As a result, an agent is no longer limited to a single machine. It can switch between execution devices, choosing the environment a task needs to run commands in and to get context from. It can even work with devices that are online only some of the time: for example, when one of a user's personal devices comes back online, the cloud agent automatically triggers and completes the tasks that need to run on that device. The figure below shows the structure after compute, persistent state and the various execution environments are decoupled at two levels:

To stay *persistently* online, the system needs more than the compute-storage separation of Section 5. It must also recover from anomalies automatically during long-running operation. A persistently online distributed system can hardly guarantee long-term reliable operation from the main system's internal logic alone. It needs an independent external control loop outside the main system: a **Control Loop**.

At the same time, in an agent system, traditional process liveness probes or monitoring scripts are not enough, because many anomalies are not process crashes. Instead, the model gets stuck in an unproductive loop during execution, or drifts from its goal. So a long-running agent system needs to monitor not only the liveness of its infrastructure but also the progress of the tasks themselves.

We set up an independent **Watchdog Session** outside the main system, driven by scheduled messages, which forms the external Control Loop. Besides handling infrastructure failures such as API errors and failed state recovery, the Watchdog also uses the model to judge whether each Worker is making substantive progress and whether its direction has drifted from the overall goal. When it finds an anomaly, it steps in promptly to fix it. When it meets a transient external failure, it keeps rechecking until things are back to normal.

Because the Watchdog is itself an agent session with a full set of tools, maintainers can ask it in natural language what caused a failure. They can also have it correct the main system's behavior while it runs, for example by adding or removing prompts or adjusting trigger rules.

To evaluate the core scheduling and routing designs above, we ran preliminary experiments at two levels. First, an end-to-end experiment compared the two-level architecture, subscription pass-through and single-session designs (Section 7.1). Then we tested the Router layer's batching on its own (Section 7.2). The experiments use synthetic workloads and simplified environments, and parts of the setup could be more rigorous, so the results below are a preliminary reference only.

7.1 Ablation Study

We drove four end-to-end designs at the same time with a stream of group chat and GitHub CI messages. Each run had about 300 messages, of which about 20 were work requests; the rest were casual chat, follow-ups, requests to stop, and CI messages. Coding work was replaced by a tool that only consumes time, so the experiment measures the system's scheduling and coordination, not its ability to execute any single task. Each design was run 5 times.

The four designs compared are **Super-agent**, **Super-agent without pass-through**, and **Single Session + Subagent tool** under two prompt settings.

The **neutral prompt** reads: *"Use a subagent for a piece of work when appropriate..."*

The **delegation-first prompt** reads: *"Every message of the chat reaches you, so work you run yourself keeps stopping for new messages. Prefer handing each piece of work to a subagent of its own, and do only small things yourself..."*

*Chart labels, translated:* title, "Cumulative arrival and completion of work requests." Horizontal axis, time (minutes). Vertical axis, cumulative tasks (mean per run). Black: work requests arrived. Blue: Super-agent. Green dashed: Super-agent without pass-through. Red: Single Session + Subagent tool, neutral prompt. Purple: Single Session + Subagent tool, delegation-first prompt.

| Design | Task completion time, p50 / p95 (minutes) | Cache-read tokens per run (all Sessions) |

|---|---|---|

| Super-agent | 12.4 / 15.7 | 23.23 million |

| Super-agent without pass-through | 12.6 / 15.5 | 31.77 million |

| Single Session + Subagent tool, neutral prompt | 20.4 / 29.5 | 6.05 million |

| Single Session + Subagent tool, delegation-first prompt | 13.8 / 29.0 | 10.82 million |

*Note: each design was run 5 times. Task completion time is the time from a work request to its result message. (The original shows this table as an image.)*

On task completion time, Super-agent's p50 and p95 are 12.4 and 15.7 minutes, clearly better than the single session with a Subagent tool. The reason is that, in this experiment, the single session with Subagents depended heavily on its prompt: the main session often decided to do the work itself, which made total completion time long and performance unstable. Under the neutral prompt, the model did not call a Subagent once in 5 runs. All work ran in the main session and was constantly interrupted by new messages, and p95 reached 29.5 minutes. With the delegation-first prompt, the model delegated in 4 of the 5 runs. Completion times came down somewhat but were still slower than Super-agent overall, and in the remaining run the model judged the work "small" and chose to do it itself, which produced the purple long tail in the figure. Rather than relying on prompt engineering and the model's on-the-spot judgment in a single session to decide whether to split up the work, the two-level architecture eases this problem at the system level: the Router does not execute specific work itself, and each Worker receives only the messages of the Threads it subscribes to.

On system overhead, Super-agent maintains several independent sessions, so it reads more cached tokens per run than the single session. It trades more token use for shorter and more stable completion times. Within Super-agent, removing the pass-through mechanism left task completion times about the same as the full version, but the Router had to make about 30% more decisions per run, and total cache-read tokens rose from 23.23 million to 31.77 million, about 37% more. This shows that under the experimental workload, pass-through does not improve the quality or speed of task completion, but it saves the Router Session a considerable amount of tokens and inference overhead.

7.2 Router Layer Batching

To verify the throughput limit of the single long-lived Router Session and its batching mechanism from Section 2.1, we stress-tested the Router layer on its own. The Router called a real model while the Workers used mock models, and we raised the arrival rate of Triggers needing a decision step by step from about 1 per minute to about 40 per minute. We measured the average batch size, the time per request, and the inference time amortized over each decision.

*Chart labels, translated:* left panel, "Batch size and time per request": blue, batch size B (Triggers per request); orange dashed, time per request T (seconds). Right panel, "Amortized inference time per decision" (seconds). In both panels the horizontal axis is the arrival rate of Triggers needing a decision (per minute).

As the figure shows, when the arrival rate of Triggers needing a decision rose from about 1 to about 40 per minute, the average batch size rose from 1.0 to 2.8, while the time per request rose only from 2.5 seconds to 3.9 seconds, more slowly than the batch size. So the inference time amortized over each decision fell from 6.4 seconds to 1.6 seconds. This means that when external events arrive in a burst and pile up, the Router layer raises its effective throughput by merging the backlog automatically. It also explains why, in Section 7.1, removing pass-through raised the Router's peak load but still did not reach the throughput limit of a single Router. So at our current team size, there is no need to shard the Router layer early at the cost of global context continuity.

The five modules in Sections 2 to 6 form the basic architecture that keeps a Super-agent running, and the experiments in Section 7 confirmed that its core scheduling and routing mechanisms work when many tasks run concurrently. The system can run with fairly low complexity largely because we made a series of engineering and scenario simplifications at this stage. Beyond the range where those simplifications hold, some problems remain to be solved: scaling the two-level architecture (Section 8.1), human-agent collaboration once sessions are gone (Section 8.2), context boundaries and A2A (Section 8.3), and security and privacy (Section 8.4).

8.1 How to Scale the Two-Level Architecture

The simplified combination above, "a single long-lived Router Session, subscription pass-through, and no direct communication between Workers," covered most of our current daily tasks at a small engineering cost. But when tasks grow larger and more tightly coupled, beyond what a single Router Session can carry, the right internal structure for each layer is not settled. When the Router layer needs horizontal sharding and at what granularity, and when Workers at the same level need direct communication and with what collaboration topology, still have to be tested in more scenarios. Co-design of the system and the model is also a direction worth exploring: training a model specifically for the Router layer's tasks, such as judging events, dispatching in batches and recalling context, may further improve the Router layer's throughput and decision quality.

Meanwhile, the long-lived Router layer, together with Chain of Recall over the reference graph, mainly solves on-demand retrieval of recent tasks and session history. When the operating period stretches across months or longer, long-term memory becomes the main bottleneck on scalability.

8.2 How to Work with an Agent Once Sessions Are Gone

The two-level architecture hides the management of many sessions from users, so sessions are no longer the first question of product design. But once the execution sessions underneath no longer correspond directly to the conversations in the user interface, a new question arises: how to present tasks to users, and what natural forms of interaction and project management to offer. We think chat-window-centered interaction is to some extent the result of path dependence. More interaction may be able to happen in domain-specific interfaces, for example by letting the Super-agent work directly in GitHub Issues and Pull Requests, as the instance in this article does. Sessions can also stay in the interface out of user habit, but one conversation the user sees need not correspond to only one session underneath.

Also, the sections above mainly discussed human interaction at the start of a task and at the acceptance of its result. But in this transition period, while model capabilities are evolving fast, many tasks still need a person partway through. How product design can balance users' step-by-step intervention on key details with the efficiency of autonomous background work is also worth exploring: for example, letting users step in, take over, or work with the agent in real time at any point during background execution.

Overall, the project management and interaction that users need are closely tied to their specific work domain and personal style, and the final form is likely to be highly customized. Because DeepSeek Harness has an open architecture, it can support this kind of customization more easily.

8.3 How to Draw Context Boundaries and Collaborate via A2A

So far, the discussion has been about the design inside a single Super-agent instance, assuming that all information within its scope is gathered in one global context. But when use expands from individuals or small teams to larger organizations, deciding how to provision Super-agents is in effect drawing the boundaries of context sharing and isolation. The parts that need shared context share one instance; the parts that need isolation each get their own.

Going further, once there are several mutually isolated instances within or across organizations, for example each member's personal assistant and the team's shared Super-agent, collaboration across those boundaries is agent-to-agent communication (A2A, not meaning any particular protocol). How agents that share no underlying context, and each represent a different permission boundary, can communicate and collaborate securely and reliably still needs further exploration.

8.4 How to Ensure Security and Privacy

The event-driven design of Section 3 lets the agent be driven by a wider range of environments, but it also raises the risk of exposure to untrusted input. If security and privacy cannot be solved well, a Super-agent can only work within a very small, trusted scope.

For example, Section 5 deploys the Agent Loop in the cloud and installs a lightweight daemon on each execution device. This design assumes by default that the cloud and the device environments trust each other. But when the cloud Agent Loop keeps taking in external environmental events, and the devices hold private code, sensitive data and local credentials, this cross-device connection brings significant security and privacy risks. Once the cloud Agent Loop is compromised, through a server-side intrusion or prompt injection, every device connected to it faces the potential risk of being taken over.

Moreover, even if the cloud is not compromised, as long as credentials in a device environment can enter the model's context, there is a risk of credential leakage during normal execution too. So mechanisms are also needed that let the agent use credentials without ever touching the credentials themselves. If this architecture is to see wider use, it must solve these security and privacy problems while still being able to recall context from diverse environments.

Looking back over the whole design, we have not proposed any new theory. We have applied classic engineering ideas from computer systems to building agent systems. Specific implementations will evolve as technology develops, but we believe the system design thinking behind them has longer-term reference value. Today, the internal Super-agent instance we built on these ideas and DeepSeek Harness runs continuously. Every day it takes part in reproducing and fixing issues, responding to code reviews, and the development of DeepSeek Harness itself.

As noted at the start, as large models need less and less human intervention to execute single tasks, the bottleneck on further productivity gains is shifting to human attention. Through the two-level architecture, event-driven design, asynchronous multi-channel interaction, compute-storage separation and an external Watchdog, the system takes over the tedious work of session management and context syncing underneath, letting people move further up, from execution details to higher-level decisions and acceptance.

In this form, the agent is no longer just a chat window passively waiting for instructions. It becomes an always-online, autonomous collaborator in the digital environment. For individuals, it can be a personal assistant that helps with daily matters across devices; for teams, it fits into R&D workflows, taking on specific tasks and pushing them forward. We believe that as model capabilities and the underlying system architecture evolve together, this more autonomous way of working may become the norm for human-machine collaboration.

Some of the designs in this article are implemented in dsh-superagent-prototype (the post's "Read more" link goes to the GitHub repository, <https://github.com/deepseek-ai/dsh-superagent-prototype>). This plugin is only a prototype offered to validate the technical approach. It is not an official DeepSeek product.

**Author & Acknowledgements**

This article comes from the shared practice of the DeepSeek Harness team. Yujia Qiao built the system and wrote this article. Huanqi Cao, Zui Chen, Xieting Chu, Tianyi Cui, Shiyuan Feng, Yudong Han, Kexin Liu, Shichun Liu, Gesi Luo, Yifan Shi, Tongrui Xiong, Hanxiang Xu, C.C. Yu, Ziya Zhang, F. Zhou and others took part in review and discussion and gave feedback. The system's implementation and this article owe much to the team's day-to-day exchanges and accumulated experience.

*Translator's note: the WeChat post ends with a DeepSeek product department job notice (Beijing and Hangzhou). It is left out here.*

Top Comments

1. @MrPingChecks

Author: Mr. Ping

Posted: 2026-11-01T13:08:57.000Z

URL: [https://x.com/MrPingChecks/status/2116880171282411777](https://x.com/MrPingChecks/status/2116880171282411777)

(No text content)

Likes: 247

2. @mylifcc

Author: lifcc

Posted: 2026-11-01T11:54:56.000Z

URL: [https://x.com/mylifcc/status/2116861546068594812](https://x.com/mylifcc/status/2116861546068594812)

其实没那么复杂，我放一张图帮大家理解

Likes: 192

3. @Maxrune

Author: MaxRune☄️☄️

Posted: 2026-11-01T12:35:39.000Z

URL: [https://x.com/Maxrune/status/2116871794128994562](https://x.com/Maxrune/status/2116871794128994562)

TL;DR

Likes: 136

Key Takeaways

**The problem.** One agent can now finish a hard task with little help. But a person can follow only 3 to 5 active sessions at once. So the limit on one task is the model, and the limit on many tasks is human attention.

**The idea.** A "Super-agent" is one always-on agent that works across chat, GitHub and email. It has four traits. It is *continuous*: it feels like one agent everywhere. It is *productive*: it runs many tasks in parallel and takes new instructions mid-task. It is *proactive*: it watches events, acts when something is worth doing, and stays quiet otherwise. It is *persistent*: it stays online and recovers on its own.

**Five modules, each borrowed from classic computer systems:**

1. *Two levels.* A long-lived Router talks to people and hands out work. It does no work itself. Isolated Workers each do one task and report back to the Router, which does all the replying.

2. *Event-driven Triggers.* Code drops most noise first (the fast path), and a model judges the rest (the slow path). A Worker subscribes to its Thread (a pull request, a chat topic, an email chain), so follow-ups go straight to it. Context stays lean: inline what is likely needed and leave the rest behind IDs the model can follow ("Chain of Recall"). The agent also starts likely work in the background and speaks only if it pans out.

3. *Full-duplex chat.* Slow tools run in the background (start and stop calls), so the agent keeps talking while work runs. Replies fit the channel: at most 100 words in chat, full write-ups on GitHub and email.

4. *Compute, state and environment kept apart.* The agent loop runs in stateless cloud containers, and sessions live in a database. A small daemon on each machine, your own laptop included ("BYOM"), runs commands where the code and credentials already are.

5. *A Watchdog.* A separate agent session runs on a schedule. It checks the infrastructure and also whether each Worker is making real progress.

**Results** (synthetic test, about 300 messages with about 20 work requests, 5 runs each). Super-agent finished tasks in 12.4 minutes at p50 and 15.7 at p95. A single session with a subagent tool took 20.4 and 29.5 with a neutral prompt; it never delegated. With a delegation-first prompt it took 13.8 and 29.0. Super-agent used more tokens: 23.2 million cache-read tokens per run, against 6.1 to 10.8 million. Without pass-through, the Router made about 30% more decisions and used about 37% more tokens.

**Batching.** One Router session kept up with about 40 decisions a minute. Batches grew from 1.0 to 2.8 Triggers, and the time per decision fell from 6.4 to 1.6 seconds.

**Open problems.** When to split the Router. Memory beyond a few months. How people work with an agent that has no sessions. Context boundaries and agent-to-agent (A2A) work across teams. Security: prompt injection, a hacked cloud loop that reaches every connected machine, and keeping credentials out of the model's context.

**Status.** DeepSeek runs an internal instance every day. It reproduces and fixes issues, answers code reviews and works on DeepSeek Harness itself.