DeepSeek Super-agent: Router/Worker Design and Setup

Start a DeepSeek Super-agent trial with one repository, one allowed requester, and a dedicated OS account. Its Router turns authorized requests into Tickets, while Workers use separate sessions and directories. Keep observe enabled initially, but understand that explicit requests can still execute.

As of 2026-11-09, dsh-superagent-prototype is research code, not an official DeepSeek product or production-ready service. Its package manifest declares version 0.1.0 and an MIT license. The public implementation also differs from the team’s internal system and design essay.

What the Router, Ticket, and Worker do

The main change is persistent task intake, rather than another model or a new coding interface. The bundle runs inside DeepSeek Harness, listens to one GitHub repository, and can optionally receive Feishu messages.

The domain model separates incoming events from authorized work. Evaluation, called Eval, decides whether a candidate warrants a new Ticket. Each accepted Ticket carries a Mandate that records its authorization and scope.

The Router is the main agent session that makes routing decisions. The Worker executes the accepted task. Configuration pages call that Worker an Executor.

Each Worker gets its own session and working directory. Results return through the original conversation, such as a GitHub comment containing a pull request. A directory separates checkouts; it does not restrict what the process can read.

For example, two unrelated bug reports can become separate Tickets instead of sharing one coding conversation. This is useful when coordinating incoming work consumes more attention than starting an individual coding task.

For one interactive change, keep your existing coding agent. For bounded delegation, start with read-only Claude Code subagents with explicit model selection.

Why observe mode is not a safety sandbox

observe limits inferred work, not all execution. The authorization rules allow explicit requests in every accept mode.

In observe, positive assessments of inferred candidates become “would accept” records, without creating work from them. In auto, a positive assessment can accept inferred work. An allowed person mentioning the agent can request work in every mode.

The allowed list is not the only admission control. An admission-table cell can also grant explicit authority to unlisted people. Configure the one-requester policy below rather than relying on observe alone.

What danger-full-access means

Use an OS account containing only the agent’s credentials. The deployment guide’s isolation warning applies to both dsh-superagent-router and dsh-superagent-worker: they run as the operator’s OS user with danger-full-access.

Credential wrappers select accounts; they do not isolate processes. Workers can run programs by absolute path and read the operator’s home directory. The implementation guide also gives the Router shell and file-reading tools.

For an initial trial, use a disposable machine or virtual machine with a non-administrator agent account. Keep personal credentials, production secrets, and unrelated repositories out of that environment. These are deployment precautions, not protections supplied by the prototype.

Keep its Harness profile separate too. The plugin changes process-wide PATH and git settings. Leave the panel bound to 127.0.0.1; do not expose this trial as a public web service.

Set up a GitHub-only trial

Use the manual path below on a fresh account and profile. The repository also provides an agent-guided SETUP.md.

Check the prerequisites

Install Node.js 22.19+ or 24+, pnpm, git 2.32+, Python 3.8+, tmux, and GitHub CLI 2.48+. These are the documented prerequisites.

You also need a repository on github.com and a model provider for DeepSeek Harness. GitHub Enterprise Server is not supported. Install git-lfs when the target repository uses Git LFS.

Use a nonempty trial repository containing README.md. Prefer a private repository with only you and the agent for the initial test.

Feishu is optional and outside this trial. Its documented path additionally requires a bot-enabled Feishu or Lark app and lark-cli, tested by the project with 1.0.90.

Sign in only as the agent

Create a dedicated GitHub user account and grant it write access to your trial repository. Run these commands in Bash under the dedicated OS account.

unset GH_TOKEN GITHUB_TOKEN
gh auth login --hostname github.com --git-protocol https
gh api user --jq .login
gh auth setup-git --hostname github.com

Complete GitHub CLI’s interactive login as the agent. The gh api command must show its login. Clearing the two variables prevents environment credentials from overriding the stored login.

The separate gh auth setup-git step configures Git to use GitHub CLI as its credential helper. This matters because preparation and branch pushes use standalone Git.

Create the local clone using the documented GitHub CLI clone syntax:

read -r -p "Repository (owner/name): " TARGET_REPOSITORY
mkdir -p "$HOME/src"
gh repo clone "$TARGET_REPOSITORY" "$HOME/src/superagent-target"

Then check HTTPS access independently of gh api:

GIT_TERMINAL_PROMPT=0 git ls-remote \
  "https://github.com/$TARGET_REPOSITORY.git" HEAD

GIT_TERMINAL_PROMPT=0 git -C "$HOME/src/superagent-target" push --dry-run \
  "https://github.com/$TARGET_REPOSITORY.git" \
  HEAD:refs/heads/agent-auth-check

git ls-remote should return the remote HEAD. On a public repository, that read can succeed anonymously. The push --dry-run check exercises the push connection without updating remote refs. Require both commands to succeed, but keep the later real PR push as the final delivery check.

This example uses gh directly because the entire OS account belongs to the agent. Do not reuse a personal account’s multi-login configuration.

Install a dedicated Harness profile

Use the Harness version pinned in the deployment guide: 0.2.1-rc.3. The bundle’s manifest requires engines.dsh to satisfy ^0.2.1-alpha.2.

Set DSH_HOME before any dsh command. The pinned CLI reference places named profiles under $DSH_HOME/profiles/<name>. Here, $HOME/.dsh is the explicit location chosen for this trial.

The following Bash commands are for a new installation only:

export DSH_HOME="$HOME/.dsh"

npm install -g @deepseek-ai/dsh@0.2.1-rc.3
git clone https://github.com/deepseek-ai/dsh-superagent-prototype.git
cd dsh-superagent-prototype
pnpm install
pnpm build
dsh superagent --from-default-profile web --dump-config > /dev/null
dsh plugin --profile superagent add "link:$PWD"

Do not rerun the profile-creation command for an existing installation. It replaces the profile and deletes its cordis.patch.yml. Follow the deployment guide’s upgrade path instead.

Confirm the profile manifest exists before writing the machine configuration. Continue in the same Bash shell:

test -f "$DSH_HOME/profiles/superagent/package.json" || exit 1

cat > "$DSH_HOME/profiles/superagent/cordis.patch.yml" <<EOF
- id: webserver
  config:
    host: 127.0.0.1
    port: 3082
- id: dsh-superagent
  config:
    stateDir: "$DSH_HOME/state/superagent"
EOF

if tmux list-sessions >/dev/null 2>&1; then
  tmux set-environment -g DSH_HOME "$DSH_HOME"
  if tmux has-session -t '=dsh-superagent' 2>/dev/null; then
    tmux set-environment -t '=dsh-superagent' DSH_HOME "$DSH_HOME"
  fi
fi

scripts/dsh-superagent start
scripts/dsh-superagent status

The service script launches dsh --profile superagent through tmux. A new tmux server inherits the exported environment. The block also updates an existing server or session’s tmux environment.

Open http://127.0.0.1:3082 in a browser on the server machine. In Harness Settings, Open configuration file should open the superagent/cordis.patch.yml path above. Stop if it points elsewhere. Do not overwrite that patch again after adding provider settings.

Select Superagent in the sidebar. An initial setup warning is expected until repository and account settings are complete. Before configuring intake, complete the model-selection section below.

Configure intake and per-Ticket worktrees

Use Superagent → Settings and its documented groups.

In Sources → GitHub, set the repository to your owner/name and the agent CLI to gh. Leave the receive-all switches for Issues, pull requests, comments, and default-branch CI off. Keep Feishu disabled.

In Eval → On each Source → GitHub, make GitHub accounts that may originate work contain only your human login. Remove any other entries and leave the bot list empty. Set every visible unlisted-person admission cell to ignore, including those for people addressing the agent. Save with accept mode observe.

These unlisted-person defaults are defined in the admission matrix. They restrict new work requests; they do not prevent messages in subscribed discussions from reaching existing Tickets as context. Keep the trial conversation limited to you and the agent.

In Execution, start with concurrency 1 as a trial setting. Keep the default directory root. Paste this into the prepare-command field; it runs under sh, and its syntax is also valid in Bash.

git -C "$HOME/src/superagent-target" fetch --no-tags \
  "https://github.com/$DSH_SUPERAGENT_GITHUB_REPOSITORY.git" \
  "${DSH_SUPERAGENT_GITHUB_PR_HEAD:-HEAD}:refs/dsh-superagent/$DSH_SUPERAGENT_TICKET" &&
git -C "$HOME/src/superagent-target" worktree add \
  -b "agent/$DSH_SUPERAGENT_NAME" \
  "$DSH_SUPERAGENT_DIR" \
  "refs/dsh-superagent/$DSH_SUPERAGENT_TICKET"

This adapts the deployment guide’s worktree recipe to the clone created above. It fetches the relevant head and creates the Ticket’s branch and checkout. Without a prepare command, the Worker starts in an empty directory.

In Prompts, set the agent’s commit identity and disclosure text. Require human merging, and do not supply a separate merge account. Prompt instructions are guidance, not enforced repository protection.

Can you use another model?

Yes, through DeepSeek Harness’s configured providers. The provider guide at tag dsh-v0.2.1-rc.3 documents the following path for the installed version.

Open Harness Settings → Models. Enter and save the DeepSeek card’s API key, or choose Add model provider for another supported provider. Enter credentials locally in that UI, not in a GitHub discussion.

For Custom model API, supply a lowercase Provider ID, base URL, matching API protocol, credential, and at least one model. Use your provider’s documented values. Saving a provider does not prove that its model can perform the required tool calls.

Next, use Choose workspace to add and select $HOME/src/superagent-target, following the pinned Web UI guide. Start an ordinary session and select a configured model in its model picker. That selection sets the default for new sessions.

Open a second new session and confirm it shows the same provider and model before sending a request. Ask it to read README.md and return its first heading without edits. Compare the answer with the file. Do not use either managed dsh-superagent-* preset for this test.

Then explicitly select that tested provider and model in Superagent → Settings → Eval and Execution. Eval supplies the Router/assessment model; Execution supplies the Worker model. This trial does not rely on an unconfirmed fallback. Leaving either override unset is appropriate only after verifying the profile default.

The Executor selection applies when a session is created. Existing Worker sessions keep their model, and Retry reuses the same session. Verify a later model change with a new Ticket.

Verify one request and diagnose the failure point

Verify a complete GitHub request and reply before asking for a code change. A running panel alone does not establish that authorization, preparation, and model calls work.

First, rerun scripts/dsh-superagent status. Require exit code 0 and no setup problem. Post a new issue comment from the allowed human account, replacing @AGENT_LOGIN with the agent’s login:

@AGENT_LOGIN Read README.md and reply here with its first heading.
Do not edit files, push a branch, or open a pull request.

The deployment guide’s trial procedure places the resulting Ticket in Overview. Require the correct heading in a reply to the original GitHub conversation.

After that succeeds, request one small documentation change and a pull request for human review. Confirm the branch was actually pushed, the PR belongs to the agent account, and the diff stays within scope. These are acceptance checks, not promised model outcomes.

For a missing Ticket, check the allowed login, admission cells, repository, and GitHub Source health. Then post a fresh comment mentioning the agent.

For service failures, the service script returns 1 for process/runtime problems, 2 for component errors, and 3 for incomplete setup. A restart may help with 1; fix the reported cause for 2 or 3.

For transient model or network failures, the execution guide specifies three retries with increasing backoff. These include HTTP 408, 429, and 5xx. Failed prepare commands are excluded from that automatic retry.

Recover a failed prepare command

Inspect the recorded preparation error and the Ticket directory before selecting Retry. The launch implementation runs preparation only when that directory does not exist. An existing directory is treated as prepared, even if it contains incomplete work.

When the directory is absent, correct the credential or prepare-command problem, then select Retry. The new launch attempts preparation again.

When the directory exists, copy its path from the Ticket’s details and inspect it in Bash:

read -r -p "Ticket directory (absolute path): " TICKET_DIR
git -C "$TICKET_DIR" rev-parse --show-toplevel
git -C "$TICKET_DIR" status --short --branch

The reported top-level directory must be the Ticket directory, not a parent checkout. Check the branch and working-tree status, expected files, and every preparation step that previously failed.

Retry an existing directory only after you have completed and verified its preparation. Retry does not rebuild it. For an incomplete checkout you cannot safely restore, preserve it, stop that Ticket, fix the command, and submit a new issue request. Confirm the replacement Ticket uses a new directory before continuing.

Once a Ticket has failed, CI and bot messages do not wake its Worker. A person must intervene. Stop the trial service when finished:

scripts/dsh-superagent stop

When to keep it running

Keep the prototype only when its routing decisions and delivered changes justify the operational work. Start narrow and increase concurrency only after measuring useful output and provider usage.

Compare cost per accepted change, not model price alone. Include routing, assessment, Worker calls, and recovery in your trial budget. The coding-agent cost-per-task guide provides a framework for comparing a model together with its harness.

Do not equate an internal demonstration with this checkout. The repository warns that some designs from the broader essay are not implemented. Keep the deployment human-reviewed and isolated until your own acceptance checks support a wider rollout.