Inside DeepSeek’s dsh-superagent: Coding Work That Outlives the Chat

A coding agent can open a pull request and still leave its human operator doing the coordination: remembering the original request, watching CI, finding the right session when a reviewer comments, and deciding whether the work is actually finished. DeepSeek’s dsh-superagent prototype puts that coordination into a system of its own.

The project watches one GitHub repository, optionally takes requests through Feishu, and gives accepted work a durable record, a worker session and a working directory. Results return to the conversation where the request began. A later review comment can continue the same work instead of requiring someone to reconstruct the conversation in a new chat.

That is the proposition worth examining. This is not a new DeepSeek model, and the repository does not establish that it writes better code than another coding agent. It exposes an approach to making coding work persist around model calls, with explicit decisions about who can initiate it, when it resumes and where a person must intervene.

A public prototype, not an official product

The repository README (opens in new tab) leads with a warning: this is a research prototype for reference, not an official DeepSeek product or production-ready software. The team says it grew from its daily development work, with much of the engineering done by coding agents.

It also says the published implementation was adapted for release. It is not identical to the internal version or to everything described in the accompanying Exploring Super-agent Design essay. Some of that essay’s designs are future directions, not implemented features.

The public repository was created on October 31, 2026. This examination follows commit 6337fc8, the source snapshot available on November 1. Its package manifest (opens in new tab) identifies a DeepSeek Harness bundle, version 0.1.0; the source is MIT-licensed (opens in new tab). GitHub returned no published releases or tags at that check. The version in a manifest should not be confused with a tested, packaged production release.

The work item survives the session’s turn

The central object is a Ticket: a unit of authorized work. It is separate from the session doing the work and from the particular attempt to run that session.

The domain model (opens in new tab) starts with Sources, such as GitHub or Feishu. They turn outside events into immutable Triggers, organized into Threads. An evaluation decides whether a trigger should create work. Acceptance produces a Ticket and a Mandate recording its scope, authorization strength, policy version and originating identity.

An Assignment then connects the Ticket to an Executor. The distinction is useful when something breaks: replacing an execution attempt does not have to replace the request, its authorization or its discussion history.

A Ticket can subscribe to several Threads, and a Thread can have several Tickets. A pull request and the issue that prompted it can therefore remain connected to one piece of work, while a conversation containing two independent requests need not become one oversized task. Related Threads can also supply context without granting authority.

This is more consequential than simply running several agents at once. The system has to remember which work owns a message and which authorization continues to apply after the original model turn has ended.

Following a request from issue to review

Consider a maintainer asking the agent to fix a reproducible bug. This is an illustrative walkthrough of the documented workflow, not a task executed for this article.

The GitHub Source receives the request and identifies its actor and conversation. Under the ordinary explicit-request path, the sender must be allowed and address the agent. The main routing session can accept the request, creating a scoped Ticket rather than immediately passing an arbitrary comment to a shell.

The Ticket receives its own worker session and directory. A configured preparation command can create a Git worktree; without one, the worker starts in an empty directory. The agent can investigate, change code and produce a pull request under its configured GitHub account.

The important part comes after that first delivery. When the worker reports its pull request, the application checks that it is the originating PR or an agent-authored PR from that Ticket’s branch, then subscribes the Ticket to its discussion. The GitHub Source can also discover a matching agent PR. Review or CI activity can then reach the existing worker. A person asking for a revision does not necessarily need to mention the agent again; the worker decides whether the follow-up belongs within the existing scope or needs separate routing.

A ready report with a pull request means awaiting review, not that the change has merged. Under the execution rules (opens in new tab), a Ticket that opened PRs ends when none of its own remain open; if it opened none, every PR it follows must close. Closure still cannot end acknowledged follow-up work that remains unfinished. An ended Ticket that was not stopped by a person retains its subscriptions, so a later human comment on one of its own Threads can resume it, subject to its Mandate remaining valid. Bots and CI do not wake an ended Ticket by themselves.

The effect is a work record that can span implementation, review and a later correction. Whether the worker makes a good correction remains a model-and-tool question; preserving the relationship between those events is the prototype’s coordination job.

Proactive work starts in observation mode

“Proactive” does not mean the default installation accepts every issue it sees.

The authorization documentation (opens in new tab) separates a deterministic admission gate from model assessment. The gate evaluates the sender and receiving scope. A model then judges inferred candidates against the team’s enabled rules.

Three modes govern that inferred work:

• off prevents inferred candidates from being admitted.
• observe, the default, records positive assessments as “would accept” without accepting the work.
• auto permits a positive assessment to create a Ticket.

Explicit requests work in every mode. Switching to off is therefore not a universal shutdown switch.

Observation mode gives an operator something concrete to review before delegating proactive work: which discussions the agent would have acted on and which rule justified each decision. An inferred acceptance requires a matching enabled rule, rather than the model deciding that something seems useful in the abstract.

The admission table can also deliberately open a scope to requests from people outside the allowed list. For example, a team can allow anyone mentioning the bot in a designated support conversation to make an explicit request. Describing the system as “allowlisted users only” would miss that configurable behavior.

Context can continue without carrying new permission

An initial authorization check is insufficient for a system that keeps reading conversations.

Messages on subscribed Threads reach their Tickets as context without passing through the admission gate again. That includes bot and CI messages. Human follow-ups can belong to an existing worker rather than receive a fresh evaluation. The design’s intended boundary is the existing Mandate: new context is not permission to widen the work.

This makes the worker’s scope judgment important. A comment asking for a small correction and one asking for an unrelated change can arrive through the same subscription. The worker is instructed to handle the former and hand back the latter. An ended, non-stopped Ticket can also resume from a human message regardless of that follow-up sender, provided the original Mandate passes revalidation.

Policy changes have another subtle limit. They invalidate running evaluations and notify affected live Tickets, but do not immediately revoke every active Mandate. Revalidation applies before an ended Ticket resumes. Removing a rule or changing a sender’s eligibility is not equivalent to interrupting every action already underway.

There is a similar distinction between stopping and pausing. A “stop” message in a conversation still passes through admission and routing, and must have explicit strength to stop a Ticket; the panel’s Stop command acts directly on it. A human stop withdraws the Mandate and prevents subscription-based resumption, but does not roll back actions already performed. Pausing processing suspends dispatch and delivery without interrupting an already running worker turn.

Separate directories are not security sandboxes

The sharpest operational warning is in the project’s own documentation: workers execute commands without approval as the operator’s operating-system user.

The deployment guide (opens in new tab) says both routing and worker presets use danger-full-access. A worker can read that user’s home directory and execute programs by path. The recommended isolation measure is a dedicated OS account containing only the agent’s credentials.

The project does make an effort to avoid accidental account crossover. Its environment implementation (opens in new tab) removes ambient GitHub token variables, clears inherited Git repository-location overrides, and configures Git and command wrappers around the agent’s identity. But wrappers and blocked command names establish defaults, not an OS-enforced containment boundary.

That distinction matters when a worker reads repository text, comments and other potentially hostile material. A deterministic rule about who may originate a Ticket does not prove that a model handling its context will resist prompt injection. Nor does it limit every action an unrestricted subprocess could perform.

The agent account’s access is an independent control. GitHub’s token documentation (opens in new tab) explains that a token cannot grant capabilities its owner lacks. Keeping that account’s repository access narrow limits what its credentials can authorize, without making the worker’s filesystem private.

OWASP’s excessive-agency guidance (opens in new tab) identifies excessive functionality, permissions and autonomy as separate risks. Here, meaningful external safeguards include the agent account’s actual repository permissions, the host account’s access and protected merge rules. They should not be replaced by confidence in the worker’s prompt.

A merge rule in a prompt is still a prompt

The same distinction applies at delivery.

The default delivery instructions (opens in new tab) describe conditional auto-merging: the pull request must have been opened for the Ticket, be ready, contain fewer than 200 added-plus-deleted lines, and have every approval required by the standing instructions cover its head commit. User-visible changes also require those instructions to name an approver whose approval covers the commit. They require another account’s configured merge CLI rather than enabling auto-merge as the agent account. Without that arrangement, people merge the pull request.

Those are instructions to the agent. The execution documentation explicitly says the host has no merge-specific decision logic and recommends branch protection with stale-approval dismissal for enforcement.

The line-count condition is consequently not a hard security limit, and required approval text is not equivalent to GitHub refusing an unauthorized merge. This is a prototype in which some boundaries live in deterministic application code and others live in instructions to a model. Operators need to know which is which.

Recovery is part of the architecture

A persistent agent needs a useful answer to “what happens if it crashes?”

The execution design stores work before carrying it out, including launching an Assignment and delivering inputs or outgoing messages. Delivery failures receive backoff. Messages to the same conversation wait behind an earlier message from that Ticket until it has failed three times; later messages may then proceed while the failed one remains visible as a problem. Retries reuse the worker’s session, directory, branch and pull request rather than inventing a new task.

The application’s persistence layer (opens in new tab) uses local SQLite for domain records, pending effects and outgoing-message receipts, while Harness persists session history separately. This is also an operational obligation: the prototype does not yet delete old event, decision, ticket and receipt records, so retained state grows without bound.

After a host restart, interrupted work receives a recovery note instructing the worker to inspect its directory, Git history and GitHub before repeating outside actions. This is a recovery mechanism, not proof of exactly-once external effects: an action can succeed outside the process before its local acknowledgement is recorded.

Background jobs also affect scheduling. A worker with outstanding work retains its slot rather than appearing idle because a conversational turn ended. Human follow-ups can use an extra slot beyond the normal concurrency limit, so a queue of fresh tasks need not prevent someone continuing existing work.

These mechanisms show how the prototype handles long-running work, delayed input and handoff. They are implementation details, not measurements of successful coding work.

What the preliminary experiments establish

An English translation of the team’s design essay (opens in new tab) describes preliminary synthetic scheduling experiments comparing the two-layer design with single-session delegation, plus a separate router-batching stress test. Coding work in the end-to-end experiment was replaced with a tool that consumed time; the router stress test used mock workers.

Those experiments address coordination under an artificial workload, not whether the agent fixes real bugs correctly. The translation also describes a trade-off: multiple sessions consumed more cache-read tokens than the single-session approach, while removing direct delivery increased router overhead without materially changing completion times in that workload. The design should not be sold as an unconditional token-saving technique.

These are reported results from the translated essay, not an independently replicated benchmark of the adapted public snapshot. They do not establish production success rates, coding quality or cost per resolved issue. Nor should the essay’s broader architecture be mistaken for this release: its distributed execution and semantic Watchdog ideas go beyond what the pinned public implementation supplies. The public deployment guide instead gives a separate-profile hourly status-check recipe.

The operator still has a job

The project’s panel (opens in new tab) prioritizes Tickets awaiting a person, then system problems and history. It exposes why work was accepted, what scope it carries, which inputs are waiting and which execution attempts have occurred.

That follows the project’s stated philosophy (opens in new tab): minimize attention cost, communicate when someone can use a result or must make a decision, and do not generate mass pull requests simply to produce volume. These are design goals and behavioral instructions, not measured productivity results.

Deployment is correspondingly more involved than connecting an issue webhook. The guide calls for a separate DeepSeek Harness profile, a dedicated GitHub user account with repository write access, an isolated CLI configuration and optional Feishu credentials. It uses a user account rather than a GitHub App because it reads that account’s notifications. GitHub polling defaults to 60 seconds and respects a longer interval requested by GitHub; broader repository-wide observation switches start off. Its documented installation pins Harness 0.2.1-rc.3; the bundle manifest specifies its own compatibility requirements.

The model is configured through Harness, with separate assessment and worker selections available. This is orchestration around a model provider, not evidence that a new proprietary DeepSeek model is required. Costs will depend on those model choices, the work accepted, context growth and repeated attempts. Synthetic scheduling results are not a substitute for measuring those costs and outcomes on a team’s own repository.

For a team considering evaluation, the useful first question is narrow: can the system carry one low-risk request through a correction and review cycle while keeping its scope, identity and history intact? Begin with observed proactive decisions and manual merging, then inspect both the patch and the coordination around it.

The prototype’s contribution is making that coordination inspectable. Whether it saves attention without creating additional review and security work is the result a deployment still has to demonstrate.