DeepSeek Super-agent: OS-Inspired Agent Architecture with Scheduling, Caching & Watchdog

Background: From Model Capability to Human Attention Bottleneck

Single-task coding agents have matured; the productivity bottleneck has shifted from model capability to human attention. DeepSeek Harness team argues agents must evolve from passive single-session tools into persistent, parallel, proactive collaborators—Super-agents—with four key traits: Continuous (cross-channel interaction without session context switching), Efficient (parallel task handling), Proactive (environment-driven action), and Persistent (always-on, recoverable). A single ReAct loop cannot support all four; a new architecture is required.

Overall Architecture: Five Modules

Super-agent comprises five modules mapped to the four traits: dual-layer Router-Worker for continuity and concurrency, event-driven design for proactivity, human-oriented interaction for continuity/efficiency, compute-storage-environment separation for persistence, and an external Watchdog for self-healing. Environment events pass through two-tier filtering, then the Router dispatches to isolated Workers; state is persisted centrally; Watchdog monitors from outside.

OS Concepts Mapped to Agent Design

3.1 Scheduling: Process Scheduler → Agent Task Scheduler

OS kernels manage scarce CPU via ready/blocked states, time-slicing, priority dispatch, and resource isolation. Super-agent's Router-Worker dual layer mirrors this: Router = scheduler (receives events, prioritizes, creates tasks, assigns Workers); Worker = isolated process (own context, no cross-task pollution); Thread subscription = directed signal delivery (bypasses scheduler for subsequent events); WorkerSlots = max concurrency quota; batching = merged runqueue wake-ups to reduce LLM call overhead.

Key implementation rules: (1) Avoid single ReAct loop (serial). (2) Router only decides, uses lightweight model. (3) Decouple task description (Ticket) from execution carrier (Worker). (4) Model blocked/ready states: Worker blocks on tool calls, freeing Router. (5) Overload protection via max Worker concurrency queueing. Boundary: Router becomes a single point; future scaling may shard scheduling, trading some global continuity for throughput.

3.2 Caching: Page Cache → Context Window Cache (Inline & Spill)

OS Page Cache loads hot disk data into fast memory, evicts cold data via locality, keeps only indices. Super-agent's Inline/Spill replicates this for LLM context windows: context window = cache; external SQLite = disk; Inline = load into window; Spill = evict, keep ID+summary; Chain of Recall = page-table pointer chasing via IDs; locality strategy = recent Thread/Ticket messages Inline, older/weakly related Spill.

Implementation rules: (1) Unified object IDs (Trigger, Thread, Ticket, Worker, PR, comments) as cache indices. (2) Tiered injection: summaries/IDs first, full text on demand. (3) Per-role context budgets with auto-spill. (4) Cache invalidation on task completion/Thread archive. (5) Trade off model token cost (fast) vs tool read cost (slow). Boundary: Weak locality (random historical jumps) increases tool reads, raising overhead.

3.3 Compute-Storage Separation: Decoupled Storage/Compute → Agent State/Inference/Execution Decoupling

Cloud-native compute-storage separation lets compute nodes scale independently while state lives in remote block storage. Super-agent extends this to three layers: (1) Compute: stateless Agent Loops (Router/Worker) in cloud containers, restartable/migratable. (2) State: independent persistent store (SQLite/DB) as single source of truth for Triggers, Threads, Tickets, decisions, progress. (3) Execution: BYOM (Bring Your Own Machine) sidecar daemon on local dev machines, holding code, uncommitted changes, credentials; only executes commands, no Agent reasoning.

Implementation rules: (1) Single writer (Engine) for all domain state changes. (2) Reasoning loops stateless, reload from DB on start. (3) Execution environment fully decoupled: Agent sends commands to daemon, daemon returns results; daemon offline pauses task, doesn't destroy session. (4) Effects (external actions) persisted in queue for at-least-once delivery. (5) Layered fault tolerance: compute quick restart, state backup, execution environment failures isolated. Boundary: Network latency introduced; state layer becomes critical single point needing HA; daemon security (credentials, file permissions) is hard.

3.4 Watchdog: Hardware/OS Watchdog → Independent Self-Healing Loop

OS watchdogs are independent hardware/daemons that reset hung main CPUs. Core principle: fault detection cannot run inside the faulty component . Super-agent's Watchdog is a separate Agent Session, not code inside Router. It monitors two planes: infrastructure (process liveness, connectivity, queue backlogs, storage errors) via deterministic Fast Path; and semantic task progress (Worker stuck in loops, goal drift) via independent LLM Slow Path.

Implementation rules: (1) Watchdog runs in own process/session, survives main system hang. (2) Distinguish hard faults (auto-retry/reset) from semantic soft faults (alert first, human confirmation for rollback). (3) Heartbeats: Workers report substantive progress; repeated tool calls without progress = stuck. (4) Configurable remediation: retry, terminate Worker, spawn new Worker, notify human; high-risk actions default to alert-only. (5) Unified observability: all healing events logged, queryable via natural language. Boundary: Watchdog itself can err; keep remediation conservative, block auto-execution of destructive ops.

Dual-Layer Architecture: Continuity and Throughput Without Trade-off

Classic tension: single session gives continuity but serial throughput; many independent sessions give throughput but fragmented context. Super-agent splits: resident Router handles human interaction and global coordination; isolated Workers execute tasks concurrently. Session becomes implementation detail, not user burden.

4.2 Router: Dispatch Only, No Execution

Router is the permanent global routing layer, aggregating all human interactions and cross-task decisions. To avoid bottleneck, it does not execute tasks (may lack Bash tool). Lightweight model suffices. Load managed via batching and Thread subscription direct delivery.

4.3 Worker: Execute Only, No Direct Human Talk

Workers have isolated contexts, full toolsets, strongest models. They never reply directly to humans; all status reported to Router for unified response. Complex tasks may spawn Subagents/Teams internally, transparent to Router.

4.4 Thread Subscription: Direct Event Delivery

After Router creates Worker for a Thread (GitHub PR, IM topic, email thread), Worker subscribes to that Thread. Subsequent events deliver directly to Worker, bypassing Router. Multi-subscription allows multiple Workers to see each other's actions and self-coordinate.

4.5 Batching: Congestion Lowers Per-Decision Cost

Events arriving during Router's inference accumulate; next inference processes them as a batch. Experiments: trigger rate 1→40/min, avg batch 1.0→2.8, latency 2.5s→3.9s, per-decision inference time 6.4s→1.6s. Higher load → cheaper per decision.

4.6 vs. Agent Teams

Agent Teams decompose a single complex task with tight coupling and heavy Lead coordination. Super-agent's Router only handles inter-task dispatch, not intra-task decomposition. Constraining a Team Lead to only external interaction and task dispatch yields the same dual-layer pattern.

Event-Driven Proactivity

Drive shifts from user prompts to environment Triggers (chat, email, code review, CI results). Four challenges: noise filtering, routing, context assembly, speculative action.

5.1 Two-Tier Filtering: Fast Path Code, Slow Path LLM

Event streams are high-noise, low-trigger-rate. Deterministic Fast Path (source, group, whitelist) filters most; candidates go to LLM Slow Path for semantic judgment. Fast Path = code; Slow Path = prompt-configurable natural language extension.

5.2 Inline & Spill: Context Window as Cache

Injecting too much dilutes attention; too little forces repeated tool calls. Treat context window as cache: Inline = hot data directly in window; Spill = cold data outside with ID+summary. Strategy: start minimal (current object ID+summary), then Inline tightly related objects (same Thread/Ticket), then spatiotemporal neighbors (adjacent messages/comments); spill on budget exceed, keep continuation pointer.

5.3 Chain of Recall: Multi-Hop Retrieval via IDs

Consistent Inline/Spill across all objects yields a reference graph. Tools return Inline/Spill-wrapped results with next-hop IDs, enabling model to traverse from Trigger → Thread → Worker Session → related code review Thread, mitigating Router's long-context loss.

5.4 Speculative Execution: Background Trial, Deliver If Valuable

Borrowing CPU speculative execution: Agent pre-computes in background on environmental signals. Personal assistant: meeting invite → pre-check calendar, gather background, draft reply. Dev collaboration: "silent reproduce & fix"—on issue discussion, Agent attempts reproduction/fix in background, delivers only on confirmed simple fix; otherwise stays silent.

Human-Centric Interaction & Persistent Online

6.1 Async ReAct Loop: Background Work, Foreground Responsive

Classic ReAct blocks on tool execution. Convert to full-duplex: tools become async start()/stop(); model gets immediate Started, continues; tool completion arrives as new event; model can stop long commands. New inputs processed after current reasoning step, not after background tool finishes. Implemented in DeepSeek Harness but not default-enabled.

6.2 Multi-Channel Etiquette

IM: low-interruption, ≤100 words, only decisions/approvals. GitHub/email/docs: structured, high-density, full context. Dual-layer already isolates verbose Worker reasoning from external channels.

6.3 Compute-Storage Separation & BYOM

Step 1: separate compute (cloud stateless containers) from state (session DB) → cloud persistent online. Step 2: separate cloud Agent Loop from stateful execution environment → local daemon (BYOM). Daemon: long-lived connection to cloud, executes sandboxed commands (git diff, npm test, file read), returns stdout/stderr/exit code. No session, model, or business state. Aligns with Anthropic's "brain-hand separation" but targets intermittent personal machines with local uncommitted changes and credentials.

6.4 External Watchdog: Infrastructure + Semantic Monitoring

Persistent systems need external control loop. Watchdog monitors not just process health but also semantic progress (Worker loops, goal drift). It is a full Agent Session with tools; maintainers can query failure causes in natural language and instruct online corrections.

Source Code Analysis: dsh-superagent-prototype

Repo: deepseek-ai/dsh-superagent-prototype (MIT, research prototype, largely coding-agent generated). Structure: core (domain, no I/O), app (runtime/adapters), sources (GitHub/Lark plugins), executor (Worker execution), client (web panel), infra (infrastructure).

7.2 Scheduling in Prototype

Core: Engine + Ticket + WorkerSlots + Thread subscription + batching Evals. Ticket ≈ task_struct (metadata, priority, state). WorkerSlots enforces max concurrency. Evals module batches Triggers for Router evaluation. Thread subscription binds events directly to Workers. Role isolation via interface constraints: Router only evaluates/dispatches; Workers only report facts.

// src/core/workerSlots.ts
class WorkerSlots {
  private used = 0
  constructor(readonly max: number) {}
  tryAcquire(): boolean { return this.used < this.max ? !!this.used++ : false }
  release() { this.used = Math.max(0, this.used - 1) }
}

7.3 Caching in Prototype

MasterAssessor implements Inline/Spill + Chain of Recall. All domain objects have unique IDs (page-table pointers). Hard-coded context budgets: Trigger body ≤4000 chars, Thread messages tiered truncation, distant objects keep 50-char stub (Spill). Recent related objects (same Thread/Ticket) get summary+ID Inlined. orchestrator_eval_read tool fetches spilled content on demand (page fault). Each read returns next-hop IDs for multi-hop recall.

// src/core/assessor.ts
function spillText(raw: string, budget: number): { stub: string, fullId?: string } {
  if (raw.length <= budget) return { stub: raw }
  return { stub: raw.slice(0, 50) + "…", fullId: uuidv4() }
}

7.4 Compute-Storage Separation in Prototype

Three layers enforced: (1) State: SQLite stores all domain objects; Engine is sole writer via transactions. (2) Compute: Router/Worker loops stateless, reload from SQLite on restart. (3) Execution: Executor spawns remote daemon; local code/credentials stay on device. Effects queue persists all external actions (kind+key), executes after commit, exponential backoff on failure.

// src/app/store.ts
async function tx<T>(db: Database, fn: (tx: Database) => Promise<T>): Promise<T> {
  await db.exec("BEGIN")
  const res = await fn(db)
  await db.exec("COMMIT")
  return res
}

7.5 Watchdog in Prototype

Partial implementation: HealthBoard + Effect queue retry. HealthBoard tracks heartbeats for Workers/daemons/external sources (Fast Path infrastructure checks). Effect queue has exponential backoff, marks failed actions for alerting. Missing: semantic progress judgment, independent Agent patrol loop (exists in internal Harness, not prototype). Guidance: add separate Watchdog Session polling all Ticket progress.

// src/core/health.ts
class HealthBoard {
  private beats = new Map<string, number>()
  heartbeat(id: string) { this.beats.set(id, Date.now()) }
  isStale(id: string, threshold: number) {
    const t = this.beats.get(id)
    return !t || Date.now() - t > threshold
  }
}

7.6 Role Isolation via TypeScript Interface Slicing

Callers receive only role-specific Engine slices, not full Engine. Sources can only receive Triggers, bind Threads, report closure. Main Session only evaluates/routes. Executor only reports facts. This enforces architectural boundaries (Router dispatches only, Workers execute only) at type level.

export type EngineForMainSession = Pick<Engine, "decide" | "reply" | "note">
export type EngineForSources = Pick<Engine, "receive" | "bindThread" | "threadClosed">

7.7 Effects: Persistent Side-Effect Queue

Side-effects (create evaluation, launch Worker, deliver message, relay, notify, reply) go through persistent queue in src/app/effects.ts. Each has kind+key, written first, executed after commit, exponential backoff. Six kinds: assessment, launch, delivery, relay, notice, reply. Deadline semantics: candidate card delivery timer starts only after delivery to main Session; Session busy time doesn't consume evaluation budget—"human-facing response time".

host.effects.handle('assessment', async ({ triggerId }, evalId) => {
  const candidate = this.host.engine.candidate(triggerId)
  if (candidate?.evalId !== evalId) return
  await this.host.deliver(`candidate:${evalId}`, JSON.stringify({ kind: 'candidate', ...await this.host.candidateCard(candidate) }))
  this.host.engine.candidateDelivered(evalId)
}, { limit: () => host.paused() ? 0 : 4 })

7.8 Execution & Persistence

DshExecutor

gives each Ticket a Session and isolated worktree (workerSessionId derived from ticket.id, path wt-${ticketId.slice(0,12)}). WorkerSlots controls capacity. Launch/delivery via effect queue. Store: single SQLite file with directory lock to prevent concurrent writes. Tables: trigger, disposition, trigger_thread, thread, ticket, decision, effect, outbox, kv. Generated columns (active, subscribed, open) indexed for fast active-workset reads. Main Session has 14 app tools (including orchestrator_route accepting 1-20 decisions); Executor Session has 6 tools, deliberately lacks "ask/display" tools so Workers cannot interrupt humans.

// src/executor/dsh.ts
function makeWorkerSessionId(ticketId: string): string {
  return `worker:${ticketId}`
}
function worktreePath(root: string, ticketId: string) {
  return path.join(root, `wt-${ticketId.slice(0,12)}`)
}

7.9 Prototype vs. Design Gaps

No independent Watchdog Session (HealthBoard + effect retry only). Async ReAct start/stop implemented in Harness but not default-enabled. Long-term cross-month memory, A2A communication, security isolation not addressed. Treat prototype as engineering slices of the four OS ideas, not complete implementation.

Conclusion: Architectural Blueprint Over Prototype

The architecture doesn't invent new theory; it recombines decades-proven OS concepts—scheduling, caching, Fast/Slow Path, compute-storage separation, speculative execution, watchdog—into an executable engineering blueprint for continuous, parallel, proactive, self-healing agents. Experimental data preliminarily validates system-level session scheduling. The real takeaway for agent engineers is the architectural mindset: migrate OS scheduling, caching, compute-storage separation, and watchdog wholesale into Agent design for reusable Super-agent architecture.