dsh-superagent

Research checked 6 November 2026. Publisher claims and third-party trials are identified separately; this page is not an AIDreamHub hands-on benchmark.

Read the prototype label literally

dsh-superagent-prototype is published in the deepseek-ai organisation but explicitly says it is not an official DeepSeek product or production-ready software. It is a repository-focused bundle for DeepSeek Harness that turns allowed GitHub—and optional Feishu—requests into work items and agent sessions.

It is interesting for a team that wants a persistent intake, execution and reporting workflow around one repository. It is not a new foundation model or permission to let a bot act on every issue. The public code also differs from internal use and from some ideas in the accompanying design discussion.

Official project page captured by AIDreamHub; not a locally run product.

A request is not the same as ambient context

The authorisation design distinguishes explicit requests, inferred candidates, tickets and mandates. Messages in related threads may be context without granting authority. The default observe mode assesses inferred work but records what it would accept instead of accepting it; explicit allowed requests can still proceed.

That distinction is useful when CI, reviewers and chat bots all speak in the same place. Start with a narrow allow-list and specific repository scope. An automated reviewer should not acquire authority merely because its comment looks like an instruction. Rules and merge approvals need to be operational controls, not optimistic descriptions of autonomy.

How to use: follow the interactive setup, not a pasted secret file

The README directs an existing coding agent to read SETUP.md and set it up with the operator. The setup covers DSH installation, repository access, agent identity, CLI wrappers, optional Feishu credentials, policy and execution preparation. Review that plan before permitting installs or account changes.

The operator must handle account authentication and repository invitations. Keep credentials out of prompts and commits. For the first trial, leave proactive acceptance in observe mode and automatic merging off, then submit a small request from an allowed account. The commands below are inspection/status entry points, not a complete unattended installer.

git clone https://github.com/deepseek-ai/dsh-superagent-prototype.git
cd dsh-superagent-prototype
git show HEAD:SETUP.md

# After completing SETUP.md with the operator:
scripts/dsh-superagent status

Track work and evidence through delivery

A ticket should have an authorised requester, bounded task, prepared working directory, execution record and an outcome returned to its source conversation. A web panel exposes work requiring attention. The repo provides pnpm check for typechecking, tests and build; passing those checks on the prototype is not proof that every generated pull request is correct.

An illustrative pilot is one documentation fix followed by a small bug with an existing regression test. Require the failing test before the change and a passing result after it. A completed agent message should be compared with repository state and CI, not accepted as evidence of a merged or deployed result.

What to reject in a team deployment

Reject requests from outside the configured authority boundary, changes to protected paths without approval, hidden dependency installation and self-approved merges. Confirm that a person’s stop prevents further work and that changed policy is respected before resuming a ticket.

Use the documented authorisation table as a test specification: check explicit and inferred requests separately, then repeat a stopped task after changing policy. These are proposed acceptance tests rather than deployment results. The public state machine is the useful evidence here; no independent reliability benchmark is established.

Compare workflow depth, not a PR screenshot

A normal coding agent fits a developer actively supervising one task. A deterministic GitHub Action fits fixed checks and transformations. dsh-superagent explores the persistent coordination layer between requests, policy and sessions; that layer also creates operational duties.

A useful service would provide scoped deployment, upgrades, credential rotation, alerting and tested rollback. Describe those costs separately from MIT-licensed code. Do not advertise a fully autonomous team replacement on the strength of a prototype demonstration.

License and responsible expectations

The repository is MIT-licensed. Model access, hosting, DSH dependencies and integration accounts remain separate concerns. Using a dedicated agent account does not remove the operator’s responsibility for its comments, commits and pull requests.

Keep the research label in the page and procurement brief. The hand drawing explains a permission gate around repository work; it is not a screenshot of a tested installation.

Questions before adoption

Is this an official DeepSeek service?

No. The repository explicitly calls it a research prototype for reference, not an official DeepSeek product or production-ready software. The public release differs from internal implementations and may omit ideas discussed in the design article.

Does observe mode block all tasks?

No. It prevents inferred candidates from becoming proactively accepted work while recording assessments. Explicit requests that meet the configured authority rules can still work. Review the admission table and requester policy rather than interpreting observe as a total execution shutdown.

Should I enable automatic merge immediately?

The setup defaults to people merging until the agent’s work has earned trust. Begin with a limited account, a small task and CI evidence. Merge rights and approvals are separate from a successful agent response or an attractive PR example.

Sources reviewed

• dsh-superagent — README
• dsh-superagent — interactive operator setup
• dsh-superagent — authorization state machine

Explore related tools

• AI agents
• Coding tools