DeepSeek tests a coding agent that follows a project over time

DeepSeek has released the source code for dsh-superagent, a research prototype that can monitor a GitHub project, receive tasks, make changes and follow up on the results. The aim is to make AI agents less dependent on people repeatedly starting new conversations and telling them what to do.

Many people today use coding agents by opening a conversation, describing a task and letting the agent do the work. Once the task is finished, they often have to follow up on the result themselves, handle new feedback or start the next task.

DeepSeek is exploring a different way to organize this. In the open GitHub project dsh-superagent-prototype, the company's DeepSeek Harness team presents a system in which an agent can follow a development project over time, respond to events and continue working without someone having to create a new conversation for every step.

This is not a new language model. It is software that organizes how AI models, coding agents and tools work together. The system is built as an extension to DeepSeek Harness, the company's open-source framework for AI agents.

From a conversation to an ongoing workflow

Imagine you are developing a website and discover a bug. You create an issue in GitHub and ask the agent to investigate the problem.

dsh-superagent registers the request, checks that you are authorized to give it tasks and creates a separate work item in the system. It then starts a coding agent that examines the project, attempts to fix the bug and can run tests before opening a pull request, a proposal for a code change.

When you comment on the change, the agent can continue working on the same task. It can also receive results from automated tests and code reviews. The task retains its history even if the agent ends a work session or the system restarts.

Several such tasks can be processed in parallel. Each gets its own working directory and agent session, allowing different changes to be developed without getting mixed together.

The prototype supports GitHub and can also connect to Feishu, a collaboration platform for messaging and team communication.

One agent coordinates, others carry out the work

The system is built around two levels of agents.

The first level acts as a coordinator, called the Router. It receives events, assesses what they concern and assigns tasks. The coordinator is not supposed to spend its time investigating and changing code itself.

The second level consists of Workers, separate coding agents that carry out the tasks. They can read files, make changes, use tools and open pull requests. They can also use subagents when a task calls for them.

When an event arrives, it is registered as a Trigger. The system assesses whether the event should lead to a task and, if so, creates a Ticket with a defined mandate. The mandate describes why the agent is allowed to work on the task and how far it may go.

This is more than just a collection of AI agents sending messages to one another. The architecture handles tasks, permissions, history, parallel processes and recovery from failures.

State is stored in a SQLite database, among other places. This means the entire workflow does not depend on a single AI conversation remembering everything that has happened.

Can the agent start working on its own?

Yes, but only within rules configured in advance.

This is an important part of the concept. dsh-superagent is intended to discover tasks without someone necessarily addressing it directly. For example, it can assess new comments, code reviews or failures in automated tests.

The system has three settings for this kind of proactive activity:

• Off: The agent does not start tasks based on indirect signals.
• Observe: The agent assesses events and records what it would have done, without starting the tasks.
• Auto: The agent can start tasks automatically when they meet defined rules.

Observe is the default setting. Direct requests from authorized people can still be carried out.

The included rules are fairly limited and cover things such as clear text corrections and visual bugs where the desired result has already been defined. The system is not supposed to invent new design decisions just because something looks wrong.

Here, fixed controls in the software are combined with the AI model's assessments. A model can suggest that something should be done, but it cannot change who is authorized to request tasks or expand its mandate through an ordinary comment.

Reducing unnecessary human follow-up

A recurring principle in the documentation is that the agent should require as little attention as possible from the people using it.

It should acknowledge the task once, keep working without unnecessary status messages and only get in touch again when the result is ready, something has gone wrong or a decision is needed.

The prototype therefore has its own control panel. It shows which tasks are waiting for review, which need an answer and whether anything has stalled.

A coding agent that automatically produces large numbers of comments, notifications and pull requests can quickly create more work than it saves. DeepSeek has therefore made limiting unnecessary communication a central design principle.

What could this mean for AI development?

The difference lies primarily in how the work is organized, rather than the AI model itself necessarily becoming smarter.

A coding agent may already be good at programming. With a system such as dsh-superagent, it can also become part of a persistent workflow in which new events are automatically sent to the right task.

This opens up the possibility of AI agents taking greater responsibility for ongoing follow-up on development projects, while people concentrate on priorities, design choices and approving results.

The architecture is also extensible. The final chapter of the documentation, 008 Cookbook, shows how developers can connect new event sources through custom integrations.

This means the principles can be used beyond GitHub. Messages, other development systems and external services could, in theory, become sources of tasks. Such integrations must be developed, however, and are not automatically available in the prototype.

For developers already using AI coding agents, this could be an alternative to coordinating many separate conversations manually.

Still a research prototype

DeepSeek emphasizes that this is not a finished, official product. The code is published under the MIT license, but the developers warn of possible bugs and inconsistent code quality. They also state that much of the development was done with the help of coding agents.

The prototype is also limited to one GitHub repository per setup. It requires installation, dedicated accounts and configuration of DeepSeek Harness. It is not a ready-made cloud service you simply log in to.

Security is another important point. According to the installation documentation, the agents run with extensive system access, without a full security sandbox. The developers therefore recommend a separate operating system account if better isolation is needed. Rules for the agent's behavior do not replace technical security boundaries.

The documentation includes mechanisms for error handling, recovery and testing, but that is not the same as documented results from long-term production use. This review examines the source code and documentation, but the system has not been run or independently performance-tested.

DeepSeek also writes that the published prototype is not identical to its internal system, and that some design ideas have not yet been implemented.

What is available is therefore, above all, a concrete example of how more autonomous AI agents can be built and organized.

Key takeaways

• This is not a new AI model. It is a system that organizes AI agents, tasks and tools around a development project.
• The agent can follow the work over time. It can receive tasks from GitHub, carry them out and continue when new comments or test results arrive.
• Several coding agents can work in parallel. A coordinator assigns the tasks, while separate agent sessions carry them out.
• Proactivity is governed by rules. The agent can be authorized to act without direct requests, but starts in an observation mode by default.
• People remain responsible. The system is intended to reduce the need for follow-up, not remove the need for oversight and approval.
• The technology is still experimental. The code is openly available, but security, stability and practical value must be assessed before it is used in real projects.

The basic idea is to make the AI agent a persistent part of the workflow, rather than a tool that has to be started and directed anew for each individual task.