DeepSeek dsh-superagent: Repository-specific tasks, explicit permission boundaries

1. Working in one repository and calling on people through a web panel

dsh-superagent is a package for DeepSeek Harness, an agent execution platform. It receives requests from GitHub and optionally connects to the collaboration tool Feishu. Each task gets its own conversation session and folder. Results are returned through methods such as pull requests, which request reviews of code changes. A web panel collects items requiring human responses or review.

To install it, ask a coding agent to read the repository's SETUP.md and help with setup. The agent asks questions one at a time and shows the full plan before installing and configuring it. Teams can define whose requests to accept and the rules for starting tasks.

2. Allowlists and rules control task initiation

Permission to start tasks and their allowed scope depend on allowlists, rules, and per-task authorization records managed by the agent's host system. Comments are task material, while the allowlist acts as an entry register. An allowed person mentioning the agent constitutes an explicit request. Mentions from people outside the list can also be explicitly allowed through conversation-scope settings. Messages from other people or registered bots become review candidates or are ignored, depending on the settings.

Conversations for tasks already underway can reach the worker through a separate route. This adds context but does not expand permissions. The worker handles requests within its assigned scope or sends back out-of-scope requests. Bot messages and automated check results can provide context for existing tasks, but do not reactivate completed tasks.

3. Evaluation mode and team rules govern automatic initiation

Rule-based autonomous work starts with observation by default. The default mode records candidate evaluations without automatically starting tasks. Teams can review the records before switching to automatic mode. Explicitly authorized requests are handled in either mode.

Approving a candidate in automatic mode requires evaluating each enabled rule and matching at least one. Rules determine both whether to start and how to work. For example, review rules can specify the reviewers and approvals needed before merging code. Candidates clearly outside the rules, such as unrelated conversations, can be ignored without detailed evaluation.

Policy versions include rules, the automatic initiation mode, and source-specific policies. Policy changes requeue ongoing evaluations and notify affected tasks. A policy change alone does not immediately revoke permissions for tasks already underway. However, completed tasks are checked against current policy before resuming.

4. Tasks run in separate sessions and resume under specific conditions

Each task uses a dedicated session and folder. If the folder does not yet exist, a configured preparation command runs once. The command has a 10-minute limit. A common setup creates a checkout using git worktree, a Git feature for separate working directories. Without a preparation command, the task starts in an empty folder.

Internally, requests pass through policy checks and evaluation before task execution. The following reproduces the first 10 lines of the original architecture diagram.

flowchart TB
  plugins[Source plugins] -->|SourceContext| engine
  tools[Session tools] --> engine
  http[Management routes] --> engine
  engine[Engine] -->|Repositories| store[Store]
  engine -->|Policy| policy[Policy]
  engine -->|SourceScope| registry[SourceRegistry]
  engine -->|Assessor| assessor[MasterAssessor]
  engine -->|Executor| executor[DshExecutor]
  assessor -->|decide| engine

A completed task can resume when a person sends a follow-up message in its conversation. Before resuming, the system checks that the original conversation is still an accepted source. It also rechecks current allowlists and rules according to the basis for approval. Failed revalidation revokes authorization. Pending messages return for fresh evaluation unless another task is already handling them.

Stopping also works in different ways. A person's request to stop in a conversation is evaluated like a normal message. The panel's stop control halts the task directly. A task stopped by a person cannot resume without fresh approval.

5. Less attention is needed, but policy management becomes a responsibility

Having an agent triage requests and handle them in task-specific spaces can reduce the need for people to initiate every task. The team's role shifts from handling individual requests to managing allowed users and rules and reviewing evaluation records. Observation mode records evaluations without automatic execution. It lets teams judge which requests can safely be delegated automatically.

However, workers run commands under the operator's account without approval. Dedicated folders and command wiring settings are not security isolation mechanisms. The repository is a research prototype, not an official product. It warns of possible bugs and differences from the internal version, and recommends review and environment-specific adjustments before adoption.

The value of adopting this prototype lies less in increasing autonomous execution than in letting teams first define the scope of delegated work and permission to start it.