DeepSeek SuperAgent Kernel: A Scenario Analysis (Nov 2026)

Updated November 1, 2026 · By Cameron Voss and Marcus Bell

These are our notes after reading the Super-agent design exploration article and then reading the source code. We have tried to write them in plain human language, which makes them easier to follow.

The overall architecture: external inputs (Feishu, GitHub) are translated by their Sources into unified Trigger and Thread facts; a main Session evaluates and routes them; the Engine, a deterministic rules core with exclusive write access, owns Ticket, Mandate, and Assignment state; workers execute in their own directories; an effects queue persists every side effect before it runs; and a web panel shows humans only what needs them.

Summary up front

1. The superagent module, once written, is a plugin for DeepSeek Harness.
2. It has exactly one function: letting DeepSeek Harness take on many long-horizon tasks, letting the agent be commanded from multiple places, by several people at once, working concurrently on one thing. A team or organization, with many input sources (Feishu, GitHub, and so on) combined toward one piece of work, which suits human organizations better.
3. The architecture is actually simple: there is a panel for humans, and the messages arriving from commanders in every direction are received by sessions at the kernel layer. Once received, they are not executed directly; the kernel layer first consolidates them, then hands them to workers to execute. This is what keeps several commanders from descending into chaos.
4. To implement this mechanism, the foundation must separate storage from compute. With storage and compute fused together, things fall apart: with that many people chiming in, one moment this person wants a change, the next moment that person does.
5. The best way to understand storage-compute separation: one codebase with many branches, each branch computing independently, and once the results are computed, they merge into a master branch. The master branch is the storage.

0. Origin: from "execution needs fewer humans" to "attention is the bottleneck"

As the share of single-task execution that needs human intervention keeps falling, the bottleneck limiting further productivity gains shifts from human operation to human attention. The entire design of dsh-superagent can be derived backward from this judgment. Its kernel is not a stronger chat window; it is an autonomous collaboration system that treats attention as its first resource.

The starting point is not "let the agent do more things." It is a one-sentence principle:

This principle runs through every component: one message, one notification, one question, one setting, one panel element, one paragraph of documentation, each spends one unit of human attention. Anything that cannot return more value than it costs is deleted. That is the general outline of the dsh-superagent kernel scenario.

Below, the five pillars, dual-layer architecture, event-driven processing, asynchronous multi-channel interaction, storage-compute separation, and the external watchdog, are mapped one by one onto the dsh-superagent implementation. Then a few end-to-end scenarios tie them together, showing how this kernel rewrites the human-agent relationship in a real repository plus Feishu/GitHub environment from "instruction by instruction" into "a continuously online autonomous collaborator."

1. Dual-layer architecture: the orchestrator/executor split is a layering of attention

The "dual-layer architecture" in dsh-superagent is an asymmetric pair of layers, corresponding to two roles (role-models.ts, prompts/):

The first layer: the main Session (orchestrator / router). It only evaluates and routes: receive a Trigger, pass the Gate admission check, hand it to the model for assessment, then decide accept / attach / stop / ignore.

It deliberately does not sleep, does not wait, and does not make technical decisions. prompts/004 states it plainly: the main Session does not wait. It is forbidden to sleep, forbidden shell timeouts beyond 30 seconds, forbidden job waits beyond 5 seconds, because one stuck step would delay new candidates. It keeps the model's attention on the highest-level questions, whether to do the work and who should do it, rather than drowning it in execution detail.

The second layer: Executor Sessions (workers). Each Ticket gets one independent session plus one independent working directory (src/executor/dsh.ts), prefixed worker-. The worker reads the original source, judges the scope, implements, self-tests, opens the PR, and handles follow-up, all unattended. Its toolset excludes tools like ask_user_question and present that would require a human to keep it company.

The inner core: the Engine. Beneath the two agent layers sits a pure domain kernel that depends on no LLM at all, src/core/engine.ts, and this is what "kernel" literally refers to. The Engine is a synchronous, no-I/O rules engine with exclusive write access: it is the sole writer of Trigger, Thread, Decision, Ticket, and Assignment. It maintains the rules for batching, authorization, fan-out, recovery, and the attention lifecycle. The complete picture of the system is this combination of kernel plus two agent layers:

• The Engine governs deterministic rules: who is authorized, how things are judged, how subscriptions fan out, who waits for whom, which stage a Ticket is in.
• The orchestrator governs judgment-based routing: whether to take a job, and to whom.
• The worker governs execution: how to implement, how to deliver.

Human dependence on the system is pressed to a minimum. The Ticket stage table makes "does this need a human" the first classification (person/* versus working/* versus idle), and the model appears only when it should.

2. Event-driven: stripping session management out of interaction

The system "takes over tedious session management and context syncing at the bottom layer." dsh-superagent models its entire operation as immutable events plus a deterministic kernel plus a persistent side-effect queue.

There are three event-driven layers in the implementation:

Domain events (DomainEvents). After every change, the Engine emits events such as trigger.received, ticket.ended, thread.subscribed (src/core/ports.ts). The Runtime converts these into notices or relays for the main Session, that is, context delivered automatically to its door, instead of the agent polling for it or a human relaying it.

The persistent side-effect queue (Effects). src/app/effects.ts is a disk-backed side-effect queue. Anything that is "to be done after a decision" is stored first and executed after: assessment (advance a candidate into the main Session), launch (start a worker), delivery (send an Input to a worker), relay (forward reports or follow-up questions), notice (inject a notification), reply (send a message). Each kind executes asynchronously, with backoff retry, and reports health independently. This queue is the engine room of the event-driven design: commands enqueue inside their own transaction, execution happens after commit, failures retry, and nothing is lost across restarts (the "Stored work" section of 003).

The Passes heartbeat. src/app/passes.ts runs a pass every two seconds, serially kicking due effects and calling Engine.evaluateDue to advance Evals. When a new Trigger, command, or HTTP request arrives, it kicks an extra pass immediately. It carries the system's heartbeat; a Source's Trigger reaches the kernel through it.

The essence here: context synchronization no longer happens inside one interaction turn. A background kernel maintains it continuously. Worker reports, human follow-ups, candidate cards, background task completions all flow back automatically as messages into the main Session's next step ("Relays arriving during a turn are delivered together at its next step"). No human, and not even the main Session itself, needs to remember to sync anything.

3. Asynchronous multi-channel interaction: one judgment, landing in parallel on many channels

"Asynchronous multi-channel interaction" in dsh-superagent is two asymmetric channel groups.

Inbound (people and systems, into the kernel): GitHub (notifications, PRs, issues, comments, CI) and Feishu (real-time events, topics, history, images). Both are translated into unified Trigger plus Thread facts (src/sources/). A Trigger is an immutable event plus Source metadata; it is the unit of audit and idempotency. Accepting the same Trigger twice creates only one Ticket. Many channels are normalized into one domain object, and the backend session management becomes invisible to humans.

Outbound (kernel, out to the world): a Channel is the write side of a Thread. One Ticket holds a set of Channels (acknowledgement, answer, result, attention, each with its own allowed rules; see src/app/outbox.ts, src/app/replies.ts). Outbound messages persist a receipt through the Outbox, which guarantees each message queues exactly once, that messages of the same Ticket to the same conversation go out in strict order, that failures back off and retry, that messages wait while a Source is offline, and that they are discarded with a recorded reason when the conversation no longer exists.

The key design word is "asynchronous." Once work is delivered, the Engine does not block and wait; results flow back asynchronously through replies, PRs, and notifications on each channel. Multi-channel input is unified into the kernel through the SourceScope of the SourceRegistry, so adding a new Source is plug-in-like and the kernel's domain model does not bloat because of it.

4. Storage-compute separation: "who executes" inside the domain, "how to execute" outside the host

Storage-compute separation is a very deliberate design line in dsh-superagent, so deliberate that it is written into the domain model's table of rejected concepts:

Unpacked concretely:

Storage. The Store exclusively owns one SQLite database and provides, with transactional semantics, the domain repositories, read-only queries, Source metadata, settings, Outbox receipts, and key-value records. At startup the Runtime acquires a directory lock before opening, preventing two processes from writing the same state.

Compute. The DshExecutor (src/executor/dsh.ts) lives outside the domain and connects through an Assignment, the binding of one Ticket to one Executor instance. Executors are swappable: one Ticket can have multiple Assignments, can hand off (be handed to a human), can resume (be continued by a human), and can be executed by several Executors in sequence. All of this holds precisely because Ticket state does not travel with the Session.

The practical payoff of storage-compute separation is recovery. The "Restart" section of docs/003: when the host restarts, the running Assignment ends with "host restarted," and a new Assignment starts carrying a recovery note ("check the directory, the git history, and GitHub before redoing any external action"). Sessions, directories, subscriptions, pending messages, and the record of "which messages each Executor Session ingested into history" are all preserved. Both the consequences of decisions and the basis for them are on disk, so the system is crash-safe.

At the same time, it pulls "who is executing" into the domain (the Assignment is in-domain; 001: "The Executor is outside the domain, but who executes must be inside it") while leaving "how to execute" outside the host. The two sides are decoupled through ports (the ExecutorHost, AssessorHost Pick interfaces in ports.ts).

5. External watchdog: humans are not flooded; they are picked out for attention

The summary phrase "external watchdog" lands in dsh-superagent as two layers, both premised on minimal attention.

Internal care: Passes plus the HealthBoard. Everything that can fail claims exactly one health entry (runtime, evals, models, worker, every effect kind, every Source, sync:), with one writer per state (007: "one writer per state"). A failure becomes a "system problem" only after three consecutive failures; one-off network jitter does not alarm. Noise itself is filtered out as an attention cost.

External care: the web panel (src/client/, 005). This is the watchdog for humans, and it answers only three questions, in this order:

1. What needs me right now? (The Overview first screen: Tickets that need a human, and system problems.)
2. Is the system healthy and doing the right things? What is the history of one specific piece of work (Trigger to Eval to Ticket)?

The panel's principle is "quiet by default." Health states take no space; only what needs a human and is actionable appears. docs/005: "Focus on what matters." Every element must answer one of the three questions, or it is deleted. That is the difference between a watchdog and a dashboard: it does not display everything; it picks out where human attention should land.

Worth noting as well: attention itself is modeled as a domain concept. In docs/003, Attention (a pending human decision) is a domain object. A worker raises one single, clearly structured question through human_action and hands it to the main Session, instead of burying it inside a long report; the main Session asks the human through a named message, in the most suitable place. Even "which question reaches which human" is not wasted on the wrong channel.

6. Typical scenarios: weaving the five pillars into one thread

Scenario A: autonomous progress inside a team chat (multi-channel plus event-driven)

A team member @-mentions the agent in a Feishu group. The Feishu Source translates this into a Trigger plus Thread and drops it into the Engine. The Gate judges "person on the list, explicitly @-mentions me," an explicit request, and accepts it directly with no evaluation. In one transaction the Engine atomically creates the Ticket, Mandate, Assignment, Subscription, and acknowledgement. None of this blocks any human: the acknowledgement returns to Feishu asynchronously through the Outbox, and the launch queues the worker through the Effects.

The worker works in its own directory and its progress disturbs no one. Midway, when the one decision it needs arrives, human_action raises one question, relayed to the main Session and delivered into the Feishu group. The human answers in one sentence; through the Subscription fan-out the answer returns to the Ticket and wakes the worker to continue. In the end the worker opens a PR and reports ready; the Ticket closes on merge. Later, someone asks a follow-up in the group; the Subscription resumes the original Ticket, same Mandate, no new Eval, no new Decision. The human appears exactly three times over the whole arc: stating the need, answering the decision, and accepting the result.

Scenario B: unattended, rule-driven work (dual layer plus storage-compute separation)

The team observes in observe mode, then switches to auto and configures rules. An event from someone not on the list, or from a bot, becomes an inferred candidate. The main Session evaluates it with orchestrator_eval; with a matching rule plus intent evidence it accepts, and the Mandate records the matched rule, the Policy version, the sender, and how it was received. This Ticket's worker operates under a narrower authorization boundary (the matched-rule restriction). On this basis the system takes on concrete work without per-item human confirmation, yet every step remains on the record, reviewable in the panel, and stoppable by a human at any point. Autonomous without running out of control, all because the kernel solidifies authorization into an immutable Mandate that can be revalidated.

Scenario C: seamless continuation after a crash or restart (event-driven plus storage-compute separation)

A worker is mid-run when the host restarts. At startup, Passes and Effects recover: the running Assignment ends with "host restarted," and a new one starts with a recovery note ("check the directory, the git history, and GitHub before redoing any external action"). Pending messages, notifications, subscriptions, and read positions are all preserved. The reliability of forced dependencies comes from decisions being persisted before execution, and from Ticket state being independent of Session state. This is exactly what the two pillars, event-driven and storage-compute separation, jointly guarantee.

Scenario D: attention leverage (external watchdog)

At a given moment the system holds 20 Tickets, 3 Sources reporting errors, and 1 expired Eval. The panel's Overview shows only the items that need a human: 1 PR awaiting review, 1 question awaiting an answer, 1 unavailable Eval. The remaining 17 work silently, off-screen. evalsHealth alarms only when something is "still undecided for the past hour," and stays quiet otherwise. The human is not crushed by 20 things; they are reminded only of the 3 that need them. That is attention as the first resource, landed: the system has already performed the attention triage for the human.

7. Three iron laws of the kernel (distilled)

Compressing the design above into the kernel's real character:

1. One writer per state. Every class of state has exactly one writer; everyone else reads it or asks it to write. This eliminates most concurrency and consistency problems, and it makes recovery simple and provable.
2. Stored, then done. Anything that follows a decision is persisted before it is executed; failures retry with backoff, restarts lose nothing. Transactional semantics plus the side-effect queue carry the crash-safety.
3. Attention is the budget. If a default value can replace a toggle, no toggle. If one sentence can explain it, no paragraph. Health states take no space. Agents speak only when it is time to speak, and act only when it is time to act. Every design decision eventually returns to that one sentence.

8. Conclusion: from "chat window" to "continuously online autonomous collaborator"

The reason an agent can evolve "from a passive, instruction-awaiting chat window into a continuously online autonomous collaborator in a digital environment" is not that the model got stronger. It is that the limbs (dual-layer execution) and the nerves (event-driven processing) are seated on a skeleton (the kernel) that treats attention as the first resource:

• Dual-layer architecture separates judgment from execution; humans see only top-level decisions and acceptance.
• Event-driven processing sinks session management and context syncing into a background kernel; interaction moves from turn-based to continuous.
• Async multi-channel means one judgment landing on many ends; humans are not bound to any one channel.
• Storage-compute separation decouples state from execution: hot-swappable, restartable, recoverable.
• The external watchdog triages "where human attention should land" as a first-class concern.

For an individual, it is a cross-device, cross-platform personal assistant handling daily affairs (many Sources plus continuous context). For a team, it merges into the development workflow (GitHub PRs plus Feishu groups), takes on and advances concrete tasks (Subscriptions plus the Ticket lifecycle), and leaves the higher-level questions, whether to do the work and how to accept it, to the team. This prototype is validating exactly that: as model capability and the underlying system architecture evolve together, this more autonomous way of working has a shot at becoming the norm for human-machine collaboration, and at the kernel level dsh-superagent has already taken the hardest part, making autonomous collaboration happen without consuming the team's attention, to a level that is implementable, recoverable, and observable.

DeepSeek V4 Hub is not affiliated with DeepSeek. dsh-superagent and its repository are the project's own; this scenario analysis of the kernel is editorial. File paths and quoted strings reference the public research prototype for technical accuracy.