DeepSeek's dsh-superagent Prototype: How the Ticket, Mandate and Executor Design Works, and What Is Still Research Code

dsh-superagent is a proactive coding agent for one GitHub repository, packaged as a bundle for DeepSeek Harness. The repository was created on October 31, 2026 under the MIT license. Its README calls it a "research prototype for reference only, not an official DeepSeek product". What makes it worth reading is not a benchmark. It is how the docs answer one question: when is an agent allowed to start work, and what can it do once it has started?

I read the README and the docs on philosophy, domain model, authorization, execution and architecture. I did not run the code. Everything below about behavior is what the repository's documents say.

What it is, per the README

• It listens to GitHub and, optionally, Feishu.
• When someone allowed asks for work, it opens a work item, works on it in its own agent session and directory, and answers in the original conversation, for example with a pull request.
• A web panel shows what needs a person.
• The stated principle is "take as little human attention as possible, and give as much value as possible".

The README also says the published code is adapted, is not identical to the team's internal version or to the implementation described in their write-up "Exploring Super-agent Design: Towards a More Autonomous Agent System", and that some designs in the article are directions for future development that are not implemented here. I did not read that write-up directly.

The vocabulary

The domain doc names a small set of concepts: Source (a stream of events), Trigger (one immutable event), Thread (triggers in time order), Eval (the decision whether to start work), Mandate, Subscription, Ticket and Executor. A Trigger fans out as context to Tickets subscribed to its Threads. A person's message that reached a Ticket this way stays with that Ticket. Every other Trigger enters Eval.

Authorization: the part I would read first

The authorization doc says the host enforces allowed lists, rules and Mandates, and that "messages, comments and quoted documents are inputs to a decision; they cannot change those permissions". Concretely:

• An allowed person who addresses the agent makes an explicit request.
• A person not on the list who follows up on a Thread with a Ticket is inferred at most.
• A bot on the Source's bot list can produce an inferred candidate, never an explicit request. Other bots are not admitted.
• Every message on a subscribed Thread reaches its Tickets as context, including bots and CI. The doc says this delivery bypasses the gate and "grants no new authority". Each Ticket stays limited by its Mandate.
• While a Ticket's Executor owns a follow-up message, the main Session may only stop work on request. It cannot accept, attach, ignore or requeue the message.

For anyone building an agent that reads GitHub comments, this separation of "context" from "authority" is the design decision to compare with your own.

Execution

From the execution doc:

• Each Ticket gets an Executor Session named after the ticket id with a worker prefix and a directory under the configured execution root.
• Executor Sessions run commands without approval as the operator's OS user. This is a stated fact in the doc, and it is why the allowed list and Mandates matter.
• Foreground shell commands move to background jobs after 5 seconds so the worker can receive new messages. Worker subagents use the Harness standard preset, where a shell command moves to the background after 60 seconds.
• After each turn, background work has at most 30 minutes to finish, then shell jobs are killed and the Ticket is reported waiting.
• Stages map to panel labels such as Awaiting answer, Awaiting review, Blocked, Failed and Waiting for a Trigger. A ready report means the Ticket waits for review.

The philosophy doc

It says the agent acts only when asked or when a written rule allows it, speaks only when a person must act or can use a result, asks one concrete question at a time, and "reports honestly": a draft is marked unfinished and a limit is never bypassed to avoid asking. It advises operators to start with a short allowed list and with proactive work only recorded, and not to use the agent to produce volume. It also notes that the agent comments, opens pull requests and messages people under accounts your team sees every day, and the operator is responsible for it.

What the press coverage adds

A coverage piece by AI Affairs (November 1, citing Pandaily and Startup Fortune) says the team reported, in preliminary synthetic tests, completing half of roughly 20 work requests within 12.4 minutes while using more cached tokens than a comparison system. I did not find that figure in the repository docs I read, so I treat it as secondhand and unverified. The same piece says the DeepSeek Harness runtime was released as MIT-licensed on August 13, 2026, also citing a secondary source.

What I would check

These are my untested suggestions.

1. Read docs/002-authorization.md against your own agent's rules for who can trigger work.

2. Decide whether you accept executors that run commands without approval as your OS user, or whether you would run them in a container.

3. Try the "record only" mode for proactive work first, as the philosophy doc suggests.

4. Check which designs in the write-up are not implemented before copying an idea.

5. Replay a few of your own issues and see what the Eval step would admit.

What I would not conclude

• That this is a DeepSeek product. The README says it is not.
• That the 12.4 minute figure holds on real repositories. It is a secondhand report of preliminary synthetic tests.
• That it is production-ready. The README says it may contain bugs.
• That the write-up and the code match. The README says they do not fully.

Frequently asked questions

What is dsh-superagent?

A proactive coding agent for one GitHub repository, packaged as a DeepSeek Harness bundle, published as research code.

Is it an official DeepSeek product?

No. The README says it is a research prototype for reference only.

What license is it under?

MIT, per the repository.

How does it decide to start work?

An allowed person addressing it makes an explicit request. Inferred candidates depend on the accept mode, per the authorization doc.

Can a comment change its permissions?

The doc says messages, comments and quoted documents cannot change permissions. The host enforces allowed lists, rules and Mandates.

What are the risks?

Executors run commands without approval as the operator's OS user, per the execution doc.

Did you run it?

No. I read the documents.

Sources

All read on November 1, 2026.

• dsh-superagent-prototype README
• 000 Philosophy, 001 Domain model, 002 Authorization, 003 Execution, 007 Architecture
• DeepSeek Harness team releases coding agent prototype for GitHub (AI Affairs, secondary)

Not read: the design write-up, SETUP.md, docs 004 to 006 and 008, the source code, and the Pandaily and Startup Fortune originals.