DeepSeek Super Agent Architecture: Continuous, Multi-Task AI Without Session Juggling

01 Current Agent Bottleneck: Human Attention

Typical local single-session agents operate via a ReAct Loop: think one step, call a tool, observe result, repeat. This serial execution works for one task but breaks down with multiple concurrent tasks. Users must manually open separate sessions for each task (research report, emails, code changes, slides), each isolated with no shared context. DeepSeek observes humans can only track 3–5 sessions simultaneously; as models become more capable, users offload more parallel work, yet human attention remains the bottleneck.

02 Super Agent's Four Core Characteristics

Continuity : Recognizes related interactions across platforms (e.g., IM group says "use Plan A", later GitHub PR comment says "use Plan B") and adjusts execution without re-briefing.

Efficiency : Background tasks (coding, report writing) run while new instructions are accepted immediately; no need to wait for completion.

Proactivity : Continuously monitors environment events (group messages, emails, calendar, code reviews, CI results) and acts when appropriate, staying silent otherwise.

Persistence : 7×24 online, integrated into actual work environments, survives failures and restarts.

03 Five Core Modules

Module 1: Dual-Layer Architecture (Router / Worker)

Two extremes: single session (continuous but serial, context pollution) vs. many sessions (parallel but fragmented, user overwhelmed). DeepSeek splits "continuity" and "concurrency" into two layers:

Router (upper layer) : Persistent, lightweight model; communicates with user, dispatches tasks, coordinates cross-task concerns, aggregates key decisions. Handles "long input, short output" via batching: accumulates events during inference, processes them in next round; prefill parallelism keeps per-decision overhead sublinear. Existing task events can route directly to Workers, reducing Router load.

Worker (lower layer) : One per concrete task, isolated context, strongest model. Complex tasks may spawn sub-tasks. Workers report completion or issues to Router; Router consolidates replies to user. User interacts only with Router; session management becomes automatic.

If Router uses a persistent session, will it clog? Router uses batching to improve throughput. Accumulated events are processed together next round. Router calls are "long input, short output"; prefill parallelism means merged event latency grows slower than event count. Within context and model limits, batching reduces amortized inference cost. Subsequent events for existing tasks go straight to Workers, further offloading Router.

Module 2: Event-Driven (Trigger) — From Passive to Proactive

Inputs expand to continuous environment events: group messages, emails, calendar alerts, code review comments, CI results. These are called Triggers . Four mechanisms enable proactive response:

Two-Level Filtering : High-volume channels (e.g., work groups) first pass programmatic rules (specific groups/accounts, @mention required, or continuous observation for feedback channels). Surviving events then go to a semantic-filtering LLM that judges intervention need using content, context, and prompt strategy.

Routing & Many-to-Many Thread Subscription : Events around a PR, IM topic, or email thread form a Thread (event stream). Same PR may have separate Threads for group chat and GitHub comments, both subscribable by one Worker. Platform-provided correlation (repo+PR number, IM topic ID, email reply chain) determines membership. Unsubscribed Threads: Router assigns to existing Worker or creates new one, establishes subscription. Thereafter, new events deliver directly to Worker. Worker can reject out-of-scope events back to Router. Router retains global observability. Subscription is many-to-many : a bug-fix Worker subscribes to both group chat and PR; a PR can be subscribed by fix and review Workers simultaneously — each sees the other's actions, enabling conflict detection. Router aggregates key conclusions for user.

CPU Cache-Style Context Management (Inline & Spill) : Borrows cache locality principle — keep most likely needed info in context window, rest accessible via read tools. Implementation: provide current object ID + summary, closely related object IDs, recent messages, replied content. Both event injection and tool results follow this pattern with length caps.

Inline : Place content directly in context (e.g., Trigger #42 content + its Thread #08 ID + Worker #03 ID).

Spill : When exceeding cap, keep summary/prefix in window, full content external with read entry (e.g., Trigger #42 shows first 50 chars; model calls read_trigger(#42) for more).

Chained Recall : Same rules apply to Triggers, Threads, Worker Sessions. From Trigger #42 read Thread #08 → returns Worker #03 ID → read Worker #03 → gets code review Thread #15 → etc. Each tool response includes next-step summaries/IDs. Router can thus reconstruct relevant context incrementally, avoiding full-history dump. Relies on persisted object associations; long-term memory organization remains open.

Speculative Execution : Pre-emptively attempt work before user asks. Example: meeting invite email arrives → Agent background-checks calendar conflicts, drafts reply; user just clicks send. Internal "silent reproduce and fix" strategy: on bug report in dev group, Agent quietly reproduces, searches fix; only posts patch if bug confirmed and fix simple/reliable; otherwise stays silent, reducing noise.

Module 3: Asynchronous Multi-Channel Interaction

Traditional ReAct blocks on long tool calls. DeepSeek uses async start() / stop():

Model calls tool → tool immediately returns "started" status; model continues, new messages processed after current reasoning step.

Background task completion → result wrapped as new message delivered back.

Model can call stop() if task stalls or runs too long.

Channel-specific output density via prompts:

Verbose reasoning and dense tool calls stay inside Worker.

IM (group chat): low interruption — only asks for decisions or delivers concise conclusions, like a reliable human colleague.

Async channels (email/docs): high information density — full background, conclusion, and evidence in one shot.

Module 4: Compute-State-Environment Separation — Laptop Lid Closed, AI Keeps Working

Local agents (e.g., workbuddy) bind compute, state, execution environment to one device — sleep/offline kills process. Cloud agents (Manus, sandboxes) stay online but can't easily access local files, intranet, private credentials. DeepSeek decouples three dependencies:

Step 1: Compute-State Separation (Cloud for Persistence) : Compute becomes stateless, runs in cloud containers; all session state (history, progress) stored in cloud DB. Containers restart/scale/replace freely; continuity guaranteed by DB.

Step 2: Compute-Environment Separation (Local Lightweight Daemon) : Compute in cloud, but execution needs local files, software, credentials. Syncing to cloud sandbox is costly and misses uncommitted changes, private secrets, intranet deps. Solution: keep execution environment local. Deploy a lightweight Daemon on user's machine (or managed/ephemeral cloud env) that cloud calls on demand. Daemon holds no session state; only executes commands, returns results. Supports multiple devices; office PC sleeps → cloud continues; PC wakes → resumes device-dependent steps.

Module 5: External Watchdog — Guards Against Crashes and AI "Hallucination Drift"

Persistence requires self-recovery. Agent failures differ from traditional software: process alive but model stuck in loop or drifting from goal. Watchdog (separate Agent) uses timed messages to:

Handle infra faults (API errors, state restore failures).

Periodically ask model: "Is there substantive progress? Is direction aligned with overall goal?" Intervene on anomaly; retry on transient external faults until recovery.

Watchdog itself is an Agent; maintainers can query in natural language: "Why did that task fail?" or command runtime strategy changes.

04 Not a Mature Product Yet

Internal Super Agent instances already participate in bug reproduction, fixing, code review. Open-sourced dsh-superagent-prototype implements only part of the design — a prototype for validating the technical path. Current simplicity relies on several simplifications; open questions remain:

When task count and model scale grow, when and how to shard the single Router?

Should Workers communicate directly?

Over months/years, how to organize, update, reliably recall long-term memory?

When users no longer face "chat windows", what new UI manages tasks?

Security and privacy are paramount:

More external events (emails, chats, web) → more untrusted input exposure.

Cloud Agent connects via Daemon to real devices.

Cloud compromise or prompt injection in malicious email could propagate via Daemon to local devices.

Even without cloud breach, local credentials/secrets entering model context window risk leakage.

These concerns limit Super Agent to small, high-trust internal environments for now.

05 Closing Thoughts

Past two years focused on model and single-turn reasoning improvements. As those advance, multi-task coordination and user oversight burden become the new UX frontier. DeepSeek's architecture targets exactly this:

How to use system architecture so Agents continuously track tasks, respond timely to changes, proactively handle appropriate work, and reduce user context-switching and repeated briefing.

If these designs run reliably in practice, we spend less time managing sessions and more on decisions requiring human judgment.