Skip to content
Security & Trust

DeepSeek's coding agent makes 'who may ask' the first question to answer

An open-source research prototype acts on asks from allowed users and rules that teams write themselves.

W
WebPulse Newsroom
AI-assisted · 4 min read
Share on X LinkedIn
DeepSeek's coding agent makes 'who may ask' the first question to answer
In brief
  • DeepSeek published dsh-superagent, a research prototype coding agent that listens to GitHub and optionally Feishu, and acts on asks from allowed users and team-written rules.
  • The sources describe no other control we can judge, so who may ask, and what may trigger unprompted action, is the first question to settle.
  • DeepSeek's post on its internal system adds an outside monitor and unprompted bug-fixing; the sources do not confirm the published prototype includes them.

Who may set the agent moving

A coding assistant that waits for a person to type is one kind of tool. An agent that watches your repository and, optionally, a workplace chat tool is another. DeepSeek has published a prototype of the second kind, called dsh-superagent. The first question to ask is who may set it moving. The sources show no other control that we can judge.

What DeepSeek published

The project's GitHub page describes a coding agent built for a single repository. It listens to GitHub and, optionally, Feishu, a workplace chat tool. When an allowed person asks for work, the agent opens a work item. It handles that item in its own agent session and its own directory.

Finished work goes back to the thread where the request began, for instance as a proposed code change. Items waiting on a human are listed in a browser dashboard.

The authors are open about the project's status. They call it a research prototype for reference only, and not an official DeepSeek product. They say it is not production-ready and may contain bugs. They also say much of the engineering was done by coding agents. The published code is not identical to DeepSeek's internal version or to the system in its related article. Some designs in that article are future directions and are not implemented.

How DeepSeek's internal design works

Tech in Asia reported on a DeepSeek WeChat technical post from October 31. DeepSeek described its internal system as two layers. Workflows are triggered by events. Conversations run across several channels without waiting on each other. Storage is kept apart from computing. A monitor runs outside the agent.

The sources do not confirm that the published prototype implements any of this. Treat it as the design of DeepSeek's own system.

In plain terms, event-driven means the agent reacts when something happens, such as a new issue or message, instead of waiting to be called. Asynchronous means it can handle several conversations at once without blocking on any of them. A watchdog is a separate monitor that watches a program from outside. The reports do not say what DeepSeek's watchdog checks or what it can stop.

Acting without being tagged

The repository text sets two triggers for action: a request, or a team-written rule that permits it. Its messages are meant for moments when a person must decide or can use something the agent produced.

Tech in Asia relays a claim from DeepSeek's post about its internal system. If colleagues mention a software problem in group chat, the system may spot a likely bug. It may then try to reproduce and fix it in the background, with no one tagging it. The sources do not show that the published prototype does this.

If the same behaviour were enabled in a deployment like the prototype, it would fit the repository's text only where a team rule permits unprompted work. The sources do not show what such rules look like. That gap matters. A bug mentioned in passing in a chat could become a pull request. Whether that helps or adds noise would depend on a rule someone wrote, and on who can edit it.

Questions to put to your team

DeepSeek says an internal instance has been running continuously on bug fixes, code reviews and work on DeepSeek Harness. That is the company's own account, and the sources offer no independent test. Tech in Asia sets the post beside OpenAI's description of engineering that starts with agents. Leaders weighing similar tools can ask five concrete questions.

First, who is on the allowed list, and who approves additions? Second, which rules let the agent act without a request, and who can change them? Third, what does the agent's separate session and directory actually isolate it from? Fourth, if a vendor describes an outside monitor, what does it check, and can it stop the agent? Fifth, who reviews the pull requests, and do they have time if the agent produces more than people can read?

The project's own philosophy touches the fifth question. It aims to use as little human attention as possible while delivering as much value as possible. That is a sensible goal. It also puts review time under strain.

Tech in Asia says a public launch in China could bring such a service under the country's generative AI rules, which cover safety, data sources and content control. This prototype is a published research repository, so that point is conditional.

A line worth keeping

Trust inside a team is a shared account, and an agent acting in the team's name draws on it. Read the permission list before you read the code.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: github.com.

Follow this story: every update on DeepSeek