An agent that listens to a team needs a clear answer to a basic question: whose request can it act on?
DeepSeek published a research prototype called dsh-superagent, packaged as a bundle for DeepSeek Harness. Its initial public commit is dated October 31. The pinned README explicitly says it is not an official DeepSeek product or production-ready software.
The prototype listens before it works
The project describes an agent assigned to one GitHub repository. It listens to GitHub and can also accept Feishu input. When an allowed person requests work, the system creates a work item, a separate agent session, and a directory.
The README describes returning results to the original conversation, for example through a pull request. A web panel identifies work that needs a person. These are the authors’ descriptions of the code; we have not deployed the system.
Separate the event from the permission
A repository event says something happened. It does not, by itself, authorize an agent to modify code. That distinction is central to this design: an incoming request needs an allowed identity or an applicable team rule.
Consider an issue containing a proposed change. A useful evaluation would record the event, the identity behind it, the rule that permits work, and the resulting work item. Removing the permitted identity should change the authorization result while leaving the issue text identical.
That paired case is a proposed authorization test. It does not establish that the prototype’s controls are complete. It gives an operator a specific behavior to examine before granting repository access.
The public implementation has limits
The authors say they adapted the code for publication. It differs from their internal implementation, and some ideas in the accompanying design article remain future directions. A description of the broader system should not be read as a list of implemented features.
The repository uses the MIT license. Its setup guide describes a substantial environment and configuration process. Installing dependencies and connecting accounts are separate decisions from reading the release.
Read it as an engineering experiment
My first use of this release would be to study the request-to-work-item boundary, rather than grant it access to a live project. A small isolated repository could later make the intended permissions and failure paths easier to observe.
This publication is a separate event from the earlier DeepSeek Harness launch. Our Replit Cloud Agents report describes a different commercial approach to existing repositories. Which team event would you allow to start an agent task automatically?
Abdessalam Alaoui
I'm Abdessalam Alaoui, founder of Musthave.AI. I write practical guides to AI models, tools, generative media, and ways real people make money with this stuff. No press-release fluff. 20+ years shipping digital products; you'll also find my work around HowTik, Yumasty, and IncomeHelpful.
