DeepSeek Harness unveils Super-agent architecture, using five major modules to take over session scheduling

Smart Things reported on November 1 that on the evening of October 31, the DeepSeek Harness team unveiled the underlying architecture of its autonomous Agent exploration project—Super-agent (super intelligent agent).

▲Super-agent open-source project address

GitHub address:

The "Super-agent" that DeepSeek wants to build can be colloquially understood as an Agent that is always online, can do multiple things at once, actively seeks out work, and can recover on its own when problems arise. The result the team launched this time is not a new product, but rather closer to a new way of thinking—bringing classic ideas from computer systems such as scheduling, caching, compute-storage separation, and Watchdog into the Agent architecture.

As models reduce manual intervention in single-task execution, the bottleneck shifts to human attention. DeepSeek Harness attempts to take over session management and context synchronization at the underlying level through five major modules—dual-layer architecture, event-driven design, asynchronous multi-channel interaction, compute-storage separation, and an external Watchdog—moving humans up to decision-making and acceptance, and improving the Agent application experience.

▲Overall system architecture of Super-agent

In experiments, half of the Super-agent tasks based on this approach were completed within 12.4 minutes, and 95% of tasks were completed within 15.7 minutes, significantly better than a single Session with Subagent tools; after removing subscription passthrough, the number of Router decisions increased by about 30%, and read-cache tokens rose from 23.23 million to 31.77 million; Router batching reduced the inference time allocated per decision from 6.4 seconds to 1.6 seconds.

This set of data means that Super-agent has preliminarily demonstrated in experiments the feasibility of "system-layer takeover of session scheduling."

On the one hand, multi-task completion is faster and more stable, with the Router saving overhead through passthrough and handling bursts through batching; but on the other hand, it trades more tokens for time and stability, and the experiments are based on synthetic loads and a simplified environment, serving only as a preliminary reference, not a formal product conclusion.

1. Super-agent: No need to switch sessions; one Agent advances multiple tasks in parallel

Over the past year, single-task Agents such as Coding Agent have proven that models can use tools to solve complex problems, with humans intervening less and less in low-level execution and their role moving up to decision-making and acceptance. New forms such as personal assistants that are continuously online and event-driven have begun to emerge.

However, existing Agents use a single Session as the unit, and the upper limit of multi-tasking is constrained by human attention; simple scaling is still limited by synchronous blocking, context confusion, and stopping when the device goes offline.

Therefore, the DeepSeek Harness team proposes Super-agent: a continuous entity that maintains context across sessions, advances multiple tasks in parallel without interfering with one another, and already has internal instances continuously advancing tasks between IM and GitHub.

▲The same task continuously advances between an IM group chat and a GitHub Pull Request review

▲Continuously monitors public group chats, proactively identifies defects without being @-mentioned, and submits fix Pull Requests

The team believes that Super-agent has four basic characteristics:

– Continuous: Users can interact with it directly in familiar interfaces such as IM chats and GitHub comments, feeling that there is always only one Agent, without needing to think about "whether Session X's context contains information Y." For example, if a user first proposes adopting Plan A in IM and later changes to Plan B in a GitHub PR comment, it can understand and adjust the execution direction.

– Efficient: It responds quickly to interactions while completing multiple complex tasks in parallel and with high quality. It can accept the next instruction without waiting for the previous command or task to complete.

– Proactive: Without waiting for users to issue instructions one by one, it can continuously observe environmental events and proactively advance matters worth handling, while staying quiet when no intervention is needed.

– Persistent: Always online, directly connected to the user's real work environment, and automatically recovering from exceptions during long-term operation.

A single ReAct Loop cannot simultaneously support the above four characteristics; a corresponding architecture is needed at the underlying level. The article argues that similar design constraints will lead to similar architectural choices. Whether for personal assistants or Agents in commercial scenarios such as software development, if the goal is to build a system that is continuously online and concurrently responsive to environmental events, the underlying architecture may be similar. Many of the problems faced in this process are highly similar to those long discussed in traditional computer systems, so classic design ideas from computer systems also apply.

Specific implementations will have different variants, but the article argues that five modules form the basic framework supporting the above four characteristics: a dual-layer architecture balances continuous interaction and efficient concurrency, event-driven design enables proactive response, human-oriented interaction achieves both continuity and efficiency during interaction, and separation of computation, state, and environment plus Watchdog enables persistent online operation across devices and automatic exception recovery.

2. Dual-layer architecture: Continuity and throughput need not be either-or; one layer dispatches, the other does the work

There is a fundamental trade-off between continuous cross-channel interaction and efficient multi-task concurrency: handing everything to one Session gives the most continuous context, but a single ReAct Loop is serial, has low throughput, and mixes details; opening fully independent Sessions gives the highest throughput, but lacks global context, fragments results, and confuses interaction.

The DeepSeek Harness team's solution is to split "maintaining global continuity" and "high-concurrency execution" into two layers: a persistent Router layer handles human interaction and global coordination, while context-isolated Worker layers execute specific tasks concurrently. Sessions should become a system implementation detail rather than a user cognitive burden.

▲Dual-layer architecture: The Router layer is uniformly responsible for routing and external interaction, while multiple Worker Sessions execute tasks concurrently in isolation

1. Router layer: only dispatches, does not do the work, and amortizes costs through batching

The Router layer is a persistent global routing layer responsible for handling human interaction at all entry points. All cross-task information and decisions are aggregated at the Router layer, which serves as the global sequence point, coordination point, and memory. To prevent this global node from becoming a performance bottleneck, the Router layer is designed not to execute specific tasks directly; it is only responsible for human interaction and task dispatch, and may not even be equipped with Bash tools.

This structure, in which one central node dispatches multiple execution nodes, superficially resembles a common Agent Team, but the emphasis differs. A common Agent Team is mainly used for step decomposition and role collaboration within a single complex task; sub-steps are usually tightly coupled, and the Team Lead often needs to deeply understand task details, plan subtasks, and coordinate members at high frequency, bearing a heavy inference load itself. In a Super-agent, by contrast, the Router layer only handles high-level associations and dispatch between tasks and does not need to intervene in the internal decomposition of a single task. Conversely, if prompts are used to constrain an Agent Team's main session not to execute specific tasks itself but only to handle external interaction and dispatch different tasks to members to advance independently, that can also be regarded as this dual-layer architecture. Team practice shows that Router-layer tasks are often less complex than imagined, and a lighter-weight model can often balance speed and effectiveness.

Internally, the Router layer likewise need not be limited to a single Session, and some logic may not even require calling an LLM. The team chose the most direct implementation—a single persistent LLM Session as the core of the Router layer—and found that it is not as prone to becoming a throughput bottleneck as it superficially appears, because environment events arriving during the previous round of inference accumulate and are processed together in the next round, forming batches, and the extra overhead of merged processing is very small:

– When the external event stream is steady, Triggers enter the Router Session one by one, and single-response latency is low;

– When events flood in and the Router Session becomes queued and congested, multiple Triggers accumulated during the previous round of inference are automatically merged and injected together in the next LLM call. The Router Session only performs lightweight interaction and dispatch, and each step is usually long-input, short-output. Merging multiple accumulated Triggers into one LLM API call computes them in parallel during the Prefill stage, and the latency growth of a single request is far slower than the batch size. Therefore, within a certain range, the more backlog there is, the lower the inference time amortized per decision; the upper limit depends on the context length and how many Triggers the model can accurately process in one round.

Later in the article, experiments quantitatively demonstrate the effect of the batching mechanism. Combined with the subscription and pass-through mechanisms and chained recall, a single persistent Router Session is already sufficient at the current team scale while maintaining context continuity.

When the scale expands further and a single session is truly insufficient, the Router layer can also be designed internally as a multi-level filtering structure or horizontally split into multiple sessions. In that case, the internal design of the Router layer is essentially a trade-off between continuity and throughput. The finer the split granularity, the higher the Router layer's concurrent throughput, but the lower the memory and context continuity between shards. Before the global memory problem is solved, this trade-off always exists.

The Worker layer consists of sessions responsible for concrete execution. Each Worker is context-isolated from the others, mounts the full execution toolset, and focuses on completing a single task in an independent context. Because Worker Sessions directly determine task results and code quality, they usually need to be configured with the most capable model.

Workers do not interact directly with humans; their reasoning processes and tool calls are not output directly to external channels. Instead, they report status to the Router layer, which replies to the user uniformly, thereby ensuring concurrency and delivery quality while avoiding the confusion caused by multiple sessions each replying on their own.

When multiple tasks execute concurrently, each Worker advances its task independently, and Workers at the same layer usually do not need to communicate directly. Conflicts among multiple Workers in concrete execution often arise in shared working environments such as the same Pull Request; as long as they all subscribe to the corresponding Thread, they will receive the same event notifications and thus have the opportunity to discover and resolve conflicts themselves, while the few cross-task collaborations are relayed by the Router layer.

Similar to the Router layer, each Worker Session does not have to be limited to a single session internally: when executing a complex single task, a Worker can internally create Subagents, or can itself be an Agent Team, and these remain transparent to the upper Router layer. This structure applies both to code collaboration scenarios, advancing multiple independent issue reproductions, PR reviews, and feature development in parallel without blocking one another; and to personal assistant scenarios: although the personal assistant interface usually provides only a single-session chat page, when the user discusses multiple different topics simultaneously in the same dialog box, the single front-end chat page is responsible for maintaining interaction continuity, while underneath a separate Worker can be dispatched for each topic to advance tasks and draft replies in parallel.

III. Event-driven: no waiting for instructions; environmental events as input; four steps that let the Agent take initiative

To make the Super-agent proactive, the first step is to change how the system is driven. The main input driving the Agent is no longer the prompts that a human types one by one in a Session, but semi-structured events in the environment. In the Super-agent, environmental events such as group chat messages, email and calendar reminders, code review comments, and CI run results are called Triggers. By listening to and responding to Triggers, the Agent no longer has to wait passively for a human to issue an instruction before executing once, as in single-Session mode.

Around the lifecycle of an environmental event from entry to processing, the article discusses four progressive questions in turn: how to filter out a large amount of noise through a two-level strategy combining programs and models; how to route events to Workers through subscription and direct-pass mechanisms; how to use Inline & Spill and chained recall to inject context into the model at high density and recall it on demand; and how to use speculative execution to act ahead of time in the background based on environmental signals.

1. Event filtering: programs screen fast first, then models judge slowly

After connecting to real group chats and code platforms, the environmental event stream shows a marked "high noise, low trigger rate" characteristic, and the vast majority of daily messages do not require Agent intervention. If a large model were called to judge every event from scratch, both latency and compute cost would be unbearable. Drawing on the Fast Path / Slow Path idea from computer systems, large-model inference can be seen as a flexible but costly Slow Path, while solidifying already clear and stable high-frequency judgments into deterministic code constitutes a low-latency, low-cost Fast Path.

Therefore, the first step after an event enters the system is filtering, with the goal of using deterministic strategies to screen out noise before calling a large model, and handing only candidate events that require semantic understanding to the model for judgment. The team adopts a two-level filtering mechanism combining program strategies with large models:

– Program-layer strategies, as the Fast Path: for deterministic conditions such as event source, group scope, and user or bot whitelists, fast admission checks are performed directly through code, for example setting "respond only to explicit requests," "treat as candidate event," or "ignore directly" for different sources, filtering out most irrelevant messages before calling the model.

– Semantic-layer strategies, as the Slow Path: candidate events that pass program-layer admission are handed to the LLM, which judges whether action is needed based on strategies written in prompts and on context. The semantic layer also serves as a natural-language extension point for humans, making it convenient to toggle or add strategies via prompts at any time.

▲Two-level filtering: program-layer strategies first screen out most irrelevant messages, then semantic-layer strategies make the judgment

The global Router layer introduced in Section 2 is responsible for maintaining cross-channel continuity, but if every subsequent event of an already-assigned task still needs to be forwarded through the Router layer, this global node will still bear a large load, pushing up system response latency. Therefore, Fast / Slow Path also applies to event routing after filtering. The global Router layer is responsible only for cold-starting new tasks and for cross-task coordination, while subsequent events whose ownership has already been determined are sent directly by programs to the corresponding Worker session without being forwarded through the Router layer.

In actual workflows, consecutive events under the same GitHub PR, the same IM topic, or the same email thread form an event stream, i.e., a Thread.

– Subscribed, Fast Path: subsequent events under the same Thread are passed directly by programs to the subscribed Worker, without the Router layer needing to call tools again for forwarding. If a new event exceeds the scope of the current task, the Worker can also unsubscribe or hand it back to the Router layer for reassignment.

– Not subscribed, Slow Path: the Router layer can still observe all events to grasp global state, but is responsible only for judging and dispatching new events that have not yet been subscribed.

▲Subscription and direct pass: the initial event creates a Worker via the Router layer and establishes a subscription, and subsequent events in the same Thread are sent directly to that Worker

In addition, the subscription relationship between Threads and Workers is many-to-many. A single Worker can subscribe to multiple related Threads at the same time, and the same Thread can also be subscribed to by multiple Workers. When multiple Workers intersect in the same work environment or discussion, new events under that Thread are simultaneously passed directly to all Workers subscribed to it, so that they can learn about each other's operations and resolve conflicts on their own without peer-to-peer communication. On the output side, Workers still report key conclusions to the Router layer, which uniformly replies to the user and synchronizes global memory.

3. Context organization: commonly used content placed directly, long texts summarized first, old tasks found by ID

After events are filtered and routed and enter the target Session, the next question is how much information should be injected into the model's context window. Because system input shifts from limited human prompts to semi-structured events continuously generated by the environment, the structural design of tool calls and event injection becomes more important. Injecting too much crowds the window and dilutes the model's attention, while injecting too little forces the model to repeatedly call tools to read, increasing the number of execution steps. The article states plainly: wasting the context window is wasting the model's intelligence.

To this end, the limited context window can be managed as a Cache. Borrowing concepts from compiler optimization and computer systems, context injection design can be summarized into two basic operations. Inline means directly inlining information that is very likely to be used soon into the current context window, to save extra tool-call round trips. Spill means leaving complete information that exceeds the window budget or is used infrequently outside the context window, retaining only references or summaries within the window for the model to read on demand.

Combining the classic locality idea in computer system design, Inline & Spill can be used to progressively optimize event injection and tool calls:

– Start with minimal information: initially provide only the current object ID and a content summary.

– Use locality to progressively Inline related information: Inline information that is very likely to be used soon into the context, first attaching closely related object IDs, then attaching spatiotemporally adjacent content, such as the first 50 characters of content, the messages adjacent to an IM message and the message it replies to, or adjacent comments in the review discussion where a code comment resides.

– Spill when exceeding the limit: set a relatively small length limit for long content that cannot be fully Inlined, and Spill the excess outside the window. A simple and direct approach is to truncate the excess and retain an entry point for continued reading, so that the model can call tools to read when it needs the complete content.

In addition, after a large number of subsequent events are passed directly to Workers and the system has accumulated many historical tasks over long-term operation, the Router layer can neither put the full history of all tasks into its own context window nor fail to retrieve context when a user brings up an old task across channels. Applying Inline & Spill consistently to various objects in the system yields an on-demand expanding multi-hop retrieval mechanism, namely chain recall. This chain recall alleviates the problem of the Router layer losing prior information over long ranges.

▲Chain recall: each recalled object inlines the ID of the next-hop related object, supporting hop-by-hop context expansion along reference relationships

Specifically, the system assigns unique IDs to objects such as Triggers, Threads, and Worker Sessions, and inlines closely related object IDs during injection, so that these objects form a reference graph at the underlying level. Because objects recalled by each tool call also follow Inline & Spill, their returned results in turn inline the summaries and IDs of next-hop related objects, so the model can start from the current event and progressively recall context on demand along reference relationships. For example, it reads the Thread containing a current message, then traces from the Thread's inlined ID to the related Worker Session, and further finds another code review Thread associated with that Worker.

4. Act in advance: try in the background first, deliver only when valuable

Drawing on the idea of speculative execution in computer systems, an Agent can, when it is not yet certain whether a result will be adopted, try in advance in the background based on environmental signals, reducing human waiting and intervention costs by consuming extra background compute. If the result is valuable, deliver it; if not, discard it.

In personal assistant scenarios, when receiving a meeting invitation email or a to-do message, the Agent can first check schedule conflicts, gather relevant background materials, and prepare a reply draft in the background, and then directly confirm and send after the user reviews it. The same applies in R&D collaboration scenarios. For example, the team configured a "silently reproduce and fix" policy in the DeepSeek Harness internal user group: when someone in the group reports a problem or discusses a change proposal, the Agent first tries to reproduce it and find a fix in the background, and only after confirming the problem and finding a simple fix does it deliver the result to the user; otherwise it stays silent throughout.

▲Speculative execution example: while the group is still discussing a solution, the Super-agent has already submitted a fix Pull Request in the background

IV. Human-oriented interaction: full-duplex, ready to accept new instructions at any time; multi-channel, speaking according to people's habits

The two-layer architecture ensures cross-channel context continuity, but the actual interaction experience still needs to solve two points: use an asynchronous ReAct Loop so that time-consuming background operations do not block the foreground, and the session can accept new instructions at any time; and make the output mode match the bandwidth of different channels and people's usage habits.

1. Full-duplex interaction: the background does the work, the foreground is not blocked, and new instructions can come in at any time

In the classic ReAct Loop, after the model initiates a synchronous run() tool call, the loop blocks until the tool finishes executing and returns the final result; during this period, the session cannot respond to any new user input. To eliminate this blocking, the conversation needs to shift from the half-duplex question-and-answer mode to a full-duplex mode.

▲Comparison of the classic ReAct Loop and the asynchronous ReAct Loop

To this end, the team changed time-consuming commands and subtask tool calls into asynchronous start() and stop(), forming an asynchronous ReAct Loop. After the model calls start(), it immediately receives a "started" response, and the loop no longer waits for that tool; after the background tool finishes executing, the system delivers the final result into the session as a new event message; at the same time, the model can also call stop() based on context to proactively terminate background commands that have been executing for too long.

As a result, foreground conversation responses and background task execution are decoupled, and the Agent can respond to human input while running time-consuming tasks in the background. New input is processed as soon as the current reasoning step ends, without waiting for background tools to complete. The article reveals that this asynchronous task mechanism has been implemented in DeepSeek Harness, but is not yet enabled by default.

2. Multi-channel interaction: low-disturbance short replies in group chats, high-density complete writing in PR emails

Different work channels have different information densities and interaction habits, and system output needs to match them. If the interaction style designed for a single-person terminal is directly moved into a group chat, outputting lengthy reasoning processes and dense tool calls as-is, it is very easy to cause information overload in multi-person collaboration.

In Super-agent, the two-layer architecture has already solved part of this problem: in specific tasks, lengthy reasoning processes and dense tool calls are isolated inside the Worker Session and are not directly output to external channels, while the Router layer is uniformly responsible for external interaction. On this basis, the system also needs to connect to the various work environments users use daily, and customize interaction specifications for different channels through prompts:

– Instant messaging channels such as IM: focus on low-disturbance lightweight communication, like a human colleague, sending notifications only when a decision or acceptance is needed, asking only direct questions and giving brief conclusions. The team has verified a simple and effective hard rule: a single reply must not exceed 100 words.

– Asynchronous channels such as GitHub, email, and documents: focus on structured, high-information-density asynchronous delivery, for example, when creating or updating a Pull Request, writing the complete problem background, change description, and verification results according to project conventions, or in personal assistant scenarios, directly drafting structured emails and document summaries.

V. Anthropic-style "separation of brain and hands": decoupling computation, state, and environment

Existing local Agents by default bind the computation that advances the Agent Loop, the session state that needs to be persistently stored, and the execution environment such as code repositories and local toolchains to the same device. Once the device sleeps or goes offline, the Agent stops running and cannot access environments on other devices.

To make Super-agent persistently online and flexibly connect to various real work environments, it can borrow the idea of separating storage and computation from computer systems, decoupling the binding of the three in two steps: the first step is to separate the computation that advances the Agent Loop from the persistent session state, freeing the Agent from the lifecycle constraints of a single machine and achieving persistent cloud-based online operation; the second step is to decouple the cloud Agent Loop from the heavy-state execution environment, leaving the real work environment in place and supporting cross-device access.

The article points out that this approach is consistent with the "separation of brain and hands" proposed by Anthropic, which likewise keeps the harness stateless, stores session logs outside the harness, and connects to execution environments on demand through a unified interface.

But the difference between the two lies in the scenario: the Anthropic article describes a hosted service, mainly discussing on-demand sandboxes and resources within the customer's VPC; what needs to be connected here first are the personal machines users use daily and that may be intermittently online, which have uncommitted changes and local credentials. Therefore, this design supports both BYOM, that is, connecting the development machine or personal computer users use daily to the cloud Agent, and connecting to cloud-hosted machines or on-demand compute environments.

As a result, an Agent is no longer limited to a single machine, but can switch between different execution devices, choosing an environment according to task needs to execute commands and obtain context from the environment. It can even support intermittently online devices, for example, after one of the user's personal devices comes back online, the cloud Agent automatically triggers and completes the tasks that need to be executed on that device.

▲Separation of storage and computation and decoupling of the execution environment

VI. Persistent online operation relies on an external Watchdog: monitoring both infrastructure and task progress

To achieve persistent online operation, in addition to the separation of storage and computation in Section 5, the system also needs to be able to automatically recover from anomalies during long-term operation. It is difficult for a persistently online distributed system to guarantee long-term reliable operation solely through the internal logic of the main system; an independent external control loop, namely the Control Loop, needs to be introduced outside the main system.

At the same time, in an Agent system, traditional process liveness probes or monitoring scripts alone are not enough, because many anomalies are not process crashes but the model falling into an ineffective loop or deviating from the goal during execution. Therefore, a long-running Agent system needs to monitor not only the liveness of the infrastructure but also the progress of the task itself.

The team configured an independent Watchdog Session outside the main system, driving it with scheduled messages to form an external Control Loop. In addition to handling infrastructure failures such as interface errors and state recovery failures, the Watchdog also has the model judge whether each Worker is making substantive progress and whether its direction deviates from the overall goal. When an anomaly is found, it intervenes promptly to repair it; when an occasional external failure occurs, it keeps rechecking until normal operation is restored.

Since the Watchdog itself is also an Agent Session with full tool capabilities, maintainers can ask it in natural language about the cause of a failure, and can also have it correct the main system's behavior online, for example by adding or removing prompts or adjusting trigger rules.

VII. Preliminary experiments: the two-layer architecture is faster and more stable, direct pass-through saves 30% of tokens, and the more congested the Router, the cheaper each decision

To evaluate the core scheduling and routing design described above, the team conducted preliminary experiments at two levels: first, end-to-end experiments comparing the two-layer architecture, subscription direct pass-through, and the single-Session scheme; then, separate tests of batching at the Router layer. Because the experiments are based on synthetic load and a simplified environment, some settings could be made more rigorous, and the following results are for preliminary reference only.

1. Ablation experiments: faster and more stable; direct pass-through does not speed things up but saves the Router about 37% of tokens

The experiment used group chat and GitHub CI message streams to drive four schemes, with about 300 messages per run, of which about 20 were work requests; coding work was replaced by time-consuming tools only, and each scheme was run 5 times.

▲Cumulative arrival curve of work requests and cumulative completion curves of the four schemes

▲Each scheme was run 5 times; task completion time refers to the time from a work request to the result message

Super-agent's p50 and p95 were 12.4 minutes and 15.7 minutes, respectively, significantly better than the single Session with a Subagent tool. The latter is heavily affected by prompts: under a neutral prompt, none of the 5 runs called the Subagent, and everything was done in the main Session, constantly interrupted by new messages, with p95 reaching 29.5 minutes; after changing to prioritize delegation, 4 of the 5 runs delegated, still slower than Super-agent, and in the remaining run the model judged the work to be "very small" and executed it itself, forming a long tail.

In terms of overhead, Super-agent maintains multiple sessions, so its cache-read tokens are higher than those of the single Session, trading more tokens for shorter and more stable completion times. Removing direct pass-through left completion times basically unchanged, but the number of Router decisions increased by about 30%, and cache-read tokens rose from 23.23 million to 31.77 million, an increase of about 37%; direct pass-through does not improve speed, but it saves the Router considerable tokens and inference overhead.

2. Batching at the Router layer: after merging backlogs, the amortized time per decision dropped from 6.4 seconds to 1.6 seconds

The team separately stress-tested the Router layer: the Router called the real model, Workers used Mock models, and the Trigger arrival rate rose from about 1 per minute to about 40 per minute.

As a result, the average batch rose from 1.0 to 2.8, the time per request increased only from 2.5 seconds to 3.9 seconds, growing more slowly than the batch size, and the inference time amortized per decision dropped from 6.4 seconds to 1.6 seconds.

This shows that during sudden congestion the Router can automatically merge backlogged events to improve throughput, and it also explains why the increased peak load after removing direct pass-through still did not hit the bottleneck. Therefore, at the team's current scale, there is no need to prematurely split horizontally and sacrifice the continuity of global context.

▲Batch size, time per request, and amortized inference time per decision of the Router Session under different Trigger arrival rates

VIII. Four hurdles remain: architecture scaling, human-machine collaboration, A2A, and security and privacy

The five modules introduced in Sections 2 to 6 constitute the basic architecture supporting the operation of Super-agent, and the experiments in Section 7 also verified the effectiveness of its core scheduling and routing mechanisms under multi-task concurrency.

The reason this system can operate with relatively low complexity is largely that at the current stage a series of engineering and scenario simplifications have been made. Beyond the applicable scope of these simplifications, there are still some problems to be solved in scaling the two-layer architecture, human-machine collaboration outside Sessions, context boundaries and A2A, and security and privacy.

The article lists four open questions: first, how to scale the two-layer architecture; there is no consensus on when to split after a single Router exceeds its capacity, what granularity to use, or when Workers should communicate directly with each other, and cross-month long-range memory is also a bottleneck; second, how to collaborate outside Sessions; the chat window may not be the final form, and interaction may increasingly occur in domain interfaces such as GitHub, and support is also needed for users to intervene midway, take over, and collaborate in real time.

Third, how to divide context boundaries as the organization grows; A2A communication and collaboration among multiple isolated instances remain to be explored; fourth, security and privacy; when a cloud Agent connects to on-device credentials, there are risks of intrusion and prompt injection, and the Agent also needs to be able to use credentials without touching the credentials themselves.

Conclusion: five modules to free the human attention bottleneck in the Agent era

The article does not propose an entirely new theory, but applies classic engineering ideas from computer systems to the construction of Agent systems; the specific implementation will evolve, but the design approach has long-term reference value. The internal Super-agent instance based on DeepSeek Harness has been running continuously, participating in problem reproduction and repair, code review, and Harness iteration.

As models reduce manual intervention in executing a single task, the bottleneck shifts to human attention. The two-layer architecture, event-driven design, asynchronous multi-channel interaction, separation of storage and computation, and the external Watchdog take over session management and context synchronization at the lower level, moving humans up to decision-making and acceptance.

Agents change from passive chat windows into continuously online autonomous collaborators: for individuals, a cross-device assistant; for teams, integrated into R&D workflows. The team believes that a more autonomous way of working is expected to become the norm. Some designs have been implemented in dsh-superagent-prototype, but this plugin is only a prototype for validating the technical route and is not an official DeepSeek product.