DeepSeek Open-Sources Super Agent Architecture: Unified Scheduler Activates Multiple Agents

DeepSeek has open-sourced a super agent architecture, and released the prototype code alongside it. According to a quick report from a Bilibili video, the core of this release isn't yet another stacked Agent framework, but a design centered on unified activation through a scheduler—bringing multiple agents into a single scheduling logic for transformation processing, rather than letting them operate independently. Based on public information, the system is already in daily use within the team, primarily handling two types of tasks: issue investigation and code review.

Architecture Highlight: One Scheduler Activates Multiple Agents

The most common pain point in multi-agent systems is that each Agent has its own activation conditions and context management. When combined, scheduling overhead and state synchronization costs quickly balloon. DeepSeek^Ad's architecture converges activation entry points onto a unified scheduler, where multiple agents are awakened and transformed through the same scheduling layer, then return results.

The significance of this design is that collaboration between agents no longer relies on point-to-point message passing, but is orchestrated uniformly by the scheduler. For engineering teams, this means an observable, reusable scheduling strategy rather than writing glue code separately for each task.

A Multi-Agent System typically refers to an architecture where multiple autonomous agents collaborate to complete complex tasks. Each agent can be an independent instance based on a large language model, with its own prompts, toolset, and context. In traditional implementations, agents collaborate through message passing or shared memory, but activation conditions, context windows, and state management remain independent, causing scheduling overhead to grow rapidly with the number of agents. By converging activation entry points onto a unified scheduler, DeepSeek essentially moves the decision of "who gets awakened and when" from individual agents up to the scheduling layer, thereby reducing the complexity of state synchronization and orchestration.

Measured Data: Half Completed in 52 Minutes, 95% in 16 Minutes

The measured results mentioned in the video deserve separate attention: in completion tests, half of the tasks were finished in 52 minutes, and 95% of tasks were completed within 16 minutes. Looking at these two numbers together, the distribution of task duration is clearly uneven—there's a significant gap between the median and the tail.

A reasonable interpretation is that the scheduler responds quite differently to different types of tasks: structured tasks like routine issue investigation and code review converge quickly, while complex tasks still require longer processing chains. This also suggests that when evaluating such systems, users should look at task distribution rather than just averages.

Internal Deployment: Issue Investigation and Code Review

According to the quick report, the system is already in internal use, helping the team investigate issues and respond to code reviews daily. These two types of tasks share a common trait: relatively clear inputs and verifiable evaluation criteria, making them suitable for division of labor across multiple agents.

Issue investigation can be broken down into reproduction, localization, and verification stages, while code review can be split into style checking, logic review, and security scanning. The benefit of unified scheduler activation is directly apparent here—the same scheduling logic can adapt to different agent combinations for different tasks, without rebuilding workflows for each scenario.

What the Open-Source Prototype Means

Open-sourcing the architecture and prototype together provides more reference value than publishing only a paper or an architecture diagram. The prototype code lets people see the actual implementation of the scheduler, the integration conventions for agents, and the specific task distribution strategies.

For teams wanting to build their own multi-agent systems, the value of such prototypes isn't in using them directly, but in providing a comparable engineering paradigm: how to design the scheduling layer, how to pass state, and how multiple agents can avoid interfering with each other. These details are often what truly blocks multi-agent systems from being deployed.

A Few Observations

Currently, public information about this architecture is still limited. The methodology of the measured data, the distribution of task types, and the specific mechanisms of the scheduler have not been fully disclosed. From what's available, the direction is clear: converge the complexity of multi-agent systems into the scheduling layer, making upper-level task orchestration simpler. Whether this design still holds at larger scales and with more task types remains to be verified with more public details.