DeepSeek Harness team releases an AI agent prototype for GitHub tasks

The DeepSeek Harness team published the code for an AI agent prototype on October 31, 2026, designed to receive requests from GitHub, turn them into tasks and coordinate their execution. Called dsh-superagent, the project works with a single repository and can optionally connect to the Feishu communication platform. The release is a research prototype.

The agent is packaged as a bundle of components for DeepSeek Harness. An accepted request receives its own working session and directory, while the response returns to the conversation where the request originated. The result can be, for example, a proposed code change presented through a pull request and tracked until the associated process closes.

The authors state that the public version has been adapted for release and differs from their internal implementation. Some directions described in the presentation concern future development. The public code's documentation defines the available components, authorization rules, task execution and supervision panel. This is infrastructure for coordinating agents, separate from the release of a language model.

From a message to a task with explicit boundaries

The team's stated principle is to reduce the attention consumed by agent management, with interventions tied to a useful result or a necessary decision. The prototype fits software development and workflow automation projects in which requests, changes and checks are tracked together. Its code separates the intake of events, their evaluation and the execution of accepted work.

The available event sources are GitHub and, optionally, Feishu. A source retains its reading position so that a restart does not replay the entire stream. Events are associated with the relevant conversations. The system distinguishes a new request from messages supplying information to an existing task and keeps a record of its decisions.

Evaluation for starting a new task has two layers. The first checks rules concerning the sender and how the message addresses the agent. The second uses the model to assess the request in context. The policy includes lists of authorized people, rules written by the team and the handling of messages from bots or automated checking systems.

Acceptance creates a Ticket, the prototype's unit of work, together with a Mandate. That mandate records the task's permitted scope, the sender's identity within that source, applicable rules and the policy version. Expanding the scope requires a new task. Following additional discussions supplies context without, by itself, widening the authorization granted for the work.

Initiatives inferred from conversations have three acceptance modes: off, observe and auto. The default mode, observe, records what the system would have accepted without starting that inferred work. Explicit requests function in all three modes. Automatically accepting an inferred initiative requires at least one active rule that covers it, as part of the team's policy.

Separate sessions and priority for human involvement

Each Ticket is assigned to an Executor, which works in its own session and directory. The configuration can prepare a separate project checkout before the first execution. The documentation states that sessions execute commands as the operator's operating system user. Separate directories organize the work; the permissions of the process and its environment determine actual technical access.

The number of sessions working simultaneously is controlled by a configured limit. An additional slot is available for a person continuing a task or requesting its status. A human discussion about existing work can therefore be taken up even when the normal slots are occupied. New task launches wait until the required execution capacity becomes available.

Follow-up messages in a subscribed conversation are linked to the corresponding Ticket. Its Executor decides whether the request fits the authorized scope and can return an out-of-scope request for evaluation. An ended task can resume following a person's message, subject to the policy's checks. Bot messages and automated checking results do not wake ended tasks on their own.

A person's stop request withdraws the mandate, and a stopped task remains ended. Policy changes are delivered to active work, while resuming an ended task involves revalidating the applicable conditions. The documentation separately describes pausing processing: sources continue recording events while the dispatch of work and automated replies is suspended by the system.

Reviewable results and a panel for necessary decisions

The prototype tracks a task's state separately from the session executing it. A report can indicate progress, waiting, a ready result, a blockage or failure. A ready result associated with a pull request awaits review. Once the tracked proposals have closed, the system can end the task, subject to conditions concerning messages and unfinished work.

Merging changes is governed by delivery instructions and repository rules. The default configuration does not enable automatic merging through the agent's account. Without a separate account designated for that operation, people perform the merge. The authors identify GitHub branch protection as the mechanism for enforcing required approvals before code changes are merged into the repository.

The DeepSeek Harness panel prioritizes tasks requiring human involvement, system problems and executor load. Event history, decision reasons, associated rules and execution state are available. Recent activity is also presented within a 24-hour window. Questions and results ready for review are distinguished from work still in progress, helping the operator identify the type of intervention required.

Recovery after interruptions uses the saved state of sessions, messages and tasks. On resumption, the executor is instructed to check the working directory, Git history and GitHub state before repeating an external operation. A retry retains the same session, directory, branch and pull request for the piece of work concerned, rather than replacing them with a new task.

The release includes prototype code, tests and documentation covering authorization, execution, the panel, configuration and architecture. It is MIT-licensed, allowing use and adaptation of the code under that license's conditions. The implementation presented remains focused on managing work in one repository, through authorized requests and team rules, with results returned to the conversations in which they originated.