DeepSeek Super Agent's Two-Tier Architecture Explained: How Router and Worker Share the Coordination Burden

When AI can already write code, investigate issues, and submit changes, the real bottleneck is no longer single-task capability—it's how many things a person can keep track of at once. The core of the Super Agent design exploration published by the DeepSeek Harness team is precisely to take "coordination" off people's hands.

The problem isn't the model—it's human attention

According to a breakdown by Bilibili creator Nana, the team's observation is straightforward: a person can typically only follow three to five active sessions at once, and adding more windows means remembering more context and switching between more situations. The ceiling for a single task is set by model capability, but how far multiple tasks can progress increasingly depends on human attention.

Harness is defined as the runtime system built around a model, orchestrating messages, tools, context, and execution flow. How the same model receives work, waits for results, and responds to changes is all shaped by this system. DeepSeek^Ad already runs internal instances based on this approach, participating in issue reproduction, fixes, and code review responses.

A telling example happened in their own work group: a user reported that on macOS, clicks were being recognized as double-clicks when the window wasn't focused, causing chat history to zoom in. No one explicitly asked the Agent to handle it, but the internal instance had already started trying to reproduce it and subsequently submitted a code merge request with a fix. In another case, development of a feature progressed from an instant messaging group chat to a GitHub code review—the interaction channel changed, but the context didn't need to be explained again.

Two-tier architecture: the Router doesn't do the work itself

Cramming all messages into one big chat window causes problems: a session typically proceeds through a loop of thinking, calling tools, and reading results, so a long task blocks everything behind it, and intermediate details get mixed together. Conversely, opening a new session for every message achieves parallelism, but the relationships between tasks are lost.

DeepSeek's approach splits global coordination and concrete execution into two layers. The upper-layer Router is the unified coordination entry point: it receives information from different platforms, keeps track of cross-task relationships, dispatches work, and reports back to the person in a unified way. The lower-layer Workers handle the actual work, each with its own independent context, and can advance different tasks simultaneously.

The key design choice: the Router does not execute concrete work itself—it may not even be given tools to run commands. It needs to stay clear-headed and avoid diving headfirst into some complex problem and making the whole system wait for it to come out. The Workers, which actually determine code quality and task outcomes, are typically configured with more capable models. This differs from "a team lead with a few assistants"—a lead on a complex task needs to break down steps in depth, whereas the Router mainly manages high-level relationships between tasks; whether a piece of work needs further subdivision is handled by the Worker itself.

The Router/Worker layering is often called the "orchestrator-worker pattern" in engineering. Its difference from "single Agent + tool calls" isn't single-pass reasoning capability, but that the system can decouple "waiting" from "thinking": when a Worker is waiting for a tool to return, it doesn't block the Router from receiving new events, and when the Router dispatches, it doesn't need to load the full context of a task. The cost is more system state—each Worker has its own conversation history, subscription relationships, and execution environment. If a Worker gets stuck, an independent mechanism needs to detect it—which is the problem the watchdog discussed later solves.

Subscription mechanism and event streams: if you know who it's for, deliver it directly

The coordination entry point can also become a new bottleneck. If every follow-up message has to go through the Router for a decision before being forwarded to a Worker, the forwarding cost grows with the number of tasks.

This design introduces a subscription mechanism: the same code merge request, the same group chat topic, or the same email thread constitutes a continuous event stream. After the Router creates a Worker, it has it subscribe to the relevant event streams, and subsequent messages belonging to that matter are delivered directly to the corresponding Worker by the program, without re-dispatching each time. When cross-task coordination is needed, it goes back to the Router; the Worker's key conclusions are also aggregated to the Router for external replies.

Subscriptions also support many-to-many associations: one Worker can follow several related topics, and the same code merge request can be subscribed to by multiple Workers—receiving the same updates gives them a chance to notice each other's operations and handle conflicts. The engineering idea is simple—if you already know who it should go to, send it directly; only information that requires understanding new intent or judging a new task goes to the model.

The same principle applies at the message entry point: group chats, email, and code platforms continuously generate events, most of which don't require the Agent to act. The system first uses programs to filter out irrelevant messages based on explicit conditions such as source, group scope, and allowlists; candidate events that pass this layer are then handed to the model for semantic judgment. One policy configured internally at DeepSeek is called "silently reproduce and fix": when someone in a group reports an issue or discusses a change, the Agent first tries in the background and only delivers results once it confirms the problem and finds a simple fix; if no valuable result emerges, it stays quiet. This essentially trades extra background computation for people's waiting time.

An event stream here refers to a set of related messages continuously generated around the same entity, such as all comments under a PR or consecutive messages in a group chat topic. Its difference from a "message queue" is that a queue is typically consumed first-come-first-served, whereas an event stream emphasizes ownership—the system first needs to know which ongoing task a message belongs to, then decides the delivery target. A subscription essentially maintains an "entity—Worker" mapping table; if the mapping hits, it's delivered directly by the program; if not, it's escalated to the model to judge intent. This "rules first, model second" funnel structure is the most direct means of controlling inference costs.

Context caching and asynchronous execution

How much should an Agent that works continuously remember? Putting all history into context quickly fills the window; giving only message IDs forces the model to repeatedly query tools. DeepSeek borrows the idea of computer caching: information likely to be used soon goes into the current context, while longer and less-used content stays outside, with summaries and read entry points retained. These IDs can also be chained into reference relationships—from the current message to its topic, from the topic to the responsible Worker, and from that Worker to another code review it's associated with—so cross-platform context can be recovered step by step along the线索. (Tracing the thread.)

Classic synchronous tool calls make the execution loop wait until the tool finishes; if a background task is slow, the foreground conversation gets dragged down too. DeepSeek's asynchronous approach is to return a startup signal immediately after launching a command, letting the tool run in the background and sending the result back as a new event when it completes. When the user adds requirements or changes direction, new input can be processed after the current reasoning finishes, without waiting for all background commands to complete.

The asynchronous mechanism is already implemented in DeepSeek Harness but is not yet enabled by default. The output rules the team has validated are: single replies in group chats should not exceed 100 words, giving only brief conclusions and direct questions; for code merge requests, email, or documents, provide full background, changes, and verification results.

The key difference between asynchronous and synchronous tool calls lies in where control flow resides. In synchronous mode, after the model issues a tool call, the entire reasoning loop pauses until the result returns. In asynchronous mode, the model issues a "start" instruction, receives a handle, and can end the current round of reasoning; the result later re-enters context as a new event. This makes the foreground conversation's response latency independent of background command duration. But asynchrony brings new problems: by the time the result returns, the task goal may have changed, and the system needs to judge "whether this result still belongs to the current intent"—otherwise it's easy to mistake stale results for valid input.

Escaping the local lifecycle and an independent watchdog

Local Agents often put the run loop, session records, code, and tools on the same machine, so work stops when the computer sleeps. DeepSeek moves Agent computation to the cloud and stores session state in a database, while the actual execution environment stays on the user's machine. The reason for not copying the environment directly to the cloud is that the working site contains far more than a code repository—it may also have uncommitted changes, local credentials, intranet dependencies, and specific toolchains; rebuilding it is both costly and prone to omissions. Their approach is to deploy a lightweight program on the execution device that runs commands and returns results, with the cloud Agent stepping in as needed.

Long-running operation has another failure mode: the process is alive but the task isn't progressing. The model may repeatedly try the same ineffective approach, or gradually drift away from the goal—something a simple check of whether the service is online can't detect. To address this, the team set up an independent watchdog session outside the main system, driven by scheduled messages, which checks for faults such as interface errors and state recovery, and also uses a model to judge whether a Worker is making real progress or drifting off course, then steps in to fix it.

In system design, a watchdog refers to a monitoring component that runs independently of the main process, with the core assumption that "the monitored party may report itself as healthy, but the report itself is untrustworthy." There are two common approaches: heartbeat-based (the component periodically signals, and a timeout indicates an anomaly) and progress-based (checking whether task state has substantively advanced). DeepSeek's solution uses both—interface errors and state recovery are faults heartbeat can cover, while "repeatedly trying the same ineffective approach" and "gradually drifting off course" can only be judged semantically by a model assessing progress. Placing the watchdog outside the main system prevents the monitor from failing along with the main system if it freezes entirely.

Experimental results: median 12.4 minutes—the tail is what matters

The team ran a preliminary scheduling experiment: each input contained about 300 group chat and automated check messages, of which about 20 were work requests, with the rest being chatter, follow-ups, and stop requests; each scheme was run 5 times. Coding work was replaced by tools that only consume time, with message intervals and simulated work durations scaled proportionally, while model call latency kept real values.

Super Agent's median task completion time was 12.4 minutes, with a 95th percentile of 15.7 minutes. By comparison, the single-session approach, despite also having sub-Agent tools, never invoked them in 5 runs under a neutral prompt—work was executed by the main session and constantly interrupted by new messages, with a 95th percentile of 29.5 minutes; after changing the prompt to prioritize delegation, 4 of 5 runs delegated, showing improvement, while the remaining run had the model judge the work as small and still execute it itself, leaving a long waiting tail.

There are costs too: Super Agent maintains multiple independent sessions, so cached token consumption is higher than the single-session approach—trading more context processing overhead for shorter and more stable task completion times. The value of subscription direct delivery shows up elsewhere: removing direct delivery yields roughly the same completion time, but the Router makes about 30% more decisions, and total cached tokens rise from 23.23 million to 31.77 million, about 37% more—under this experimental load, eliminating intermediate forwarding mainly reduced inference overhead.

The team also separately tested batching at the coordination layer: when the Router receives multiple events during its previous round of reasoning, it can merge them into the next model call. In a stress test where Workers used simulated models and the Router used a real model, as the events requiring decisions rose from about one per minute to about 40, the average batch size grew from 1.0 to 2.8, and per-request latency grew from 2.5 seconds to 3.9 seconds—slower than batch size growth, making merged processing worthwhile.

These results come from synthetic messages and a simplified environment; they support the scheduling design's effectiveness under that load, but the difficulty of real tasks, coupling between work items, and performance in larger teams still need to be tested.

Permissions and memory: open questions not yet resolved

The cloud Agent continuously reads external messages, while local devices hold private code, sensitive data, and credentials. If the cloud is compromised or broken via prompt injection, connected edge devices could be controlled; even under normal operation, credentials entering the model context could create leakage risks. The team proposes that the Agent should be able to use credentials without touching them directly, and larger organizations need to draw clear context boundaries—who shares an instance, what information must be isolated, and how multiple isolated instances collaborate—all remain open questions.

Long-range memory is likewise still being explored: using relationships to recover recent tasks and to save and understand work history across spans are problems at different scales; how users can step in and take over at any time during background execution also needs more mature product design.

What makes this exploration noteworthy is that it breaks autonomous collaboration down into concrete system responsibilities: how work is dispatched, how information is delivered, how results are handed off, and who detects anomalies—each directly affects how much coordination cost people bear. If users still have to constantly switch windows, restate context, and chase progress, even the strongest single-task capability will be offset by management burden. Taking these burdens over gives people more room to decide goals, handle key disagreements, and judge whether results are acceptable.