DeepSeek Super-agent: Router-Worker Architecture for Persistent Cross-Channel Agent Tasks

Introduction

DeepSeek's product department recently published a design exploration titled "Super-agent Design Exploration: Towards More Autonomous Agent Systems" and released a research prototype called dsh-superagent-prototype. The prototype is explicitly noted as a research artifact that does not fully match the internal version or the design document; some directions described in the article remain unimplemented.

The core problem: agents can now handle multiple requirements simultaneously, but humans are busier than ever coordinating across channels. A test runs in one window, a review waits in another, a CI failure arrives via GitHub, and a colleague adds a requirement in a group chat. Code gets written, but messages still need human relaying and progress still needs human checking.

DeepSeek's approach keeps cross-channel interaction and coordination in a Router layer, delegates concrete tasks to multiple Workers for parallel execution, and uses events plus persistent records so that paused work can continue. The central architectural tension: context must stay coherent, execution must be separated, and the link between them must survive interruptions.

The Cross-Channel Context Problem

Consider a bug report: "New version exported files won't open." An agent reproduces, fixes, and submits a PR. A reviewer requests a compatibility test; CI then fails. Later, the original reporter adds in the group chat that only the old client is affected. Humans know this is one continuous issue, but the system sees separate inputs: group chat messages, review comments, CI results. If each channel has its own chat session, a human must find the original window and re-explain the connection.

Putting everything in one session keeps context together but mixes fixing, reviewing, and other requirements in a single execution loop, causing mutual interruption. Creating a new session per message enables parallelism, but the newly added constraint (old client only) may not reach the session that is currently modifying code.

Router-Worker Dual-Layer Design

Super-agent resolves this with two responsibility layers:

Router layer : maintains cross-channel context, decides whether a new message needs handling and by whom, and unifies external communication.

Worker layer : executes concrete tasks in isolated sessions, reads code, runs tools, and reports progress and results back to the Router.

How to write the compatibility test is left to the Worker; complex fixes can further use sub-agents or Agent Teams. The two layers describe responsibilities; each layer can have its own internal division. Multiple Workers' contexts are isolated, but shared files, branches, and write ordering still need coordination — a problem previously discussed in the sub-agent article.

Both Router and Worker are DeepSeek Harness (DSH) sessions, differing only in prompts, tools, and responsibilities. Session creation, restoration, and input delivery continue to use DSH interfaces. DSH already supports session persistence and sub-agent restoration; the experimental Agent Teams add persistent members, shared task boards, and the ability to wake unloaded members via messages. Merely having "multiple agents" or "ability to resume" does not reveal what is new here.

For this bug fix, DSH ensures execution can resume; Super-agent records which execution belongs to which work item and which discussions it relates to. When a reviewer says "add a test" in the PR, the system locates the original fix task and routes it to the execution session — the reviewer does not need to find the agent's chat window.

In the earlier "Four Multi-Agent Architectures Explained" Supervisor article, the focus was on decomposing a task, dispatching, and collecting results. Here an additional question arises: when multiple works advance concurrently, how do subsequent messages find their original assignees?

Message Routing: Triggers, Threads, and Subscriptions

If every CI notification and review comment forced the Router to re-understand and re-dispatch, the coordination session would become a bottleneck. The design document defines a single environmental event as a Trigger , and a sequence of events under the same topic or PR as a Thread .

Most messages from chat platforms and code platforms do not require agent action. Source, group, user, or bot allow-lists can be checked programmatically; only candidate events needing semantic understanding are sent to the model.

On first encountering a new work item, the Router judges and dispatches. The Worker then subscribes to the relevant Thread; subsequent messages in that event stream are delivered directly by code, without asking the model to re-decide ownership each time.

Group chat additions and PR reviews can return to the same fix. Dashed lines indicate programmatic read/write of persistent state.

Returning to the export defect: the fix task can simultaneously watch the group chat topic and its own PR. Review comments arrive via PR subscription; the old-client constraint arrives via group chat subscription — both route back to the same fix. A single discussion may relate to several works; subscriptions are not limited to one-to-one. Before waking an executor, the prototype also checks whether the follow-up is from a human or bot and whether the task has already ended.

The Router can still read events and task records to understand the global situation, but it no longer forwards every round-trip. Model-judged relationships become programmatic delivery bases that persist.

Batch Processing for Router Scalability

When ten new questions appear simultaneously in the group, existing subscriptions cannot handle all routing. For messages that still need ownership judgment, the design uses batching: events backlogged during the Router's previous reasoning round are merged into the next round for joint processing.

When messages are sparse, handle one by one; when they arrive in bursts, one reasoning pass can make multiple dispatch decisions. Whether this pays off depends on how much extra latency merging adds. The Router mainly reads context and outputs short decisions; input prefill has parallel computation headroom, so reading a few more events does not necessarily increase latency proportionally.

The team tested this separately: Router called a real model, Workers used a simulated model. When events requiring decisions rose from ~1 per minute to ~40 per minute, average batch size grew from 1.0 to 2.8, and single model request latency increased from 2.5s to 3.9s. In this Router load test, merged processing did amortize some inference overhead.

However, cheaper per-request does not mean faster per-message; a message may still queue waiting for the previous round to finish. Context window capacity and how many events a model can accurately process in one round also limit batch size.

Scaling further involves horizontal Router sharding. Multiple Routers increase concurrency, but sharding strategy affects what each Router knows. If split by channel, the group chat compatibility requirement and PR review might land on different Routers, requiring task correlation and condition synchronization. Keeping inputs for the same task together reduces such round-trips; cross-task shared information still needs coordination.

A single Router makes it easier to understand before-and-after events together; multiple Routers add context synchronization cost. Filtering, subscriptions, and batching let a single Router handle this load; how to shard at larger scale and maintain shared memory remains open in the original document.

Ticket Persistence: Execution Can Pause, Ticket Remains

For the current fix, messages can now find their assignee. Next question: after the Worker submits a PR and ends this execution round, who keeps the task and subscriptions alive?

The prototype introduces Ticket . The group chat topic and the PR are two Threads; the Ticket associates them with the same fix, storing inputs and dispatch records.

A fix may take several rounds: Assignment records who executes this round, Executor Session carries the model and tool calls, Mandate records the acceptance basis and scope. Multiple execution rounds hang under the same Ticket.

Code written, PR submitted, executor reports ready — the execution slot can be released first, waiting for review comments to continue. The Ticket and subscriptions persist; the prototype tracks the linked PR and uses rules around closure, merge, and follow-ups to decide when the task ends. The Worker is done for now, but the fix is not finished.

Animation illustrates process: right side execution runs on demand, left side always the same Ticket. Store uses SQLite to persist events, task relationships, acceptance decisions, pending actions, and message send statuses. On restore, DSH session logs let the executor reconnect to prior interactions; these task records tell the system: which PR it is waiting for, and what actions remain undone.

Writing to the database does not equal completion. The system might have just decided to accept a task but exit before starting the Worker. Therefore the prototype's Engine places task, mandate, dispatch, and pending actions in a single transaction, commits, then starts the executor, delivers input, or sends messages.

On restart, the database still shows actions waiting to launch. If message sending fails, the Effects queue records failure and retries with backoff; Outbox saves send status.

A subtle failure mode: the platform already received the message, but local success recording lagged, causing duplicate sends on retry. For interrupted tasks, the prototype adds a recovery hint to the new Assignment, prompting the executor to check the workspace, Git history, and GitHub before redoing external operations. The database preserves progress, but external side-effects still need verification.

When a human returns the next day asking for progress, the model need not read all history at once. The design proposes Inline & Spill : provide recent relevant info, summaries, and object IDs; long content stays outside the window, fetched on demand. Chained recall lets the model follow references from messages, Threads, Workers, etc., to gradually retrieve associated content.

For example, the old-client constraint lives in the group chat; subsequent modifications must follow those references to retrieve that addition. Records sit in the database, but they must be read when needed, otherwise the model may continue modifying under outdated conditions.

Handling Human Follow-ups and Async ReAct Loop

Waiting hours for a review, releasing the execution slot for other work, is efficient. But when the review arrives, it must re-queue; new tasks keep arriving, and old tasks may still wait long.

The prototype's WorkerSlots adds a small arrangement: human follow-ups can use one extra slot beyond the normal concurrency limit, and waking existing work has higher priority than starting new work. During background batch starts, human additions don't queue behind new tasks; once the extra slot is exhausted, waiting resumes.

Waiting also occurs inside a single execution. A compatibility test runs for a long time; meanwhile the group adds a new condition. If the foreground waits for the test to return, it cannot process new messages.

This involves the design's async ReAct Loop : launch background work, return immediately, and later feed results back as events into the session while the foreground continues receiving messages. The team says the mechanism is implemented in DeepSeek Harness but not enabled by default. New group requirements arrive promptly, but already-issued commands are not automatically revoked; conflicts between the two must still be handled later.

After timely message receipt, the system must distinguish a supplementary condition from a brand-new request. If someone casually mentions another issue in the group, should it start fixing immediately?

The prototype first checks source and identity, then applies policy for model judgment. Tasks self-inferred from discussion default to observe mode: record what would be taken up, but do not start execution. Enabling auto still evaluates against pre-written rules; explicit human requests follow a separate path.

The Ticket's Mandate stores acceptance scope and basis. The fix task watches the entire group chat topic, so it can read new messages, but the subscription itself does not expand its work scope.

The design document's "silent reproduce and fix" example also has a team-configured policy: attempt in background, deliver if usable result appears, otherwise stay quiet. This trade-off mirrors daily collaboration: asking the whole group about every potential issue may turn saved operation time into more messages.

For the same fix, the group may only need results and open questions; the PR needs changes, background, and verification process. These communications are unified by the Router; Worker tool outputs stay internal.

Execution Environment Separation and Watchdog

Even with persistent task records, a sleeping computer can halt progress.

The design document further separates three parts: the compute driving the model-tool loop, the persisted state, and the execution environment hosting code repos and toolchains. In this vision, a cloud agent accesses the user's machine via a resident client-side process; code and toolchains remain local.

DeepSeek references Anthropic's April-published Managed Agents architecture. Lance Martin et al. decouple Harness, persistent session logs, and execution sandbox: the Harness-running process can be replaced while session records remain, and the execution environment connects via tool interfaces. DeepSeek further considers daily development machines: they may have uncommitted changes, internal dependencies, and go offline.

Back to the export defect: dependencies, config, and modifications that reproduce it may all sit on that dev machine. Merely moving code to the cloud may not reconstruct the scene. With compute and environment separated, the agent can keep running in the cloud and access the original environment when local tools are needed.

But when the local machine is offline, commands depending on it still cannot execute. The cloud can continue saving tasks and receiving messages, advancing relevant steps when the device comes back online. System online, task remembered, execution environment available — all three must hold independently.

Cloud compute and cross-device execution are directions discussed in the design document; the public prototype currently demonstrates SQLite-based local task state persistence.

Even with an always-available environment, a fix may stall. The Worker keeps emitting messages but fails to reproduce the defect for a long time — "running" status alone won't reveal this. The design therefore adds a Watchdog Session outside the main system, periodically observing Worker errors, recovery anomalies, and prolonged lack of substantive progress. When the main loop stalls, the watchdog still has a chance to detect and intervene.

Simon Willison's August 2026 post summarizes effective Coding Agent use as two parts: ability to clearly guide modifications and ability to confidently verify correctness. Watchdog helps detect stalls; whether this fix is done still depends on whether the compatibility test covers the old client and whether the PR solves the original problem. Another model saying "progress made" is insufficient to answer those questions.

Experimental Results: Scheduling Benefits

DeepSeek's preliminary experiments run ~300 messages per round, ~20 work requests, each configuration repeated 5 times. Coding work replaced with time-consuming dummy tools; the test measures scheduling and collaboration.

Super-agent task completion time: p50 12.4 minutes, p95 15.7 minutes. Under neutral prompt, single Session + Subagent tool baseline: p95 29.5 minutes.

However, in the neutral prompt's 5 runs, the model never invoked Subagent. Switching to a delegation-preferred prompt yielded delegation in 4 of 5 runs, shortening completion time.

In these runs, handing dispatch to the Router made parallel work occur more stably. The baseline had the tool but the model didn't necessarily use it; to further compare architectures, the model must also stably use concurrent delegation. This compares specific session configurations, not Super-agent versus full DSH.

The direct-delivery mechanism's benefit shows mainly in overhead. Removing direct delivery kept task completion time similar, but Router decision count increased ~30%, and total cached input tokens per experiment rose from 23.23M to 31.77M.

Converting: the no-direct-delivery version reads ~37% more cached tokens; using it as baseline, enabling direct delivery reads ~27% fewer. This does not directly translate to cost reduction — other inputs and outputs must be counted. Super-agent's total cached tokens still exceed single Session; direct delivery saves a portion of repeated coordination.

Why no obvious change in completion time? Combined with the earlier Router load test, the team explains: this load hasn't pushed the Router to throughput bottleneck. Reducing redundant judgments first saves inference overhead. Determining when a single Router needs sharding depends on how much work remains for it to judge after filtering and subscriptions — not just total incoming messages.

Conclusion

Previous Agent Loop discussions focused on how one execution continues and ends. This time the concern is the time outside execution: PR sent, review not back; computer offline, group adds a line. For work that temporarily has no executor but isn't finished, can the system keep remembering and reconnecting?

Returning to the opening fix, the next thing to see is: after crossing several rounds of reviews, CI, and group additions, can it deliver verified changes while humans do fewer rephrasings, follow-ups, and re-explanations.

References

DeepSeek Product Dept: Super-agent Design Exploration: Towards More Autonomous Agent Systems, 2026-10-31 (https://mp.weixin.qq.com/s/zoS7GlReWPhfCjENGxXCdg)

DeepSeek: dsh-superagent-prototype, source code and design docs; analysis version 6337fc8 (https://github.com/deepseek-ai/dsh-superagent-prototype/tree/6337fc823ce20251c8de8085948165c81aaa701e)

Simon Willison: More than just code review, 2026-08-22 (https://simonwillison.net/2026/Aug/22/more-than-just-code-review/)

Lance Martin, Gabe Cemaj, Michael Cohen: Scaling Managed Agents: Decoupling the brain from the hands, 2026-04-08 (https://www.anthropic.com/research/managed-agents)

DeepSeek Harness: Super-agent's underlying agent runtime framework; analysis version ce7073d, includes session persistence, sub-agent, and experimental Agent Teams docs (https://github.com/deepseek-ai/deepseek-harness/tree/ce7073d51254c26cd63b22a60835b8f948deb447)