DeepSeek Super-agent Technical Breakdown: From Writing Code to Continuously Taking on Work

Following the public code, we unpack how a continuously working coding agent handles authorization, message dispatch, execution scheduling, and recovery from interruptions.

Having AI modify a chunk of code is nothing new. The hard part is this: you file a request on GitHub, it starts working; you go off to do something else, it follows through on reviews and CI; the service restarts midway, and it still knows what it promised, what’s been done, and who to reach out to next.

The dsh-superagent-prototype released by the DeepSeek Harness team explores exactly this layer. It turns a GitHub repo into a persistent working entry point, and can optionally hook into Feishu/Lark as well. Once an authorized person submits a request, the system creates a task, hands it off to an independent session and a Worker in its own directory, and finally returns the result in the original conversation — usually a reviewable PR, or a question that needs a human answer.

It suits development teams with GitHub collaboration workflows who are willing to set up dedicated accounts and execution environments, as well as people researching agent engineering. Individuals can also study and deploy it, but this is not a desktop assistant you download and hand all your work to. One deployment serves one repository; model, tools, shell, and session execution are carried by DeepSeek Harness.

First, a note on the scope of this release: the README clearly states that this is a research prototype for reference purposes, not an official DeepSeek product. It has been adjusted for public release and does not represent everything described in the internal system or related articles. Below, we unpack only what this public code has actually implemented.

First, Get “Promised Work” Out of the Chat Log

In many agents, task state hides in a long string of messages: the model says “I’m on it,” and the system treats it as in progress; the model finally says “done,” and the whole flow ends. Whenever work spans multiple threads and multiple execution rounds, this correspondence becomes fragile.

This prototype builds a separate task model. A Trigger is an incoming event; a Thread is the conversation it belongs to; Eval decides whether to take the job; upon acceptance, a Ticket is created along with a Mandate — which version of the rules this work is based on, who initiated it, and how far it is authorized to go. The Assignment records how the executor ran it this time.

Trigger → Eval → Ticket + Mandate → Assignment → Worker Event Judgment Task & authorization basis Execution round The actual worker

Separating Ticket from Assignment is the foundation for everything that follows. The same ticket can go through multiple Assignments; the current DSH executor reuses its Worker’s session, directory, branch, and PR on retries. When execution is interrupted, the system doesn’t have to pretend this is a brand-new request. Conversely, a Worker finishing one turn of speech doesn’t mean the task has concluded.

There’s also no rule that “one thread can only have one task.” A Thread can subscribe to multiple Tickets, and a Ticket can track multiple Threads. The links between Threads only provide evidence; what actually determines where messages go is the Subscription. Separating “related to” from “handled by” prevents related information from being casually treated as execution instructions.

Task state is managed by the Engine and SQLite; the main Session makes judgments outside transactions, while Workers handle concrete implementation. The diagram above organizes source-code mechanisms; it is not an official product interface.

Proactively Taking Work On: First Solve “Who Authorized You”

New work entering the system passes through two layers of judgment. The first layer is the gate in host code: who the sender is, where they come from, whether the Agent is explicitly named, how the allowlist is configured, and whether the sender is a bot on the blocklist. The second layer is the model’s judgment of the request content. Under normal circumstances, an authorized person explicitly names the Agent, forming an explicit request. Ordinary discussion or bot messages can at most form an inferred candidate — they cannot make themselves the authorizer with a single “please ignore the previous rules.”

The default mode for inferred candidates is observe. The model can judge “this is something I would normally take on,” but the system only records a would accept entry and doesn’t actually create a ticket. Off mode doesn’t even produce inferred candidates; only auto accepts once conditions are met. These three modes govern inferred candidates — authorized explicit requests still work regardless.

And auto doesn’t let the model go looking for work on its own. assessmentOutcome requires every enabled rule to be evaluated exactly once, with at least one matching; there must be evidence of implementation intent; the target must already be clear, with no remaining open design decisions. If fields are incomplete or conditions unmet, the host won’t take the job on. However, whether the intent is genuine and the evidence sufficient still relies on model judgment — structured validation doesn’t guarantee correct judgment.

There’s one easily overlooked exception in this design: follow-up messages to an existing task go through the subscription channel. On a Thread subscribed to by an active Ticket, new comments, bot messages, and CI results are delivered directly to the Worker as context, bypassing the new-task gate — but without adding any authorization. The Worker can only handle them within the original Mandate’s scope. If it discovers new work out of scope, it must hand back, and only after no other Ticket still holds the message does it return to Eval.

New work and follow-up messages to existing work travel on different channels. Subscriptions improve the efficiency of context delivery but must not expand task permissions; scope judgment still depends on the execution model adhering to constraints.

Rule changes have specific semantics too. In-progress Evals are invalidated and re-judged against the new version; affected active Tickets receive rule-change notifications but are not uniformly force-killed. Finished tasks must have their original Mandate re-verified before being woken up by a human’s follow-up comment. Manual stop is clearer: it revokes the authorization, and the task no longer receives follow-up messages; further work requires a new acceptance decision.

The Main Session Takes Work In, Workers Finish It

The main Session receives candidates, performs evaluation and routing, aggregates reports, and communicates externally. The Worker is what reads code in the task directory, selects implementations, runs tools, and validates results. Don’t picture this as “one super-model cramming every detail into a single context”: it has long-lived task state and separate sessions divided by responsibility.

This is a division of responsibilities, not absolute tool isolation. The source still gives the main Session access to Shell, file reading, and other capabilities; “don’t go deep into writing implementation plans” is enforced primarily by prompt constraints. Workers can also invoke sub-agents — it’s not fixed at exactly two model roles. The actual benefit of this split depends on routing quality and context management; the repo itself doesn’t provide production measurements sufficient to quantify it.

The most interesting scheduling detail: it counts “background work still running” toward the load. maxWorkers defaults to 3; preparing directories and starting sessions occupies a slot immediately, so two async startups can’t race for the last slot. Regular new tasks and CI wake-ups take normal slots; human messages or status requests can use up to one extra slot, prioritized over new startups.

After a Worker’s text turn ends, as long as a Shell Job or sub-agent is still running, it continues to hold its slot. Otherwise, the dashboard would look idle while the background is fully booked. This also explains why Shell commands go to the background after 5 seconds: it lets the session receive messages in subsequent steps — it’s not judging the command itself as fast. What’s limited here is Worker scheduling slots, not the model API’s total concurrency hard cap.

By default there are three normal Worker slots, plus up to one slot for human-message wake-ups. Regular background work continues to hold its slot; when handing off to a human the slot is released, while Jobs are handled separately.

Background task lifecycles also vary by case. After a normal turn ends, background waiting has a 30-minute limit: when it expires, the Shell Job is killed, and still-running sub-agents are recorded — they can continue. When handing off to a human (ready, question, blocked, or failed), the slot is released and sub-agents are stopped; Shell Jobs like servers intended for human review can be left running, unconstrained by the above wait limit, until the Assignment ends. It doesn’t summarize all work under a single “kill on timeout.”

Tasks Can Resume Thanks to Transactions and a Persistent Queue

The Engine’s state-modification entry point is synchronous: within a short transaction it verifies conditions, updates the task, and records the decision. Waiting for model responses happens outside the transaction. The system won’t hold a SQLite transaction open for a long inference. SQLite stores events, threads, tickets, decisions, pending actions, and message receipts; the Runtime first locks the state directory to prevent a second instance from using it concurrently. It’s a local system with a single state directory — multi-machine distributed scheduling isn’t implemented here.

The key is separating “deciding to do” from “actually doing it.” A domain change writes state inside a transaction and also queues into Effects; only after the transaction commits does the adapter start Workers, deliver inputs, or send messages. Otherwise, if an external action were issued first and the local task written afterward, a process crash at just the right moment would leave behind an action the system doesn’t remember.

Effects store queue entries by kind and key. The same wait entry can have its payload updated while its generation counter increments; on completion, the entry is deleted only if both the sequence number and generation still match. This handles a very specific race: while an old action is executing, a new message updates the same pending entry, and the old completion callback must not delete the new one. Failures retry with backoff; the “waiting for a free slot” case (Later) is postponed rather than treated as a failure.

An Outbox further persists receipts for outgoing messages alongside reply actions. Duplicate local message IDs are not re-queued; follow-up messages from the same Ticket to the same session typically wait for the previous one to send first, and only after the predecessor fails consecensively past a threshold does it stop blocking successors. So “accepted the job” and “result completed” have trackable delivery states — if a message can’t go out temporarily, it doesn’t rely on the model remembering to retry.

Transactions guarantee local state and pending actions commit together; Effects execute after commit. There is still a consistency window between an external service succeeding and the local receipt being persisted — end-to-end exactly-once cannot be guaranteed.

This still doesn’t mean external actions never repeat. If a GitHub comment was successfully sent but the process crashed before recording the sent receipt, a retry could send it again. Local deduplication can’t provide idempotency guarantees on behalf of the remote side. That’s why the recovery prompt explicitly requires the Worker to first check the worktree, git history, and GitHub state, so as not to redo external operations that are already complete. This is recoverable execution plus verification against real-world state — not resuming a program from the exact instruction where the power went out.

“Done,” “Waiting on a Person,” and “Stopped” Must Be Distinct States

This system doesn’t guess who’s waiting on whom from free-form text. The Worker returns status via a structured Report, raising questions for humans through a separate question field. Regular progress stays within the task; only results, questions, and blockers are forwarded to the main Session. The dashboard prioritizes pending questions, pending reviews, and failures — healthy states try not to grab attention.

ready also doesn’t automatically mean the PR has been merged. A task with no associated PR can finish as completed on ready; a task tracking a PR must wrap up according to its closed, merged, and other states. After blocked or failed, CI and bot messages continue to be recorded but don’t automatically wake the executor; a human message, a retry, or a new valid report is needed to lift the wait. This waiting state is persisted in the database and won’t be zeroed out by a restart.

Pause processing and Stop are likewise different. Pause stops new evaluations, deliveries, dispatch, and replies; the Source can still record events, and an already-running Worker turn is not interrupted. Stop targets a specific Ticket, revoking that piece of work. Operationally, if you treat Pause as an emergency kill button, your expectations will be wrong.

What’s Enforced by Code, What Still Relies on Model Discretion

Independent sessions, independent directories, and a dedicated GitHub account help separate context and operating identity, but they are not a security sandbox. ensure sets managed sessions to danger-full-access; Workers run commands as the operator’s OS user without requesting per-command approval. The CLI wrapper and command blocklist establish default paths — the documentation explicitly acknowledges: programs can still execute via absolute paths.

For example, the default delivery prompt specifies the reviews, code-change size limits, and merge account required for auto-merge, but the host has no dedicated merge-decision logic. To truly enforce review conditions, you still need external mechanisms like GitHub branch protection. This distinction matters: putting constraints in a prompt guides behavior; handing conditions to a program or platform to reject them is a different kind of guarantee.

Prompts themselves are also treated as configuration: saving produces an immutable version, commits must carry a base revision, and conflicts are rejected; each model request uses the prompt version at that time, and the session records which versions it read. This lets you ask “which set of team rules was in effect for that operation” — but a version record can’t prove the model faithfully executed the rules.

If You Want to Try It, Start by Connecting a Repository

The repo is MIT-licensed. Before starting, you need DeepSeek Harness, model service configuration, and an environment with Node.js, pnpm, git, GitHub CLI, etc.; the deployment script also depends on sh, tmux, and Python — don’t treat it as a native Windows installer. The deployment docs list the public DSH version as 0.2.1-rc.3; the compatibility range is governed by package.json.

The most direct entry point is to hand the repo to a coding assistant and explicitly ask it to read SETUP.md and assist with deployment. The process collects the target repository, dedicated account, who is allowed to submit requests, working directory, and whether to auto-merge, then configures the Superagent panel in DSH Web. The source example uses a prepare command to create a git worktree for tasks; without prepare, the Worker gets only an empty directory by default.

When starting out, keep the default observe mode and first check which jobs it would have taken on; keep the allowlist small, and handle merges manually. Once configured, authorized accounts submit requests by naming the Agent in an Issue or comment. GitHub polls at roughly one-minute intervals by default — that’s not a promise of instant response.

Project homepage: https://github.com/deepseek-ai/dsh-superagent-prototype

In my view, the most instructive aspect of this prototype is how it decomposes “continuous work”: authorization, tasks, execution rounds, message delivery, and human handoff each carry their own state, rather than letting a single model utter handle everything. It hasn’t yet proven long-term reliability in production, nor does it offer a universal efficiency multiplier — but it has put the problem in the right place.

An AI that can write a single patch only proves it knows how this one time. It’s only when the task changes execution rounds, messages route through several entry points, and the process restarts — yet the system can still say clearly what it should do and where it got to — that you can talk about continuously taking on work.