DeepSeek's Super-Agent: Open-Source Architecture for Continuous, Proactive AI Collaborators

DeepSeek releases dsh-superagent-prototype, a next-gen agent architecture using a dual-layer Router/Worker design, event-driven triggers with two-level filtering and subscription pass-through, context management via inline/spill and chained recall, async ReAct loops, compute-storage separation, and a Watchdog for self-healing; experiments show 12.4 min p50 task completion but 3.8x token overhead versus single-session baselines.

PaperAgent
PaperAgent
PaperAgent
DeepSeek's Super-Agent: Open-Source Architecture for Continuous, Proactive AI Collaborators

Why Super-Agent Is Needed

Current mainstream agents operate within a single session, each independent. DeepSeek observes that a human can only actively track 3–5 concurrent sessions , making human attention the bottleneck for multi-task throughput, not model capability. Super-Agent breaks the binding between an agent and a single manual session, becoming a continuous entity that retains context across sessions and proactively advances multiple tasks. It targets four properties: continuous, efficient, proactive, persistent .

Overall Architecture: Five Modules

The architecture comprises five modules: a dual-layer architecture balancing continuous interaction with high-throughput concurrency; event-driven mechanisms for proactive response; human-centric interaction for natural experience; separation of compute, state, and environment plus a Watchdog for cross-device persistence and self-healing.

Super-Agent overall system architecture
Super-Agent overall system architecture

Dual-Layer Architecture: Router Coordinates, Workers Execute

The core tension is that continuity and throughput cannot both be maximized in a single session : stuffing all events into one session kills throughput; spawning a new session per event loses global context. The solution splits into two layers:

Router layer – always-on, handles all human interaction and task dispatch, acts as the global sequencing/coordination/memory point. It only schedules, does not execute, and can even omit heavy tools (e.g., Bash), allowing a lightweight model to balance speed and quality.

Worker layer – isolated sessions, each with full tool access and the strongest model, focused on completing a single task well.

Dual-layer architecture: Router handles routing and external interaction, Workers isolate concurrent execution
Dual-layer architecture: Router handles routing and external interaction, Workers isolate concurrent execution

Event-Driven: From Passive Reply to Proactive Action

Environment events — group chat messages, emails, calendar items, code review comments, CI results — are called Triggers . Around a Trigger's lifecycle, four progressive mechanisms are designed:

Two-level filtering : a programmatic Fast Path uses deterministic rules to quickly admit or discard most noise; candidate events then go to a semantic Slow Path where an LLM judges whether action is needed.

Subscription & pass-through : consecutive Triggers under the same PR or topic form a Thread . Once a Worker subscribes to a Thread, subsequent events are passed directly to it without Router re-routing; the Router only handles cold-start of new tasks.

Inline & Spill with chained recall : controls context injection density (detailed in next section).

Speculative execution : when outcome is uncertain, the system tries in the background; if valuable, the result is delivered, otherwise discarded. Example: while users discuss a fix in chat, the fix PR is already prepared.

Two-level filtering
Two-level filtering
Consecutive Triggers in the same IM topic or GitHub PR form a Thread
Consecutive Triggers in the same IM topic or GitHub PR form a Thread
Initial Trigger creates Worker via Router and establishes subscription; subsequent Triggers in same Thread pass directly to Worker
Initial Trigger creates Worker via Router and establishes subscription; subsequent Triggers in same Thread pass directly to Worker

Context Management: Treat the Window as a Cache

Inputs shift from discrete human prompts to a continuous stream of environment events, making the context window the scarcest resource. Borrowing from compiler optimization : Inline places recently likely-needed information directly into the window, saving tool-call round-trips; Spill keeps oversized content outside the window, retaining only a reference or summary, reading it on demand. Chained recall retrieves spilled context stepwise when needed.

Chained recall
Chained recall

Full-Duplex Interaction, Compute-Storage Separation, and Watchdog

Async ReAct Loop

Classic ReAct loops block on synchronous tool calls, preventing the session from responding to new input. The design switches to asynchronous start() and stop(): the model calls start() and immediately receives a "started" response; the background execution result is later delivered as a new event to the session. This decouples foreground conversation from background execution, turning half-duplex into full-duplex.

Classic ReAct Loop vs. async ReAct Loop comparison
Classic ReAct Loop vs. async ReAct Loop comparison

Compute-Storage Separation

The compute that drives the Agent Loop runs in cloud-based stateless elastic containers; session state is persisted to a database. The heavy execution environment stays on-premise, with only a lightweight daemon running on the endpoint that does not hold session state. This aligns with Anthropic's "brain-hand separation" and supports BYOM (Bring Your Own Machine), letting users connect their daily development machines directly to the cloud agent.

Agent Loop and persistent state separated in the cloud
Agent Loop and persistent state separated in the cloud

Watchdog

An independent Watchdog session acts as an external control loop. It not only monitors process liveness but also uses a model to judge whether each Worker is making substantive progress or drifting off-course. Maintainers can even instruct it in natural language to adjust the main system's prompts and trigger rules on the fly.

Experimental Results: Faster, More Stable, at the Cost of More Tokens

Ablation experiments used group-chat and GitHub CI message streams to drive four configurations: each run ~300 messages, ~20 work requests, repeated 5 times.

Task completion time : Super-Agent p50/p95 = 12.4 / 15.7 minutes , significantly better than a single session with a Subagent tool. The latter heavily depends on prompt wording and on-the-spot model judgment; with a neutral prompt, 5 runs never delegated to a Subagent, all work crammed into the main session and constantly interrupted, p95 = 29.5 minutes .

Token cost : Super-Agent consumed ~ 23.23 million read-cache tokens per run vs. ~ 6.05 million for the single-session baseline. Removing the pass-through mechanism left completion time almost unchanged but increased Router decisions by ~30% and token usage by ~37%, confirming pass-through saves real overhead.

Router batch processing under load : as Trigger arrival rate rose from ~1/min to ~40/min, average batch size grew from 1.0 to 2.8, while per-request latency only increased from 2.5s to 3.9s. Amortized inference time per decision dropped from 6.4s to 1.6s. Thus, under congestion, automatic batching yields throughput gains; a single resident Router suffices for current team scale without premature horizontal sharding.

Cumulative arrival curve of work requests and cumulative completion curves for four configurations
Cumulative arrival curve of work requests and cumulative completion curves for four configurations
Task completion time P50/P95 and per-run read-cache token comparison for four configurations
Task completion time P50/P95 and per-run read-cache token comparison for four configurations
Batch size, per-request latency, and amortized inference time per decision at different Trigger arrival rates
Batch size, per-request latency, and amortized inference time per decision at different Trigger arrival rates

Conclusion

As model single-task capability grows, the productivity bottleneck shifts from the model to human attention. Super-Agent's approach lets the system take over session management and context synchronization at the infrastructure layer, freeing humans for higher-level decision and acceptance.

While the group discusses a solution, Super-Agent has already submitted a fix PR in the background
While the group discusses a solution, Super-Agent has already submitted a fix PR in the background

Open-Source Prototype

The prototype repository is available at:

https://github.com/deepseek-ai/dsh-superagent-prototype/tree/main
Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

AI AgentsDeepSeekAgent ArchitectureEvent-Driven ArchitectureCompute-Storage SeparationContext ManagementSuper-AgentAsync ReAct
PaperAgent
Written by

PaperAgent

Daily updates, analyzing cutting-edge AI research papers

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.