DeepSeek Super Agent: Event-Driven Router-Worker Architecture with Persistent SQLite Memory

Ten Evolutionary Stages of Agent Construction

The article begins by referencing the earlier piece Agent Kung-fu (WeChat article), which outlined ten methods for building agents. Each stage adds a new layer of capability:

Prompt Workflow Agent – Early Coze-era agents driven purely by prompt chains.

Agent SDK – Code-based agents built on frameworks like OpenAI Agents SDK, Agno, AgentScope.

Control Panel Agent – Platforms like Loopx that standardize task/agent definitions and track progress via a dashboard. Underlying agents are independent (Codex, DSH) rather than SDK frameworks; this explains why OpenAI provides both Agents SDK and Codex SDK.

Harness Agent – Nesting a harness on top of stages 1‑3 to improve execution stability.

Loop Engineering Agent – Given a PRD and evaluation metrics, the agent automatically runs trial‑and‑error loops on the harness.

Graph/Protocol Engineering Agent – Defines interaction protocols among multiple Loop agents via a graph to accomplish complex tasks.

Knowledge/Experience/Business Distillation-Driven Agent – Uses an LLM Wiki to distill domain experts; the distilled knowledge drives iterative agent upgrades.

Ontology-Driven Agent – An ontology links multi-source data and task experience, providing top-level rule governance to avoid conflicting experiences that cause crashes or degradation.

Causality-Driven Agent – Causal reasoning automatically iterates the ontology, which then drives Graph Engineering for complex tasks.

First-Principles-Driven Agent – Unlike causality which modifies existing flows, first principles delete redundant or unnecessary steps and rebuild the entire process from scratch.

DeepSeek's Super Agent Architecture

DeepSeek's super agent is described as an event-driven + dual-layer Session (Router–Worker) + persistent state machine active coding system. It surpasses the Control Panel Agent (stage 3) and Graph/Protocol Engineering Agent (stage 6), while fusing OpenClaw's always-online and autonomy capabilities (referenced in WeChat article OpenClaw architecture analysis ).

Engineering Capabilities

Ops Panel: Lists only items requiring human attention, adhering to the philosophy of minimizing human attention consumption.

Concurrency Control: WorkerSlots limits concurrent workers and reserves an extra slot for human messages so new tasks never preempt human follow‑ups.

Fault Recovery: On restart, running tasks resume with a "recovery prompt" requiring the worker to check directory, git history, and GitHub before continuing. Transient network or model errors retry up to three times, then mark as failed.

Delivery Reliability: Outbound messages are ordered by Ticket and session; failures back off from 5 seconds up to 300 seconds.

Lifecycle Management: Ticket stages are explicit (queued / working / idle / person-answer / blocked …); supports resume, retry, restart, handback, stop; PR close/merge can drive Ticket termination.

Scope & Permissions: Authorization (Mandate) is granted only at acceptance and is immutable thereafter; policy changes notify affected Tickets but do not revoke directly.

Long-Term Online Design

Router deliberately limited to routing only: Prompt forbids reading code, writing plans, or self-unblocking. Tool layer restricts it to 14 application tools plus read/shell tools – no write/edit permissions.

Store-then-execute: Every decision is written transactionally into an effect queue, then executed by handlers. Deduplication and merging by kind and key, with retry support. Core domain layer performs no I/O, accessing externals only through port interfaces.

Never blocking: Router presets a 5-second limit for foreground commands and task waits; a noWait guard rejects sleep and timeouts over 30 seconds. Prompt instructs: "Result will arrive on its own, end this round."

Decision replay: orchestrator_route is idempotent by trigger ID; each item executes independently. Eval timeouts re-queue, so even if the router misses an event or restarts, the host can retry.

Persistent sessions: Main session ID stored in KV as master-id (default orchestrator-<stateDir hash>). On startup Sessions.ensure recovers it; if missing, a new dsh-superagent-router is created.

All inputs are messages: Candidates, worker reports, human follow‑ups go via steer (queued sequentially). Notifications go via inject (do not wake session, same-name notifications merge). AgentDelivery guarantees exactly-once delivery per request ID, surviving restarts.

Memory Management

Facts stored outside the model: The router's true memory is SQLite – tables for triggers, decisions, tickets, threads, etc. It reads via orchestrator_read with pagination (default 4,000 chars per page, 20 items per list). Retrieval uses SQL LIKE substring matching on trigger text – not vector or semantic search .

Relevant history pushed by host, not recalled by model: Candidate cards carry related_tickets (max 8, in-progress first), delivered_to, referenced_tickets, and handed_back with reasons.

Task isolation, on-demand expansion: Each Ticket gets a dedicated worker Session. Thread context limited to first 5 messages plus 5 before/after trigger point; assignment text truncated to 1,500 chars, trigger text to 600 chars, with read pointers for truncated content.

Context compression delegated to DSH: Both presets enable compaction-basic, command-compact, and a tool-result trimmer (head 4,096 + tail 1,024 chars when exceeding 8,192). Prompt says "check ticket summary after compression to avoid duplicate work" – i.e., state restored by reading storage post-compression. Compression summarization logic resides in the DSH platform package, not in this repo, so its quality cannot be evaluated here.

Summary

On top of conceptual innovation, the super agent achieves a balance of global continuity + task parallel isolation :

Router maintains long-term online presence and global coordination via a persistent main Session, periodic Passes, and reliable Effects/Outbox.

True "memory" is structured state in SQLite (Ticket/Thread/Subscription). Workers are ephemeral and isolated to avoid cross-contamination, while subscriptions enable continuous context across messages.