DeepSeek Super-agent architecture

DeepSeek Super-agent: Router, Workers & Continuous Agents

Author
DeepSeekAgent.io Editorial Team
Published
Updated

In “Exploring Super-agent Design: Towards a More Autonomous Agent System,” the DeepSeek Harness team describes a different operating model for agents. Instead of asking a person to supervise several independent Sessions, one persistent entry point receives events, decides what deserves action, and dispatches isolated workers. The team also published dsh-superagent-prototype, a DSH bundle that turns part of that direction into runnable research code.

This is not a longer system prompt for one conversation. It changes where conversation, authorization, task state, and execution live.

Why one Session becomes the bottleneck

A conventional coding Agent works well when a person gives it one goal and waits for the result. When several repositories, issues, and team conversations move at once, the person must repeatedly find the right Session, restore context, and check whether the Agent is stuck.

As models become able to work longer without intervention, this coordination cost becomes more visible. Super-agent keeps human communication in a Router and moves concrete work into Workers, so a long test run does not block the system from receiving another request.

Router: the persistent front door

The public prototype calls its persistent control conversation the Main Session; its implementation role is orchestrator/router. It receives Triggers from Sources such as GitHub issues, pull-request comments, CI changes, or Feishu messages. Under the current Policy, it can:

  • accept a new Ticket;
  • attach a message to an existing Ticket;
  • stop work;
  • ignore an unrelated event.

The Router does not spend its context performing every repository change. It maintains the cross-source view and dispatches authorized work to Executors.

Worker: one execution context per Ticket

Each Ticket receives an Executor Session and a directory. The prototype names Sessions worker-<ticket id> and prepares a separate working directory for each unit of work. An issue cannot silently contaminate another task's branch, files, or conversation history.

A Worker can move long commands into background jobs, receive follow-up messages, report progress, and wait for a person. A Ticket may retain its subscriptions after an Assignment ends, allowing a later human follow-up to resume the same work instead of starting an unrelated conversation.

Sources, Triggers, and continuity

Super-agent does not scan everything indiscriminately. It connects configured Sources and converts their events into auditable Triggers. The prototype includes a GitHub Source and optional Feishu integration.

The Source owns read positions and thread mapping. Policy controls who may request work. A Ticket retains the authorized scope. Subscriptions route later comments, reviews, and CI results back to the right Ticket. Persisting these relationships is what turns a collection of model calls into a continuing system.

Continuous does not mean unconstrained

The design expresses initiative through inspectable controls:

  1. choose the Sources and scopes the system reads;
  2. use allowed lists and admission tables to identify valid requests;
  3. begin in observe, recording what the Agent would have accepted;
  4. bind every Ticket to a Mandate that cannot expand itself;
  5. return results through the originating Channel.

“Be proactive” becomes a combination of events, rules, authorization, and state rather than an open-ended prompt.

Design article versus public prototype

dsh-superagent-prototype is an MIT-licensed research prototype published by the DeepSeek Harness team. Its README says the public code was adapted for release, is not identical to the internal version, and does not implement every direction in the design article. It is best treated as a runnable architecture reference, not a finished hosted product.

Where the architecture fits

Super-agent is most useful when events keep arriving, work can be separated into Tickets, and a team is willing to define authority explicitly:

  • continuously handling issues, reviews, and CI feedback for one repository;
  • accepting development requests from a team conversation and reporting back to its thread;
  • running several changes in isolated branches and directories;
  • detecting rule-matched problems without giving the Agent unrestricted control of every message.

For occasional one-shot work, a normal DSH Session remains simpler. Super-agent earns its complexity through sustained intake, parallel execution, and recoverable state.

Related reading

References