A bug turns up in a team chat. Someone asks the coding agent to fix it. A pull request appears back in the same conversation. The attractive part is everything the team did not have to do: open another window, reconstruct the discussion, then chase the work across tools.

That is the shape of DeepSeek's newly public Super-Agent prototype. The more interesting question is what happens when the chat contains a complaint, a suggestion or an automated review, rather than an approved request.

A prototype, not a product launch

The repository describes dsh-superagent as a proactive coding agent for one GitHub repository, with optional Feishu support. An allowed person can ask it for work; it returns a result to the originating conversation, such as a pull request. A web panel shows work that needs a person.

DeepSeek labels the release research code, not an official DeepSeek product or production-ready software. The public version differs from its internal version, and some ideas in the accompanying design article are still future directions. Those qualifications matter more than the name.

The Next Web's November 1 coverage places the release in the race to coordinate coding agents with less human attention. The AI/TLDR digest makes the practical change clear: the work starts in an existing conversation, rather than a terminal. Neither report establishes that the prototype will save time on your repository. GigSoul has not run it.

Listening is not the same as being asked

The project's authorization document distinguishes explicit requests from inferred candidates. An allowed person addressing the agent can make a request. Other messages depend on the team's configured permissions and rules. Automated accounts do not get to make explicit requests merely because their comments sound helpful.

The default mode for inferred work is observe. The system records what it would accept without starting that work. Explicit requests still work in this mode. A team can review those records before allowing proactive acceptance.

That is a useful distinction for a shared chat. A sentence can be relevant without authorizing a change. The documentation says messages and quoted documents cannot change the configured permissions. Context can help explain the job; it cannot grant itself permission to become one.

The permission gate is not a sandbox

There is a second boundary, and the execution documentation is blunt about it. Work runs commands as the operator's operating-system user without per-command approval. Its directories and command wrappers establish defaults, not a security boundary; an executable can still be reached by absolute path.

In other words, controlling which conversation starts work does not isolate the machine doing that work. Anyone considering the prototype should assess the account, files and credentials the process could reach, rather than treating an allowed-sender list as containment.

Merging has another limit. The default delivery instructions restrict auto-merge, but the documentation says these are agent instructions, not GitHub merge rules. Teams that require approvals should enforce them through branch protection and dismiss stale approvals. A policy written for an agent and a rule enforced by the repository are different controls.

Measure the attention bill

The project's philosophy warns against mass pull requests, broadcast messages and busywork. It recommends starting with a short allowed list and recording proactive work before widening it.

That offers a better first evaluation than counting generated patches: did the agent recognize a real request, stay inside it, produce something reviewable and avoid creating a new coordination job? Super-Agent is interesting because its public design takes that attention bill seriously. The prototype label is a reminder that teams still have to check whether the code pays it.