DeepSeek Open-Sources Super Agent Foundation: Using Old Operating System Tricks to Solve AI Management Challenges

Over the past year, Coding Agents have exploded in popularity. From Cursor to Devin, from Claude Code to various open-source solutions, models can do more and more—writing code, fixing bugs, running tests, working for hours without stopping. But in practice, many people's experience is: the more capable AI gets, the busier we become. You open five or six chat windows, each with an AI working inside, and you have to switch between them constantly—checking progress on this task, deciding whether to manually handle that error, figuring out which task is ready for review. AI, originally meant to reduce our workload, has created a new job: managing AI.

On October 31, the DeepSeek^Ad Harness team published an architecture article about exactly this. They argue that the more capable AI becomes, the less the bottleneck is the model itself and the more it's human attention—a person can typically keep track of only three to five active conversation windows at once, essentially dumping what should be low-level technical isolation onto the human brain. They call the current state of AI Agents the Session model: each Session is an independent chat window, isolated from the others; you tell it something, it does the work, and next time you talk it doesn't remember what was discussed. But real software development doesn't work that way—an issue might start as a GitHub issue, then move into code changes, PR review, CI testing; the developer might raise a requirement today, add constraints tomorrow, and change their mind in the same PR the day after. These are all the same piece of work, but in the Session model you have to manually carry context between each stage.

So the DeepSeek Harness team proposed what they call a Super Agent: turning AI from an execution tool that waits for instructions into a continuous entity that spans platforms, operates around the clock, and can proactively get work done. You don't need to manage where the Session is—it can keep an eye on multiple things simultaneously.

Four Characteristics of a Super Agent

DeepSeek lists four characteristics for Super Agent. First, continuity: whether you're halfway through a conversation in a chat group or changing your mind in a GitHub PR comment thread, you're always dealing with the same Agent that understands the full context. Second, efficiency: multiple complex tasks can progress in parallel, and one time-consuming task doesn't block you from sending new instructions. Third, proactivity and persistence: proactive means it continuously monitors the surrounding work environment and finds work on its own; persistent means it keeps running even when your device goes offline and can recover from failures by itself. A single React Loop clearly can't support these four characteristics, so the DeepSeek team's solution is interesting—they didn't invent any new theory, but instead took classic designs that have existed in computer systems for decades and moved them one by one into the Agent architecture.

Dual-Layer Architecture: Router Doesn't Work, Worker Doesn't Talk

The core design is called the dual-layer architecture, and the idea is simple: split maintaining global continuity and doing high-concurrency work into two layers. The upper layer is the Router layer, a persistent global scheduling node responsible for receiving all human interactions—whether a message comes from chat or from GitHub comments, it first goes to the Router. But the Router has one principle: it doesn't do work itself, and you might not even give it a Bash tool. It's only responsible for figuring out one thing—who should handle this task. In their own words, the Router layer is often not as complex as you'd imagine; a lightweight model can run it.

The lower layer is the Worker layer. Each Worker is an independent execution unit, equipped with the full development toolset and the most capable reasoning model, focused on completing a single task within its own context. Workers have a strict discipline: they never speak directly to humans. Intermediate reasoning details and tool-call errors all stay internal; after finishing work, a Worker reports to the outer Router, which outputs to the human on its behalf. This way, the user feels like they're always talking to the same assistant that understands the big picture, while behind the scenes multiple Workers are coding in parallel. In their internal instances, the same development task can proceed continuously between a group chat and a GitHub PR—the user first proposes plan A in the group, then changes to plan B in a comment, and the Router understands it's the same piece of work and automatically adjusts the Worker's direction.

React Loop (ReAct loop) is the foundational operating paradigm for the vast majority of current Agents, originating from the ReAct paper (Reasoning + Acting) proposed in 2022. Its core is to let the large model cycle between "think—act—observe": the model first outputs a piece of reasoning, then decides which tool to call; after the tool returns results, they are appended to the context as new observations, and the model continues reasoning based on them until the task is complete or the step limit is reached. This loop is inherently synchronous, serial, and single-context—it can only advance one thing at a time, and tool calls block subsequent conversation. The article's claim that "the classic React Loop can't support the four characteristics" refers precisely to its inability to parallelize or maintain global continuity after being interrupted by external events. Super Agent's asynchronous Start/Stop, event-driven design, and dual-layer split are essentially engineering-level decoupling of this loop.

Subscription Pass-Through and Batching: Offloading the Router

If it were just a dual-layer architecture, the Router layer would easily become a bottleneck, so DeepSeek did two more things. One is called the subscription and pass-through mechanism: for example, when a Worker takes on a GitHub PR, it directly subscribes to all subsequent comments under that PR; when someone later suggests changes, the message goes straight to that Worker without the Router relaying it layer by layer. They ran ablation experiments, and this alone saved the Router about 30% of decision count and 37% of cached tokens. The other is batching: when external messages flood in at once, multiple events queued during the Router's previous reasoning round are automatically merged and processed together in the next round. Because the Router only does lightweight dispatching—long input, short output per step—the more backlog there is, the lower the per-decision inference time becomes. DeepSeek stress-tested this: as trigger event arrival rate rose from one per minute to 40 per minute, the inference time shared per decision dropped from 6.4 seconds to 1.6 seconds.

Event-Driven and Two-Stage Filtering: Letting the Agent Find Work on Its Own

A dual-layer architecture alone isn't enough. To make the Agent proactive, its input must shift from human-typed prompts to events continuously generated by the environment. So group chat messages, code review comments, CI results, email notifications—all of these are uniformly called Triggers in Super Agent. But there's a practical problem: in real group chats, the event stream is typically high-noise and low-trigger-rate—if every message were sent to the large model for judgment, compute would burn out instantly and humans would be annoyed to death. So DeepSeek borrowed the classic FastPass and SlowPass ideas from computer systems and built a two-stage filter. The first stage is code rules, a low-cost fast path that makes hard-logic judgments based on event source, group scope, and user whitelist—for example, messages from unauthorized users are ignored directly, group chats not on the whitelist are skipped, and not a single line of model inference runs.

The second stage is semantic rules, a higher-order slow path: only messages that pass the code check are handed to the model for reading, and the model then judges whether it really should act based on policies written in natural language.

FastPath / SlowPath is a two-stage processing pattern common in computer systems and network devices: the fast path uses fixed rules, table lookups, or hardware to handle the vast majority of simple requests, pursuing low latency and low overhead; the slow path handles complex cases that the fast path cannot decide, allowing higher cost and longer latency. Typical applications include network packet classification, database query optimizers, and filesystem path resolution. DeepSeek maps this to Agent event filtering: code rules (source, whitelist, group scope) serve as the fast path, blocking most noise without running a single line of model inference; only messages that pass the fast path enter the semantic-rule slow path. The key benefit of this layering is that cost grows sublinearly with event volume, rather than triggering a large model call for every message.

Context Management: Inline, Spill, and Chained Recall

Context management is another headache: even after events are filtered and routed correctly, how much information should be stuffed into the model's context window once it enters the target Session? Too much dilutes attention; too little forces the model to repeatedly call tools to read, increasing execution steps. DeepSeek's stance is blunt: wasting the context window is wasting the model's intelligence. They borrowed two concepts from compiler optimization—Inline and Spill. Inline means putting information likely to be used soon directly into the context window, saving extra tool-call round trips—for example, the first 50 characters of the current event, a few adjacent chat messages, and neighboring comments in the review where a code comment lives. Spill means leaving long content that exceeds the window budget outside, keeping only a summary and the IDs of related objects, so the model can call tools to read the full content when needed.

Even better is chained recall: the system assigns a unique ID to every Trigger, Thread, and Work Session, and when injecting context it inlines the IDs of their related objects, forming a reference graph underneath. Starting from the current event, the model can hop along IDs on demand to retrieve—from a current message to its Thread, then to the related Work Session, then to another associated code review. This way, when the Router needs to dig up old history after long-term operation, it doesn't have to cram all history into the window; it can expand on demand.

Speculative Execution: Try Your Luck in the Background, Shut Up If It Doesn't Work

Another fun design is speculative execution, similar to CPU branch prediction. When the Agent isn't yet sure whether its result will be adopted, it tries its luck in the background based on environmental signals. For example, someone in the group just said this bug seems pretty serious, and everyone is still discussing the cause, but the Agent has already quietly pulled the environment in the background, tried to reproduce the issue, and written a fix patch. If it succeeds, it delivers the result; if not, it stays completely silent and never pops up to show off. They configured a "silently reproduce and fix" policy in their internal group: the Agent first tries in the background, and only delivers when it confirms the issue and finds a simple fix; otherwise it stays silent the whole time.

Asynchronous Execution and Channel-Specific Output

By this point, Super Agent can already keep an eye on multiple things and proactively find work, but one experience problem remains: when the Agent is executing a time-consuming task, does the foreground get stuck? In the classic React Loop, when the model initiates a synchronous Run, the tool-call loop blocks immediately until tool execution completes. This time DeepSeek changed time-consuming commands and subtasks to asynchronous Start and Stop: after the model calls Start, it immediately receives a "started" response, and the loop no longer waits for background execution to finish; when the background run completes, the system injects the result as a new event; the model can also Stop at any time based on context to proactively terminate a background task that's been running too long. This decouples foreground conversation responsiveness from background task execution—while the background is compiling or running tests, the foreground can still instantly reply to your new instructions.

Output also differs by channel. In group chats, low disruption is required—like a restrained technical colleague who only sends notifications when a decision or acceptance is needed, with each reply strictly under 100 characters. For asynchronous channels like GitHub PRs and email, output should switch to high-density structured reports, writing complete problem background, change descriptions, or verification results when needed.

Storage-Compute Separation and Watchdog: Freeing the Agent from a Single Machine

Even so, an old problem remains: close your laptop lid and the Agent is dead. Traditional Agents bind computation state and execution environment to the same machine, so when the device goes offline everything stops. So DeepSeek applied the storage-compute separation idea from computer systems, decoupling in two steps. First, put the computation that advances the Agent Loop into stateless elastic containers in the cloud, with drawing state stored in a database, so the Agent can escape the single-machine lifecycle and achieve 24/7 online operation. Second, separate the cloud Agent Loop from the heavy-state execution environment: your code repositories, local toolchains, and private credentials all stay on your own computer untouched; the cloud only needs to install an extremely lightweight Daemon on your machine to execute commands and return results. This design is called BYOM (Bring Your Own Machine). This way, the Agent is no longer limited to a single machine, can switch between devices, and can choose environments based on task needs; even if your computer temporarily goes offline, the cloud Agent can continue doing other things, and when the computer comes back online it automatically reconnects and continues. They say this approach is consistent with Anthropic's "brain-hand separation," with the difference being the scenario: Anthropic discusses sandboxes created on demand by managed services and customer VPC resources, whereas DeepSeek here first needs to connect to users' everyday personal machines that may be intermittently online, with uncommitted changes and local credentials on them.

However, the cloud Agent's Loop can also malfunction—the process might crash, the model might fall into an infinite loop spinning in circles, or it might drift off course and make things worse. So DeepSeek attached an independent Watchdog outside the main system, driven by timer signals. The Watchdog itself is also an Agent Session; it doesn't do work but specifically monitors whether Workers are making substantive progress and whether their direction deviates from the overall goal. If it detects an anomaly, it forcibly intervenes to fix it; if it's an occasional external failure, it keeps rechecking until things return to normal. Maintainers can directly ask the Watchdog in natural language about the cause of a failure, or have it hot-modify the main system's prompt rules online.

BYOM (Bring Your Own Machine) is an idea proposed relative to BYOD (Bring Your Own Device) and BYOC (Bring Your Own Cloud): keep the heavy-state execution environment on the user's own machine, with the cloud retaining only the stateless scheduling and reasoning loop, executing commands on the user's machine through a lightweight Daemon and returning results. It is similar in goal to Anthropic's "brain-hand separation"—both split "thinking" from "doing"—but the constraints differ: managed sandboxes assume environments are created on demand and can be discarded at any time, whereas personal machines exist long-term, may be intermittently online, and have uncommitted code and local credentials on them. This also explains why the article lists security and privacy as the most practical open problem: once the cloud is compromised or prompts are injected, all connected edge devices are exposed.

Experimental Data: Trading Tokens for Time, Stability Above All

How does this architecture perform in practice? DeepSeek ran two sets of preliminary experiments. The first was an end-to-end ablation experiment, using real group chat and GitHub CI message streams to drive four schemes; a single experiment contained about 300 messages, interspersed with about 20 work requests, with the rest being chitchat, interruptions, and system notifications. The simulated tool was replaced by a time-consuming-only tool, so the experiment measures scheduling and collaboration capability, not single-task execution capability. Each scheme was run 5 times. Results: SuperAgent's median task completion time was 12.4 minutes, with 95th percentile at 15.7 minutes; while the single-Session scheme with a SubAgent tool, under the default prompt, had the model not call SubAgent even once across 5 runs—all work was done in the main Session, continuously interrupted by new messages, with the 95th percentile reaching 29.5 minutes.

After switching to prompt-first delegation, 4 out of 5 runs delegated, but it was still slower than SuperAgent, and in one run the model judged the work to be small and did it itself, creating a long tail. This shows that trying to get the model to divide work via prompts within a single Session is too unstable. The dual-layer architecture solves this at the system level by having the Router not directly execute concrete work and Workers only receive messages from subscribed Threads. Of course, the efficiency gain comes at a cost: SuperAgent needs to maintain multiple independent drawings, and cached tokens per experiment are higher than single-Session—essentially trading more tokens for shorter, more stable completion times.

The second was a Router-layer batching stress test: as Trigger arrival rate rose from one per minute to about 40 per minute, average Batch size rose from 1.0 to 2.8, and per-request latency only rose from 2.5 seconds to 3.9 seconds—growing far slower than Batch size; per-decision shared inference time dropped from 6.4 seconds to 1.6 seconds. This shows the Router can automatically merge backlog events during sudden congestion, improving throughput. At the current team size, there's no need for premature horizontal sharding that would sacrifice global context continuity.

Open Source and Open Questions

That said, DeepSeek admits this system is still a research prototype; experiments are based on synthetic load and simplified environments, not formal product conclusions. The prototype project DSH SuperAgent Prototype is already open-sourced on GitHub under the MIT license, built on DeepSeek Harness, and currently only connects to GitHub and Feishu—it's an engineering foundation reference for the tech community. There are also a string of open questions: how does the dual-layer architecture scale up? When does the Router need to be sharded? When do Workers need to communicate directly? None of these have definitive answers. Moreover, once the Agent moves beyond the Session concept, how do users collaborate with it? Is the chat window the final form, or does interaction happen more in domain interfaces like GitHub? These are still being explored. As organizations grow, how to divide context boundaries between multiple SuperAgent instances and how to enable inter-Agent collaboration is also a new problem. Most practical is security and privacy: since the cloud Agent connects to local credentials on edge devices, if the cloud is compromised or prompts are injected, all connected edge devices are at risk.

Conclusion: The Bottleneck Is Shifting from Models to Architecture

Back to DeepSeek's article itself—they didn't invent anything new. Dual-layer architecture, event-driven design, FastPass/SlowPass, speculative execution, storage-compute separation, Watchdog—all are things from operating system textbooks decades old. What they did was publicly systematize these classic designs into the Agent architecture, and you can clearly see the shadows of many classic systems. So I believe the value of this may not lie in how stunning any particular technical detail is, but in the fact that the Agent industry is changing flavor: for a while everyone relied on prompt engineering and luck to achieve results, but now that model capabilities have risen, the bottleneck is shifting from the model itself to system architecture. The DeepSeek Harness team uses old systems engineering tricks to solve this problem, providing the entire industry with a direction to reference.

Your current AI assistant—what annoys you most: that it's not capable enough, or that you can't manage it yourself?

One-line Summary

DeepSeek rebuilds Agent architecture with classic operating system designs, shifting the bottleneck from the model to the system.

Paragraph Summary

The DeepSeek Harness team published an architecture article proposing the Super Agent concept, attempting to solve the problem that the more capable Coding Agents become, the heavier the human management burden. Their core judgment is that the bottleneck has shifted from model capability to human attention and system architecture. The solution is to bring decades of classic operating system designs into the Agent: a dual-layer architecture where the Router only dispatches and doesn't work, while Workers only execute and don't speak externally; subscription pass-through and batching offload the Router; FastPass/SlowPass two-stage filtering handles high-noise event streams; Inline/Spill plus chained recall manage context; speculative execution lets the Agent try in the background and stay silent on failure; storage-compute separation and BYOM let the Agent run 24/7 independent of a single machine; an external Watchdog monitors infinite loops and direction drift. Ablation experiments show SuperAgent's median task completion time is 12.4 minutes, significantly better than the single-Session scheme, at the cost of higher token consumption. The prototype is open-sourced under the MIT license, but remains a research prototype, with scalability, interaction form, and security/privacy issues unresolved.