Exploring Super-agent Design (English translation)

This is an English translation of “Exploring Super-agent Design: Towards a More Autonomous Agent System” (Super-agent 设计探索：迈向更自主的 Agent 系统), published in Chinese by the DeepSeek Harness team on their WeChat account on 31 October 2026 (original), alongside the open-source dsh-superagent-prototype. Everything below the line is their text and their argument. The translation was made by AI and has not been reviewed by a human, so expect errors and check the original before relying on any detail.

This article is an exploration of architectural ideas for engineering practice, not a description of existing DeepSeek Harness product features.

1 Super-agent

Over the past year, single-task agents, with coding agents in the lead, have shown that models can use tools to solve complex problems while needing less and less continuous human monitoring and step-by-step intervention. At the same time, models have become better at multi-agent collaboration, so organizing and scheduling work across sessions is now feasible. As people take less part in low-level execution, their role is moving up to higher-level decisions and acceptance of results.

This rise in model capability has also produced new kinds of applications. Personal agents have recently appeared in numbers. They connect directly to everyday messages, calendars, email and work platforms, keep watching the stream of information and help handle tasks. This always-on, event-driven way of working is not limited to personal use; personal assistants are only one class of application. It is just as valuable in business settings such as software development.

Today’s mainstream agent designs, however, struggle to support this mode at the scale of many tasks and team collaboration. Agents still work with the single session as the basic unit, and sessions are independent of each other. A user who pushes several pieces of work forward in parallel has to switch between sessions by hand and remember each one’s context, and in our observation a person can usually follow only three to five active sessions at once. Under this design, the ceiling of a single task is set by model capability, and the ceiling of multitasking is set by human attention.

If we only extend existing local, single-session agents with CLIs, MCP or external connectors, the agent can receive outside messages, but it remains limited by synchronous blocking within one session, mixed-up context across tasks, and stopping as soon as the local device goes offline. It needs a lot of manual upkeep.

Breaking through these limits requires untying the agent from the single manual session, so that it becomes a continuous entity that keeps context across sessions and advances several complex tasks at once without them interfering. We call this form of agent, and its system architecture, a Super-agent.

For example, in the Super-agent instance we run internally on DeepSeek Harness, one development task can move continuously between IM and GitHub. The same instance also keeps watching feedback in a public group chat and, without anyone @-mentioning it, proactively finds root causes and opens fix pull requests:

Figure 1. The same task carried continuously between an IM group chat and a GitHub pull request review.

Figure 2. Continuously following a public group chat and, without being @-mentioned, proactively identifying a defect and opening a fix pull request.

Concretely, we think a Super-agent has four basic properties:

Continuous. Users interact with it directly in familiar work surfaces such as IM chats and GitHub comments, and it feels as if only one agent exists. Nobody has to wonder “does session X have information Y in its context?”. For example, if a user first proposes approach A in IM and later switches to approach B in a GitHub pull request comment, it understands and changes course.

Efficient. It responds quickly and completes several complex tasks in parallel with high quality. It accepts the next instruction without waiting for the previous command or task to finish.

Proactive. It does not wait for users to issue instructions one by one. It keeps watching events in its environment, proactively moves forward on things worth handling, and stays quiet when no intervention is needed.

Persistent. It is always online, connected directly to the user’s real working environment, and recovers automatically from failures during long-running operation.

A single ReAct loop cannot support all four properties at once; it needs a matching architecture underneath. Similar design constraints lead to similar architectural choices. We believe that any system meant to stay online and respond concurrently to environment events, whether a personal assistant or an agent for business settings such as software development, will probably adopt a similar architecture underneath. Many of the problems along the way also closely resemble problems that computer systems have studied for decades, so many classic ideas from computer systems apply here as well.

Concrete implementations will vary, but we think the following five modules form the basic framework behind the four properties: a two-layer architecture (Section 2) balances continuous interaction with efficient concurrency; event-driven operation (Section 3) enables proactive response; human-facing interaction (Section 4) keeps interaction both continuous and efficient; and the separation of compute, state and environment (Section 5), together with a watchdog (Section 6), provides persistent, cross-device availability and self-healing.

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

Figure 3. Overall Super-agent architecture. Labels [2] to [6] correspond to Sections 2 to 6.

2 Two-layer architecture

To achieve both continuous interaction across channels and efficient 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, context is as continuous as it gets. But a single ReAct loop executes serially, which caps its speed: tasks take long, throughput is low, and the intermediate details of many tasks get mixed together, which also hurts the results.

Conversely, if every event opens a new, independent session, concurrent throughput is highest. But as soon as tasks are not fully independent, the lack of global context leaves the sessions’ results disconnected from each other, and several sessions each answering the user creates confusing interaction.

To balance continuity and throughput, we can split “maintaining global continuity” and “highly concurrent execution” into two separate layers: a resident Router layer (Section 2.1) handles all human interaction and global coordination, and a context-isolated Worker layer (Section 2.2) executes concrete tasks concurrently, as shown below:

Figure 4. Two-layer architecture: the Router layer handles routing and all outward interaction; several Worker sessions execute tasks concurrently in isolation.

With this two-layer architecture the system takes over context management and concurrent execution underneath, which makes sessions fade from the user’s view: the user always faces one and the same Super-agent. Seen this way, making users manage sessions by hand is largely design inertia carried over from the underlying LLM APIs. A session should be an implementation detail of the system, not a cognitive burden for the user.

In current designs, the session carries both technical context management and user-facing project management. Once the product is decoupled from the underlying sessions, user-facing project management is no longer bound by them, and what interaction and task management to expose to users becomes a separate product question. We come back to it later.

“Two layers” here is a logical division of responsibility. Neither layer has to be a single session in its implementation; each can have its own internal structure. The following subsections describe the Router layer and the Worker layer.

2.1 The Router layer

The Router layer is a resident, global routing layer that handles human interaction from every entry point. All cross-task information and decisions converge there, and it serves as the global sequence point, coordination point and memory. To keep this global node from becoming a performance bottleneck, the Router layer is designed not to execute concrete tasks itself. It only handles human interaction and task dispatch, and may not even have 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 emphasis differs. Agent teams are mainly used to break down steps and divide roles within a single complex task. Because the sub-steps are usually tightly coupled, the team lead often needs a deep understanding of task details, plans subtasks and coordinates members frequently, so it carries a heavy reasoning load itself. In a Super-agent, the Router layer only handles high-level relationships between tasks and dispatch, and does not get involved in breaking down any single task. Conversely, if an agent team’s main session is told by its prompt not to execute concrete tasks itself, only to handle outward interaction and hand different tasks to members to pursue independently, it can also be seen as this two-layer architecture. In our practice, the Router layer’s work is often less complex than one might expect, and a lighter model often achieves both speed and good results.

Internally, the Router layer also need not be a single session, and some of its logic may not need an LLM at all. We chose the most direct implementation, a single resident LLM session at the core of the Router layer, and found that it is not as easily a throughput bottleneck as it seems. Environment events (the Triggers of Section 3) that arrive during one round of inference pile up and are handled together in the next round, forming natural batching, and merging them costs little extra:

• When the external event stream is steady, Triggers enter the Router session one at a time and the latency of each response is low.
• When events pour in and the Router session starts to queue, the Triggers that piled up during the previous round are merged automatically and injected together in the next LLM call. The Router session only does light interaction and dispatch, so each step is typically long input and short output. Merging the backlog into one LLM API call is computed in parallel during prefill, so a single request’s duration grows much more slowly than the batch size. Within a certain range, the bigger the backlog, the lower the inference time amortized per decision. The upper limit depends on context length and on how many Triggers the model can handle accurately in one round.

Section 7.2 shows the effect of this batching quantitatively. Together with the subscription and pass-through mechanism and chain of recall introduced later (Sections 3.2 and 3.3), a single resident Router session keeps context continuous and, at our current team size, is sufficient.

When scale grows further and a single session really is not enough, the Router layer can be built internally as a multi-stage filter or sharded horizontally into several sessions. Its internal design is then, at heart, again a 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 remains.

2.2 The Worker layer

The Worker layer consists of the sessions that do the concrete execution. Workers have isolated contexts, carry the full set of execution tools, and focus on completing a single task in their own context. Because worker sessions directly determine task results and code quality, they usually need the most capable model.

Workers do not interact with people directly. Their reasoning and tool calls are not written out to external channels. Instead they report status to the Router layer, which answers the user on everyone’s behalf. This keeps concurrency and delivery quality high while avoiding the confusion of several sessions each replying.

When several tasks run concurrently, each worker advances its task independently, and workers in the same layer usually do not need to talk to each other. Conflicts between workers usually arise in a shared working environment such as the same pull request. As long as they all subscribe to the corresponding Thread, they receive the same event notifications (see Section 3.2) and so have a chance to notice and resolve conflicts themselves; the few cases of cross-task coordination are relayed through the Router layer.

As with the Router layer, a worker session need not be a single session internally. For a complex single task, a worker can create subagents or be an agent team itself, transparently to the Router layer above. This structure suits code collaboration (reproducing several independent issues, reviewing pull requests and developing features at the same time without blocking each other) as well as personal assistants. A personal assistant usually offers only a single chat page in its interface. When the user discusses several topics in the same conversation, the front-end chat page keeps the interaction continuous, while underneath a worker can be dispatched per topic to advance tasks and draft replies in parallel.

3 Event-driven operation

For a Super-agent to be proactive, the first thing to change is what drives the system. The main input driving the agent is no longer prompts that a person types into a session one by one, but semi-structured events from the environment. In a Super-agent, environment events such as group chat messages, emails and calendar reminders, code review comments and CI results are called Triggers. By listening and responding to Triggers, the agent no longer has to wait, as in single-session mode, for a person to give an instruction before it passively runs once.

Following the life cycle of an environment event from arrival to handling, the following sections discuss four successive questions: how to filter out a large volume of noise with a two-stage policy that combines code and model (3.1); how to route events to workers through subscription and pass-through (3.2); how to inject context densely and recall more on demand using Inline & Spill and chain of recall (3.3); and how to use speculative execution to act early in the background on environment signals (3.4).

3.1 Event filtering

Once connected to real group chats and code platforms, the event stream shows a pronounced “high noise, low trigger rate” pattern: the vast majority of everyday messages need no action from the agent. Calling a large model to judge every event from scratch would make latency and compute cost unbearable. Borrowing the fast path / slow path idea from computer systems, LLM inference can be seen as a flexible but expensive slow path, while frequent judgements that are already clear and stable are hard-coded as deterministic code, forming a low-latency, low-cost fast path.

So the first step after an event enters the system is filtering. The goal is to remove noise with deterministic policy before calling the model, and to pass only candidate events that need semantic understanding to the model. We use a two-stage filter that combines program policy with the LLM:

• Program-level policy (the fast path): quick admission checks in code against deterministic conditions such as the event source, group scope, and user or bot allowlists. For example, each source can be set to “respond only to explicit requests”, “treat as candidate events” or “ignore”, which removes most irrelevant messages before any model call.
• Semantic policy (the slow path): candidate events that pass the program-level check go to the LLM, which decides from prompt-written policy and context whether to act. The semantic layer also serves as a natural-language extension point for people, so policies can be switched on or off or added at any time through prompts, as shown below:

Figure 5. Two-stage filtering: program-level policy removes most irrelevant messages first (no LLM call for unrelated sources); semantic policy then decides, staying silent on discussions that need no intervention.

3.2 Event routing

The global Router layer from Section 2 maintains continuity across channels. But if every follow-up event of an already assigned task still had to be forwarded through the Router layer, this global node would carry a heavy load and push up response latency. So the fast path / slow path idea applies to routing filtered events as well. The global Router layer handles only the cold start of new tasks and cross-task coordination, while follow-up events whose owner is already known are sent by code directly to the corresponding worker session, without going through the Router layer.

In real workflows, consecutive events on the same GitHub pull request, the same IM topic or the same email thread form one event stream, called a Thread:

Figure 6. Thread examples: consecutive Triggers on the same IM topic or the same GitHub pull request form a Thread.

After the Router layer creates a worker session from a Thread’s initial event, that worker subscribes directly to the Thread, which splits event routing into the two paths shown below:

• Subscribed (fast path): follow-up events on the same Thread are passed by code straight to the subscribed worker, with no tool call by the Router layer to forward them. If a new event falls outside the current task’s scope, the worker can unsubscribe or hand it back to the Router layer for re-dispatch.
• Unsubscribed (slow path): the Router layer can still observe all events to keep track of global state, but only judges and dispatches new events that nobody has subscribed to yet.

Figure 7. Subscription and pass-through: the initial event goes through the Router layer, which creates a worker and sets up the subscription; later events on the same Thread go straight to that worker.

Subscriptions between Threads and workers are many-to-many. A worker can subscribe to several related Threads, and a Thread can have several subscribed workers. When several workers meet in the same working environment or discussion, new events on that Thread are passed to all of its subscribers at once, so they can learn of each other’s actions and resolve conflicts themselves without point-to-point communication. On the output side, workers still report key conclusions to the Router layer, which answers the user and updates the global memory.

3.3 Organizing context

Once an event has been filtered, routed and has reached 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 limited human prompts to semi-structured events that the environment produces continuously, the structure of tool calls and event injection matters more. Inject too much and the window fills up and the model’s attention is diluted; inject too little and the model has to call tools again and again to read, which adds steps. Wasting the context window means wasting the model’s intelligence.

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

Combined with the classic idea of locality from computer systems, Inline & Spill lets us optimize event injection and tool calls step by step:

1. Start with minimal information: at first, provide 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 time or space, such as the first 50 characters of the content, the messages before and after an IM message and the message it replies to, or the neighboring comments in the review discussion a code comment belongs to.
3. Spill what exceeds the limit: give long content that cannot be fully inlined a small length cap, and spill the rest outside the window. A simple, direct way is to truncate the excess and leave a pointer for reading on; the model calls a tool when it needs the full content.

Moreover, once many follow-up events pass straight to workers and the system has accumulated many past tasks over long operation, the Router layer can neither hold the full history of every task in its own context window nor afford to lose context when a user brings up an old task on another channel. Applying Inline & Spill consistently to every kind of object in the system yields a multi-hop retrieval mechanism that unfolds on demand, which we call chain of recall. It eases the Router layer’s tendency to lose earlier information over long horizons, as shown below:

Figure 8. Chain of recall: every recalled object inlines the IDs of the next-hop related objects, so context can be unfolded hop by hop along references.

Concretely, the system gives objects such as Triggers, Threads and worker sessions unique IDs, and inlines the IDs of closely related objects when injecting them, so the objects form a reference graph underneath. Because every object recalled by a tool call follows Inline & Spill as well, its result inlines summaries and IDs of the next hop, and the model can start from the current event and recall context step by step along the references as needed.

For example, from a current message it reads the Thread it belongs to, follows an ID inlined in the Thread to a related worker session, and from there finds another code review Thread that worker is linked to.

3.4 Acting ahead of time

Borrowing the idea of speculative execution from computer systems, an agent can try things in the background based on environment signals before it is clear whether the result will be used, spending extra background compute to reduce how long people wait and how often they have to step in. If the result is valuable it is delivered; if not, it is discarded.

For a personal assistant, when a meeting invitation or a to-do message arrives, the agent can check calendar conflicts in the background, gather relevant background material and prepare a draft reply, which the user only has to review and send. The same holds for development work. In the company’s internal DeepSeek Harness user group, for example, 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 to reproduce it and look for a fix in the background, and delivers the result only once it has confirmed the problem and found a simple fix. Otherwise it stays quiet the whole time.

Figure 9. Speculative execution: while the group is still discussing solutions, Super-agent has already opened a fix pull request in the background.

4 Human-facing interaction

The two-layer architecture of Section 2 ensures continuity across channels at the level of context. To make actual human-agent interaction both continuous and efficient, two more problems must be solved in how and where interaction happens. First, how an asynchronous ReAct loop removes the blocking that long-running background operations impose on the foreground conversation, so the session can take a new instruction at any time without waiting for the previous command or task (4.1). Second, when interaction happens in different work channels people already use, how the system’s output matches each channel’s bandwidth and people’s habits there (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, and during that time the session cannot respond to any new user input. Removing this blocking means turning the conversation from half-duplex question-and-answer into full duplex, as shown below:

Figure 10. Classic versus asynchronous ReAct loop: the asynchronous call returns a “Started” notice at once, and the session can still answer new messages while the background tool runs.

To do this, we turned long-running command and subtask tool calls into asynchronous start() and stop(), forming an asynchronous ReAct loop. After calling start(), the model 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 context to end a background command that is taking too long.

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

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

4.2 Multi-channel interaction

Different work channels have different information density and interaction habits, and the system’s output has to match them. Moving the interaction style of a one-person terminal straight into a group chat, and dumping long reasoning and dense tool calls there as they are, quickly overloads everyone in a multi-person collaboration.

In a Super-agent, the two-layer architecture already solves part of this: long reasoning and dense tool calls stay inside worker sessions and are never written to external channels, and the Router layer handles all outward interaction. On top of that, the system needs to connect to the work environments people use every day, and use prompts to define interaction rules for each channel:

• Instant messaging channels such as IM favor light, low-interruption communication. Like a human colleague, the agent only sends a notification when a decision or acceptance is needed, asks only direct questions and gives short conclusions. One simple, effective hard rule we have validated: no single reply longer than 100 words.
• Asynchronous channels such as GitHub, email and documents favor structured, information-dense asynchronous delivery. For example, when creating or updating a pull request the agent writes the full problem background, change description and verification results according to the project’s conventions; for a personal assistant it drafts structured emails and document summaries directly.

5 Separating compute, state and environment

Existing local agents by default bind three things to the same device: the compute that drives the agent loop, the session state that must be persisted, and the execution environment, such as code repositories and the local toolchain. As soon as the device sleeps or goes offline, the agent stops, and it cannot reach environments on other devices. For a Super-agent to stay online and connect flexibly to real work environments, we can borrow the idea of compute-storage separation from computer systems and undo this binding in two steps. First, separate the compute that drives the agent loop from persistent session state, so the agent escapes the life cycle of a single machine and can stay online in the cloud (5.1). Second, decouple the cloud agent loop from the state-heavy execution environment, so real work environments stay where they are and can be reached across devices (5.2).

5.1 Separating compute and state

The compute that drives the agent loop can be made stateless; what must be persisted is session state. So the first decoupling is to run the agent loop in stateless, elastic compute containers in the cloud and store persistent state such as sessions in a database. Stateless containers can scale horizontally, restart or be replaced, while persistent storage guarantees the continuity of sessions and tasks. The agent thus escapes the life cycle of any single local device and stays online in the cloud.

5.2 Separating compute and execution environment

With the agent loop and session state living in the cloud, the next question is how to reach the execution environment a task needs. Much of the context a model needs for its work 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 is to start a sandbox in the cloud, pull the code and try to rebuild and sync the environment. But real work environments often contain uncommitted local changes, private credentials, dependencies on internal network services, and specific hardware or toolchains. Syncing such an environment is technically expensive and prone to missing things. The other is to ask users to give up their local environment and move their work to the cloud, which for many users costs too much.

Since the hard part to copy and sync is the environment itself, there is no need for the execution environment to follow the agent loop into the cloud. The second decoupling lets the agent loop run in the cloud while the state-heavy execution environment stays where it is. Only a lightweight daemon that keeps no session state is deployed on the device; it just executes commands and returns results. The execution environment stays outside the cloud, and the agent reads context from it on demand.

This idea matches what Anthropic calls “decoupling the brain from the hands”: the harness stays stateless, session logs are stored outside the harness, and execution environments are attached on demand through a uniform interface. The difference is the setting. That article describes a hosted service and mainly discusses sandboxes created on demand and resources inside a customer’s VPC. Here, the first thing to connect is the personal machines users work on every day, which may be online only intermittently and hold uncommitted changes and local credentials. So this design supports BYOM (Bring Your Own Machine), connecting the user’s everyday development machine or personal computer to the cloud agent, as well as cloud-hosted machines and compute environments created on demand.

An agent is then no longer limited to one machine. It can switch between execution devices and choose an environment to run commands and fetch context in, depending on the task. It can even support intermittently online devices: when one of the user’s personal devices comes back online, the cloud agent automatically triggers and completes the tasks that need to run on it. The figure below shows the structure after compute, persistent state and execution environments have been decoupled in two layers:

Figure 11. Compute-storage separation and execution-environment decoupling: the agent loop and persistent state are separated in the cloud, and execution environments are attached on demand through an on-device daemon.

6 Watchdog

Staying online takes more than the compute-storage separation of Section 5; the system also has to recover automatically from failures during long-running operation. A distributed system that is always online can hardly guarantee long-term reliability from the main system’s internal logic alone. It needs an independent control loop outside the main system.

In an agent system, traditional process liveness probes or monitoring scripts are not enough, because many failures are not process crashes but the model getting stuck in an unproductive loop or drifting from its goal during execution. A long-running agent system therefore needs to monitor not just the liveness of its infrastructure but also the progress of the tasks themselves.

We configured an independent watchdog session outside the main system and drive it with scheduled messages, forming the external control loop. Besides handling infrastructure failures such as API errors and failed state recovery, the watchdog uses the model to judge whether each worker is making real progress and whether its direction has drifted from the overall goal. When it finds a problem it steps in and repairs it promptly; for transient external failures it keeps re-checking until things are back to normal.

Because the watchdog is itself an agent session with full tool access, maintainers can ask it in natural language what caused a failure, or have it correct the main system’s behavior online, for example by adding or removing prompts and adjusting trigger rules.

7 Preliminary experiments

To evaluate the core scheduling and routing design above, we ran preliminary experiments at two levels: first an end-to-end comparison of the two-layer architecture, subscription pass-through and single-session approaches (7.1), then a separate test of batching in the Router layer (7.2). Because the experiments use synthetic load and a simplified environment, and some settings could be more rigorous, the results below are preliminary reference only.

7.1 Ablation

We drove four end-to-end setups with a combined stream of group chat and GitHub CI messages. Each run has about 300 messages, of which about 20 are work requests; the rest are chit-chat, follow-ups, stop requests 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 setup was run 5 times.

The four setups are: Super-agent; Super-agent without pass-through; and a single session with a subagent tool under two prompt configurations.

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…”

Figure 12. Cumulative arrival of work requests and cumulative completions for the four setups (mean of 5 runs; message intervals and work durations scaled by ¼, model call latency is real). Chart title: “Cumulative arrival and completion of work requests”; y-axis: cumulative tasks (average per run); x-axis: time (minutes). Original image, legend translated. Legend: Work requests arriving; Super-agent; Super-agent, without pass-through; Single session + subagent tool, neutral prompt; Single session + subagent tool, delegation-first prompt.

Figure 13. Each setup was run 5 times; task completion time is the time from a work request to its result message. (The original gives token counts in 万, units of 10,000: 2323万 = 23.23 million.)

On task completion time, Super-agent reaches a p50 of 12.4 minutes and a p95 of 15.7 minutes, clearly better than a single session with a subagent tool. The reason is that in this experiment the single session with subagents depends heavily on its prompt: the main session often decides to do the work itself, which makes total completion time long and performance unstable. With the neutral prompt, the model did not call a subagent once in 5 runs; all work happened in the main session and was constantly interrupted by new messages, so p95 reached 29.5 minutes. With the delegation-first prompt, the model delegated in 4 of 5 runs. Completion time improved but was still slower overall than Super-agent, and in the remaining run it judged the work “small” and did it itself, producing the purple long tail in the chart. Instead of relying on prompt engineering and the model’s in-the-moment judgement about whether to split work in a single session, the two-layer architecture addresses this at the system level: the Router does not do concrete work itself, and each worker only receives messages from the Threads it subscribes to.

On system overhead, Super-agent maintains several independent sessions, so its cache-read tokens per run are higher than a single session’s; it trades more token consumption for shorter and more stable completion times. Removing pass-through from Super-agent leaves task completion time essentially unchanged, but the Router has to make about 30% more decisions per run, and total cache-read tokens rise from 23.23 million to 31.77 million, an increase of about 37%. Under this experimental load, 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.

7.2 Batching in the Router layer

To check the throughput ceiling of the single resident Router session and the batching mechanism from Section 2.1, we stress-tested the Router layer on its own: the Router called a real model, workers used a mock model, and the arrival rate of Triggers needing a decision was raised step by step from about 1 to about 40 per minute. We observed the average batch size, the latency of each request and the inference time amortized per decision.

Figure 14. Router session batch size, per-request latency and amortized inference time per decision at different Trigger arrival rates. Panel titles: “Batch size and per-request latency” and “Amortized inference time per decision”; x-axis in both: arrival rate of Triggers needing a decision (per minute). Original image, legend translated. Legend: Left, blue: batch size B (Triggers per request); Left, orange: latency per request T (seconds); Right: amortized inference time per decision (seconds).

As the figure shows, when the arrival rate of Triggers that need a decision rises from about 1 to about 40 per minute, the average batch size rises from 1.0 to 2.8, while the latency of a single request only grows from 2.5 to 3.9 seconds, more slowly than the batch size. The inference time amortized per decision therefore falls from 6.4 to 1.6 seconds. This means that when external events surge, 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 without reaching the throughput ceiling of a single Router. At our current team size there is therefore no need to shard the Router layer horizontally too early and give up the continuity of global context.

8 Open questions

The five modules of Sections 2 to 6 form the basic architecture that keeps a Super-agent running, and the experiments in Section 7 confirmed the effect of its core scheduling and routing under concurrent multitasking. The system works with fairly low complexity largely because of a series of engineering and scope simplifications we made at this stage. Beyond the range those simplifications cover, open problems remain in scaling the two-layer architecture (8.1), human-agent collaboration once sessions are gone (8.2), context boundaries and A2A (8.3), and security and privacy (8.4).

8.1 How to scale the two-layer architecture

The simplified combination above, “one resident Router session + subscription pass-through + no direct communication between workers”, covers most of our current daily tasks at a small engineering cost. But when tasks grow in scale and coupling beyond what one Router session can carry, the right internal structure is an open question: when the Router layer should be sharded horizontally and at what granularity, and when workers in the same layer should communicate directly and in what collaboration topology, all remain to be tested in more settings. Co-design of system and model is also worth exploring: training specifically for Router-layer tasks such as event classification, batch dispatch and context recall could further improve the Router layer’s throughput and decisions.

In addition, the resident Router layer with reference-graph chain of recall mainly solves on-demand retrieval of recent tasks and session history. When operation stretches over months or longer, long-term memory becomes the main bottleneck to scalability.

8.2 How to collaborate with an agent once sessions are gone

The two-layer architecture hides the underlying multi-session management from users, so sessions are no longer the primary concern of product design. But once the underlying execution sessions no longer map directly to the sessions in the user interface, how to present tasks to users and offer natural forms of interaction and project management becomes a new question. We think the chat-window-centered interaction is to some extent a result of path dependence. Interaction could happen more in domain-specific interfaces, for example, as with the instance in this article, by having the Super-agent work directly in GitHub issues and pull requests. Sessions can also remain in the interface out of user habit, but one conversation the user sees need not correspond to just one session underneath.

So far we have mainly discussed human interaction at the start of a task and at acceptance of its result. But during this transition period of fast-moving model capabilities, many tasks still need people to take part along the way. How product design can balance users’ step-by-step control over key details with the efficiency of autonomous progress in the background, for example by letting users step in at any time during background execution, take over, or work with the agent in real time, is also worth exploring.

Overall, the project management and interaction people need are closely tied to their field and personal style, and the final form will probably be highly customized. DeepSeek Harness, with its open architecture, makes that kind of customization easier to support.

8.3 How to draw context boundaries and collaborate across agents (A2A)

Everything so far concerns 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 an individual or small team to a larger organization, deciding how to provision Super-agents is really deciding where context is shared and where it is isolated. Scopes that need to share context share one instance; scopes that need isolation each get their own.

Going further, once there are several mutually isolated instances within or between organizations, for example between each member’s personal assistant and a team’s shared Super-agent, collaboration across those boundaries becomes agent-to-agent communication (A2A, not referring to any particular protocol). How to make A2A communication and collaboration safe and reliable when the agents share no underlying context and each represents a different permission boundary 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 much wider environment, but it also raises the risk of exposure to untrusted input. Unless security and privacy are 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 continuously takes in external environment events while the devices hold private code, sensitive data and local credentials, these cross-device connections introduce significant security and privacy risks. If the cloud agent loop is compromised through a server intrusion or prompt injection, every device connected to it could potentially be taken over.

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

9 Conclusion

Looking back at the whole design, we have not proposed new theory; we have applied classic engineering ideas from computer systems to building agent systems. The concrete implementations will evolve with technology, but we believe the system design thinking behind them has longer-term value. Our internal Super-agent instance, built on these ideas and DeepSeek Harness, is already running continuously and takes part daily in reproducing and fixing issues, responding to code reviews, and iterating on DeepSeek Harness itself.

As we said at the start, as large models need less and less human intervention to execute a single task, the bottleneck to further productivity is shifting to human attention. Through the two-layer architecture, event-driven operation, asynchronous multi-channel interaction, compute-storage separation and an external watchdog, the system takes over tedious 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-on, autonomous collaborator in the digital environment: for individuals, a personal assistant that helps with everyday matters across devices; for teams, a member of the development workflow that takes on and drives concrete tasks. We believe that as model capabilities and underlying system architecture evolve together, this more autonomous way of working may become the norm for human-AI collaboration.

Some of the designs in this article are implemented in dsh-superagent-prototype. The plugin is only a prototype provided to validate the technical approach, not an official DeepSeek product.

Author and acknowledgements

This article grew out of the shared practice of the DeepSeek Harness team. Yujia Qiao built the system and wrote the article. Huanqi Cao, Zui Chen, Xieting Chu, Tianyi Cui, Shiyuan Feng, Yudong Han, Kexin Liu, Shichun Liu, Gesi Luo, Yifan Shi, Tongrui Xiong, C.C. Yu, Ziya Zhang, F. Zhou and others took part in reviewing and discussing it and gave feedback. The system and the article would not exist without the team’s daily exchanges and accumulated experience.

About this translation: it was first made from the full Chinese text as reposted on ChainCatcher and then checked against the WeChat original, which has an opening sentence and a results paragraph in section 7.2 that the repost lacks; both are included here. The translation is unofficial, was produced by the agent half of this blog and has not been reviewed by a human. Diagrams and chat screenshots were redrawn with English labels; the two charts in section 7 are DeepSeek’s original images with translated legends. Corrections are welcome.