DeepSeek Super-agent Architecture: How AI Agents Become Proactive Team Members

Introduction

Mainstream coding agents and models already possess strong task delivery capabilities, but enterprise team development environments demand more. Imagine a scenario where a developer posts a requirement in a chat group, a tester creates a GitHub Issue, and a reviewer leaves PR feedback — all visible to a single agent "partner" that generates tasks, drives them forward, and returns feedback through appropriate channels. DeepSeek recently released the Super-agent design and prototype plugin to address exactly this need: an agent that truly fits into a development team, stays online, responds proactively, automatically organizes tasks, sessions, and context, letting the team focus on decisions and acceptance.

Super-agent: An Always-Online Team Agent

In enterprise collaborative development, a single piece of work rarely ends within one developer's conversation. A change request may start in a group chat, receive boundary clarifications during development, and later collect review feedback after code submission. Meanwhile, an Issue awaits a fix. Each item has its own progress and can be advanced by a new message. Typically, multiple agents handle prioritization, dependencies, supplementary notes, reminders, and feedback routing. As tasks grow, so does the context to remember. Moreover, agent session contexts are not shared — closing a session, context compression, or handing off to another colleague may require re-explaining prior decisions.

DeepSeek Super-agent targets this persistent task organization and collaboration layer. The team continues using group chat, GitHub Issues, and code reviews, while Super-agent runs in the background discovering tasks, assigning them to suitable executors. Each task gets its own work context and Worktree; one task proceeds while others continue; completed tasks feed results back to the team.

Illustrative Scenario: Font Configuration

A product colleague requests in a Feishu group: separate font configuration for body text, code, and terminal.

The maintainer @Super-agent in the same Feishu thread to implement it.

Super-agent receives the message, evaluates, starts a task, modifies code, submits a PR, and reports back to the group.

Colleagues can follow up on the PR; Super-agent answers automatically.

A designer suggests adjusting the settings layout on the PR.

Super-agent recognizes and reuses the existing requirement, makes changes, merges the PR, and notifies the group.

During this collaboration, another execution session can fix a system bug, and a third can run API tests — they share necessary project background but keep task-specific details isolated. The team doesn't need to feed each session discussion details, nor pause other work because one task is time-consuming. Super-agent acts like an always-online, proactive teammate: remembering who requested what, which technical decisions are settled, where code changed, who is pending feedback; it ingests developers' scattered issues, forms work tasks, and continuously drives completion.

Overall Architecture: Coordinator (Router) + Executor

As a team "member", Super-agent must handle continuous interactions from multiple channels and process multiple tasks efficiently. This requires architectural improvement — not single-session queued processing (continuous context but low efficiency), nor simple one-to-one derived sessions (high concurrency but high resource use and fragmented sessions). Super-agent uses a two-layer logical architecture with role separation:

Coordination (Router) Layer: Receives external messages (GitHub, Feishu, etc.), decides which tasks to accept and who handles them.

Execution Layer: Runs concrete tasks in isolated contexts — code modification, testing, verification.

The two layers connect via task "tickets" that store task identity and authorization basis; execution sessions hold the context needed for the task.

Workflow Overview

Entry checks source scope; if it belongs to an already discussed ticket (e.g., a handled work order), route back to the original task.

Otherwise, check initiator against "order acceptance" rules; the main session arranges tickets, dispatches execution sessions and work directories.

Execution session processes the "ticket", reports progress, system persists results, and sends replies back to the appropriate conversation.

A single ticket can undergo multiple execution rounds and associate with multiple discussion events (e.g., multi-round discussion around "independent font configuration"); thus a new execution round doesn't require redefining requirements or replenishing context.

This architecture resembles the familiar "Orchestrator + Workers" Multi-Agent pattern, but Super-agent's coordination layer is positioned more "lightly" — it generally doesn't intervene in internal task decomposition, whereas Multi-Agent orchestrators focus on breaking complex tasks among multiple agents and coordinating their completion.

Five Design Details

1. Two-Layer Architecture: Logical Separation, Not Physical Constraint

Super-agent's two layers are logical division, not necessarily a single agent or single session. For example, a complex task ticket's execution can be done by one agent plus multiple subagents forming an Agent Team — the executor can still derive and call subagents to decompose complex work. Even the lightweight coordination layer may need to split into multiple coordinators when input event volume causes congestion, sacrificing continuity for throughput.

2. Event-Driven: Core Is Filtering and Routing

Group messages, GitHub Issue comments, PRs, and CI results all become Super-agent events. Not all events become real tasks, so filtering comes first. Filtering splits into deterministic rule filtering and semantic filtering:

Deterministic conditions (source, identity, group bot whitelist) checked programmatically first.

Candidate events passing programmatic checks go to an LLM for semantic filtering — rules defined in prompt strategies.

If filtering solves "whether to enter the task flow", routing solves "who continues the task": which are follow-up messages for already handled tasks (route back to the responsible executor), which need new work tasks dispatched to executors, which are daily chatter without work value (ignore).

"Thread Continuation": A stream of events formed by consecutive messages under an Issue/PR or group chat topic is called a Thread; subsequent events of the same Thread are directly sent to the execution session (Worker) subscribed to that Thread.

3. Async Execution Loop: Long Tools Don't Block the Conversation

A task execution typically follows an Agent ReAct loop: reason, call tool, observe result, continue reasoning — each step waits for tool completion before next reasoning. The problem: slow tool calls block response to subsequent user messages — e.g., a modification request is processing, but the user adds a new message; the session cannot respond.

DeepSeek Harness already includes an "Async ReAct" task mechanism for this: the ReAct loop launches a tool and returns immediately without waiting for completion; when the tool finishes, its result is sent back as a new event to the session. This solves session blocking by long tool calls, enabling faster response to user input.

4. On-Demand Context Organization: Let Sessions Retrieve Full Facts

As an agent serving different team tasks, managing task context is crucial. Super-agent's context management strategy: don't stuff every session window with full history; instead, put recent relevant content directly in the window, keep long logs and full reports outside the window with summaries and references. When details are needed, the model follows associations across messages, event chains (Threads), execution sessions, etc., expanding context via references. This reduces repeated injection of long context and lets compressed sessions still reach original records. It resembles some Memory product mechanisms but with more complex management.

5. Separate Compute, State, and Environment: Restartability Requires Persistence

If a local agent serves as Super-agent, device offline stops the agent. To keep Super-agent persistently online, DeepSeek proposes separating the agent's compute, persistent state, and tool execution environment:

Agent Loop (reasoning loop) runs in stateless cloud containers.

Persistent state (task progress, messages) stored in a database.

Tool execution (Git access, file writes, message replies) placed on the edge/client side.

Practice: Connecting GitHub and Feishu to One Super-agent

The above is DeepSeek's architectural design; the full product isn't released yet. However, DeepSeek published a lightweight prototype project: dsh-superagent-prototype (a DSH plugin). We demonstrate with this project.

Step 1: Let AI Install and Configure per Official Guide

The official project's SETUP.md is an agent-oriented deployment guide, so we can have AI assist deployment with explicit instructions. Example prompt:

请按 dsh-superagent-prototype 的 SETUP.md 部署。
使用独立的 superagent 配置，保留我已有的环境。
接入我的 GitHub项目 pingcy/xxxxx 和专用飞书测试群。
先检查依赖、模型和账号；安全凭据由我在本机输入。
使用短允许名单，默认不自动合并、不发布。

AI completes DSH and dependency installation, build, startup, independent config creation, plugin registration, and official checks, builds, and basic tests. Some steps may require user confirmation.

Step 2: Check and Configure Sources, Rules, etc.

After step 1, most configuration is auto-set. You can also enter Super-agent's settings UI. For GitHub, configurable items include:

Source: specify a code repo, GitHub CLI; events to receive (Issue, PR, CI, etc.)

Order acceptance rules: which accounts can initiate work; how to handle; acceptance rules (what to accept, what to ignore)

Execution environment: task ticket Git worktree root, state directory; model used by executor

Prompts: generally not recommended to change — prompts used during Super-agent work

Super-agent needs a GitHub execution account with repo read/write permissions, verifying the command entry's actual login identity. Later, @ this execution account in GitHub Issues to trigger Super-agent.

Step 3: Create an Issue to Trigger a Fix Task

Create a demo GitHub Issue, then add a comment from another account:

@pingcy 请修复上面超时预算接受 NaN、Infinity 等非有限值的问题。
只修改预算模块与回归测试，运行相关测试，提交 PR，不合并。

Wait; DSH panel shows Super-agent coordinator and executor workspaces start; Superagent plugin's "Execution" area shows authorized tickets recording requester, scope, and original discussion link. After completion, Super-agent replies in the GitHub Issue.

Step 4: Add New Requirements Along the Original Task

Now there's a pending PR. Suppose another colleague adds a new requirement in the same Issue — no need to @ the execution account again. Super-agent starts a new execution but does not open a new session task; it enters the original task — reasonable because it's the same Issue handling process. The original execution session adds regression tests on the same PR, reports 90 tests passed. Completion auto-replies to Issue; no new PR created — matching the requirement.

Step 5: Create Feishu Bot, Connect to Chat Group

Super-agent also supports Feishu group integration. Easiest: let AI help connect Super-agent to Feishu group (requires Feishu platform login): after creating a self-built app and bot, setting permissions, generating and binding security credentials, creating a test group and inviting the bot, AI queries group and user identifiers, writes into Super-agent policy, and enables Feishu source. Both GitHub and Feishu sources show running.

Step 6: Accept Orders from Feishu Group, Follow Up in Original Topic

Now interact with Super-agent similarly via Feishu group: initiate tasks, view results, add tasks. DSH Super-agent panel shows task execution. Because both entry points connect to the same Super-agent, cross-channel seamless collaboration works — Feishu receives task, executes on GitHub, replies back to Feishu (subject to GitHub and Feishu bot authorization limits).

Conclusion

This covers DeepSeek's Super-agent architecture introduction and prototype experience. Although the official product isn't released, it's clear: enterprise-grade coding agents are shifting focus from stronger model generation and longer complex tasks toward continuous, efficient, proactive work advancement in team collaboration contexts. Perhaps the future holds not only personal agents for everyone, but also a team-owned Super Agent.