DeepSeek's Super-Agent: 4 Core Designs Turning AI into Teammates

Overview

DeepSeek has released the dsh-superagent-prototype on GitHub alongside a detailed Zhihu technical article. The prototype implements a Super-agent designed to act as a persistent digital coworker that can juggle multiple tasks across chat channels (Feishu, GitHub PRs, CI) without human attention bottlenecks. The author notes that a single person can only monitor 3–5 concurrent sessions; as models get stronger, the bottleneck shifts to human attention. The solution is a system that achieves four properties simultaneously: cross-channel continuity, multi-task parallelism, proactive event-driven action, and always-online presence.

Core 1: Router–Worker Architecture (Front Desk Doesn't Cook)

The system adopts a two-layer design inspired by a restaurant:

Router (front desk) : A single persistent session that maintains global context, routes incoming events, and never executes concrete tasks — it may not even be granted a Bash tool. The Router uses a lightweight model.

Workers (chefs) : Each task spawns an isolated Worker session with its own context directory. Workers use the strongest available model to produce code-quality results and report back only to the Router. The user interacts with just one Agent (the Router) from start to finish.

This enforced separation solves the common problem where models ignore instructions to delegate (e.g., "use a Subagent") and instead try to do everything in the main session, causing context overload and interruptions.

Core 2: Two-Level Filtering + Thread Direct Pass

To make the Agent proactive without drowning in noise (e.g., 300 messages with only ~20 actionable requests), DeepSeek uses a fast/slow path:

Gate (fast path) : Code-based allowlist rules — channel scope, source, keywords — that discard most messages at zero compute cost.

Assessment (slow path) : A model evaluates remaining messages against team-defined prompt rules to decide whether to create a work order and dispatch a Worker.

Thread Direct Pass : Once a Worker is assigned to a thread (e.g., a GitHub PR), subsequent messages in that thread go straight to that Worker, bypassing the Router entirely. Removing this direct pass increased Router decisions by ~30% and raised cached token reads from 23.23M to 31.77M in experiments.

Speculative Execution : When a bug is reported in chat, the system can silently reproduce and search for a fix in the background (observe mode by default). If a fix is found, it surfaces a PR; if not, it stays quiet. This runs in default observe mode — it records "would have acted" without actually executing.

Core 3: Async ReAct for Long-Running Tasks (Half-Duplex vs Full-Duplex)

Classic ReAct uses a blocking

run()</sup> that halts the event loop while a long tool (e.g., test suite) executes — like a phone call where nobody else can get through. DeepSeek splits long tools into <code>start()</sup> and <code>stop()</sup>:</code></code>

start()</sup> returns immediately with "Started", freeing the Router to continue chatting.

The tool runs in the background; when finished, the result is injected as a new event into the session.

Users can interrupt with stop()</sup> at any time. This async ReAct mechanism is implemented in DeepSeek Harness but disabled by default. Additionally, the Router limits chat replies to ≤100 words; long-form output (PR descriptions, emails) is reserved for asynchronous channels.

Core 4: Cloud Brain, Local Hands (BYOM — Bring Your Own Machine)

Local agents die when the laptop lid closes. DeepSeek separates three concerns:

Stateless compute : Runs in cloud containers (Loop containers) that can be replaced or scaled freely.

Session state : Persisted in a database; container restarts don't lose context.

Local execution daemon : A lightweight agent on the developer's machine (or cloud sandbox) that holds uncommitted changes, local credentials, and internal network access. It only executes commands and returns results.

The cloud-side Watchdog (itself an Agent) periodically checks each Worker for infrastructure health (API errors, state recovery) and task progress (stuck, drifting). It can be queried directly for diagnostics. In the prototype, Watchdog is simplified to hourly restarts without drift detection.

Experimental Results (Synthetic Load, Preliminary)

DeepSeek ran 5 trials each on a synthetic load of ~300 messages containing 20 work requests:

Super-agent : p95 task completion time 15.7 min (p50 12.4 min).

Single Session + Subagent (neutral prompt) : p95 29.5 min; in 5 runs the model never delegated once — the main session was repeatedly interrupted by new messages.

Batching effect: As trigger arrival rate increased from ~1/min to ~40/min, average batch size grew, and per-decision latency dropped from 2.5s to 1.6s because queued messages are prefilled in parallel, amortizing cost.

Trade-off: Parallel sessions increase cached token reads (token cost) but reduce wall-clock time.

Prototype vs. Design Document

The Zhihu article describes the target architecture; the GitHub prototype is a "model apartment" validating the technical route. Several advanced designs remain unimplemented in the open-source version:

Speculative execution defaults to observe mode (no real action).

Async start/stop exists in Harness but is disabled by default.

Watchdog lacks drift detection.

Storage-compute separation and BYOM daemon are not reflected; the prototype runs locally with local state.

The author observes that DeepSeek appears to be moving beyond selling models toward selling "digital coworkers" — stacking model, Harness, and Super-agent to capture office-productivity market share.