DeepSeek Super-agent: route events to the right task

Separate the design from the public prototype

DeepSeek Harness describes a routing layer that handles interaction and dispatch while separate workers execute tasks. Deterministic checks filter incoming events before model assessment. Once a worker subscribes to a thread, such as a pull request discussion, follow-up events can reach it directly. Subscriptions are many-to-many: a shared thread can concern several workers.^[1]

The English essay used here is a machine-translated republication attributed to the official DeepSeek Harness account, dated November 1. Zhidx's November 1 report places the original Chinese publication on October 31. The essay describes architectural ideas and an internal running instance. Only parts appear in the public research prototype; it is not an official DeepSeek product, and scaling, security and privacy remain open problems.^[1][2]

For your own design, separate four identities: the event that arrived, its conversation thread, the task that owns the goal, and the current execution attempt. A thread provides routing context. It need not correspond to exactly one task. The following record and recovery rules are editorial proposals inspired by the design, rather than verified behavior of the prototype.^[1]

Predict ownership after a duplicate and restart

This static exercise is fictional. Task T17 investigates a parser-test failure on pull request PR42. Its worker already follows that thread. CI event E8 arrives twice. Attempt A1 records a successful reproduction, then the host restarts before it records whether a comment was posted. Before reading on, decide which identities should change and what evidence the next attempt needs.^[1]

Keep task T17 and its thread association. Start attempt A2 under that same task. Account for E8 once, retaining the second delivery as a duplicate observation. Creating another investigation for each delivery would split ownership. In this example, known-thread delivery needs no fresh routing decision; an unrelated request in the same discussion would require explicit reassignment or a separate task.^[1]

A2 first reads the saved reproduction and the last recorded step. It then checks PR42's actual comments, current commit and CI results. If the reproduction comment already exists, record that fact and continue without reposting. If it is absent and the task still permits that action, post once. Ambiguous external state remains unresolved; a missing local success record alone cannot justify repeating the action.^[1]

A filled trace after that check could read: event E8, duplicate observed; thread PR42; task T17; current attempt A2; durable result, parser failure reproduced by A1; external result, reproduction comment found; next step, investigate the recorded failure; human decision, none yet. Each field answers a different recovery question. Recording the fields alone does not enforce correct delivery or prevent duplicate effects.^[1]

Escalate stalled work with one concrete decision

Now suppose A2 repeatedly runs the same reproduction without changing the diagnosis. A live process and fresh log lines establish activity. They provide little evidence of progress. DeepSeek's proposed external watchdog checks substantive progress as well as infrastructure liveness. For this exercise, set a fixed limit on attempts that produce no new evidence, then stop and request a decision at that limit.^[1]

Make the request useful: parser failure reproduced on PR42; reproduction record and current CI linked; repeated attempts added no evidence; choose a different investigation or close T17. Keep the detailed trace available without posting every tool result into chat. DeepSeek recommends short, decision-oriented chat replies. The stopping limit and message here are proposed choices, not a measured recovery policy.^[1]

Turn the trace into a bounded replay plan

Compare four cases before implementing the policy: normal delivery should preserve one task and produce the intended result; duplicate E8 should add no second comment; restart after a comment but before its success record should recover the comment; a genuinely unrelated request should receive separate ownership. Check the final task, attempt history, external-action count and reason for any human interruption. This is a proposed test plan, not an executed benchmark.^[1]

Keep performance claims narrow. DeepSeek's preliminary experiment used about 300 messages and 20 work requests per run, five runs per design, and a simulated time-consuming coding tool. It measured scheduling and coordination, without testing code quality or production engineering speed. The two-level design also consumed more cache-read tokens than the single-session baselines. Neither faster scheduling nor quiet notifications establish a safe execution environment.^[1][2]