Quick Answer: A proactive coding agent picks up work on its own and reports back without a person scripting every step. dsh-superagent, a DeepSeek research prototype, works on one GitHub repository. It acts only when an allowed person asks or a team rule permits it, and it replies in the original conversation, often with a pull request.
Most teams picture a proactive coding agent as one that never sleeps. It files issues, fixes bugs, and pings you with progress. That picture misses the real cost. Every message an agent sends draws on your team's attention, which is the scarcest resource in the room. The dsh-superagent README takes the opposite stance and states it plainly: take as little human attention as possible, and give as much value as possible.
What dsh-superagent Actually Does
The repository describes dsh-superagent as a proactive coding agent for one GitHub repository, packaged as a bundle for DeepSeek Harness. It listens to GitHub and, optionally, Feishu. When an allowed person asks for work, the agent opens a work item, runs it in its own agent session and directory, and answers in the original conversation.
Here's a concrete case. A maintainer comments on an issue asking for a fix to a flaky test. The agent doesn't open a fresh chat that the maintainer has to babysit. It opens a work item, makes the change in its own directory, and replies in the same thread with a link to the pull request. The maintainer's involvement is one request and one review.
The practical lesson: the unit of work is the work item, not the chat. If you track work items, you can see what the agent is doing without reading every message it sends.
Why Less Attention Beats More Autonomy
The popular advice says more autonomy means more value. The dsh-superagent design argues that the binding constraint is attention, not compute. An agent that opens five pull requests nobody requested hasn't saved anyone time. It has added five review tasks and several interruptions.
The failure mode looks like this. When an agent posts every intermediate step to a team channel, people learn to mute it. Once muted, the one message that needed action gets missed. Noise trains people to ignore the channel, and the signal dies with it.
That said, quiet isn't always better. An agent that waits too long for permission can miss a security patch window, and the cost of that delay can exceed the cost of an extra notification. The trade-off is real. The right balance depends on how quickly your team actually responds to the channel.
So how does the agent decide when to speak at all? The answer lives in its authorization model.
Authorization: Acting Only When Asked or When a Rule Allows
The README's core rule is that the agent acts when someone allowed asks for work, or when a rule the team wrote allows it. The authorization document in the repo (docs/002-authorization.md) covers the details. Before you adopt a design like this, check three questions:
- Is the requester on the allowed list for this repository?
- Did the request arrive through a channel the agent actually listens to?
- Does a written team rule cover this kind of action, so it doesn't need a fresh request?
If the answer to all three is no, the agent should stay silent. Treat these as review questions for your own deployment, not as a complete specification of the prototype's rules.
Authorization rules are the part of this design you should write down first. A proactive agent with vague permissions is just an unpredictable one.
Reactive, Scheduled, or Proactive: How the Options Compare
Coding automation tends to fall into three shapes. The differences matter most when you decide who can start work and where results land.
| Approach | What starts work | Where results go | Main risk |
|---|---|---|---|
| Chat assistant (reactive) | A person types a prompt each time | Back to the same chat window | Low autonomy; every step waits on a human |
| Scheduled bot (cron-style) | A timer, regardless of current need | Usually a shared channel | Runs when nothing needs doing and adds noise |
| Proactive agent, dsh-superagent style | An allowed request or a written rule | Original thread, plus a panel for items needing a person | Bugs in an early prototype and loose permission rules |
The scheduled bot is the one most teams build first, and it's the one most likely to create attention debt. A proactive agent with an explicit trigger is harder to set up but easier to live with.
Execution: Separate Sessions and Directories
Each work item runs in its own agent session and its own directory. The reason is practical. Suppose you're halfway through a refactor on your laptop, and the agent edits the same files in the same working tree. You get merge conflicts, or worse, silent overwrites.
Separate directories solve this the way git worktree does. Each checkout is isolated, so the agent's branch and your branch never share a working copy. This is an analogy for the isolation principle, not a claim about the prototype's exact implementation, so read the execution document (docs/003-execution.md) before you rely on it.
Isolation doesn't remove review. Treat the agent's branch like a contribution from a new teammate. Read the diff, run the tests, and check that the change matches the issue you actually filed.
The Panel: Surfacing What Needs a Person
The repository includes a web panel that shows what needs a person. This is where the attention principle becomes a product feature. Instead of scrolling a stream of agent activity, you read a queue of decisions that only you can make.
The design only works if the panel stays selective. If every agent action appears there, the panel is just another firehose. A good rule: an item belongs in the panel only when a human must decide something, such as approving a merge, granting a new permission, or resolving an ambiguous request.
What's the last thing your team's bot told you that you actually acted on? If you can't remember, your notification channel probably has the same problem.
Setup, Caveats, and Running It Safely
The README is clear about what this is. It's a research prototype, not an official DeepSeek product. Much of the engineering was done by coding agents, so coding style and practices may be uneven. The article it accompanies, Exploring Super-agent Design: Towards a More Autonomous Agent System, also describes some designs that aren't implemented in this release.
Setup is designed to be done with a coding agent. Point yours at SETUP.md, and it asks one short question at a time, shows the full plan once, and then installs and configures everything. If you prefer a manual install, follow docs/006-deployment.md. For development, pnpm check runs the typecheck, the tests, and the build.
Before you put it near real work, do these four things:
- Read the numbered docs in order, since each builds on the ones before it.
- Run
pnpm checkand confirm it passes on your machine. - Scope the GitHub credentials to the one repository the agent is meant to serve.
- Review every pull request the agent opens before merging anything.
Frequently Asked Questions
What is a proactive coding agent?
A proactive coding agent monitors sources such as issues, chat messages, or a schedule, and starts work without a person writing every instruction. The useful ones are bounded. They act under explicit permission and report only when someone must act or can use a result. dsh-superagent is a research example built for one GitHub repository.
How do I set up dsh-superagent?
Ask your coding agent to read SETUP.md in the repository and walk you through it. The agent asks one question at a time and shows the full plan before it installs anything. For a manual install, follow docs/006-deployment.md, then run pnpm check to confirm the typecheck, tests, and build all pass.
Why should a coding agent stay quiet?
Because attention is the scarce resource. Each unnecessary message trains people to mute the channel, and then the one message that needs action gets missed. Speaking only when someone must act or can use a result keeps the channel worth reading.
Is dsh-superagent production ready?
No. The README calls it a research prototype, not an official DeepSeek product. It may contain bugs, and its engineering practices may be inconsistent. Review and adapt it before using it in your own environment.
Keep the Agent Quiet and Useful
The most useful step you can take this week is to write down which requests your proactive coding agent may act on without asking, and which must go to a person. Then watch the panel or channel for seven days and count how many items truly needed a human. Try it on one repository and note the result. Pass this to whoever runs your GitHub automation, since they're the one dealing with the notification noise.