DeepSeek Harness's Super-Agent Architecture: Router/Worker, Triggers, and BYOM

Yesterday, the DeepSeek Harness team published a new article, "Super-agent Design Exploration: Towards More Autonomous Agent Systems".

Now let's talk about it, it's not too late, right?

Mainly because I read this article carefully, time understanding and digesting output are all costs, so I wrote it today.

And I do think that such an article needs to be digested well, but I saw many big accounts publish the article half an hour or even an hour after the official release, hmm, maybe that's what big shots do :)

The DeepSeek Harness team (hereinafter referred to as the DSH team) first explained, which matches our expectations: in the past year, as model capabilities have strengthened, and multi-agent capabilities have improved, humans are less and less involved in underlying execution, and more in top-level decision-making and acceptance.

Similarly, with the strengthening of model capabilities, tools like OpenClaw from earlier this year have evolved into the new form: Personal Agent.

I noticed that the DeepSeek team hasn't made a dsh bot yet, and the bots currently circulating are all community-developed, for example this one.

I've talked about Personal Agent before, and it's not really innovative; it's just made more usable and with lower latency.

The DSH team's logic is that current mainstream agent designs are still hard to support the Personal Agent model at the scale of multi-task and team collaboration, because current agent work is still in the form of a single Session, where sessions are independent of each other, and manual switching between sessions is hard to keep up with in terms of personal attention. They observed that personal attention can only focus on about 3-5 sessions.

I thought about my own situation of burning tokens, and it indeed fits the 3-5 session logic; anything more and I really can't remember what's there, and the effect greatly decreases.

The upper bound of a single task depends on model capability; the upper bound of multiple tasks depends on human attention.

Even if you solve extensibility through MCP, you still suffer from context confusion, single-session synchronous blocking, and other issues.

Based on this, the DeepSeek Harness team proposed a Super-agent architecture.

The core is to break the context between single tasks, making the agent a Super Agent that can maintain context across sessions and drive multiple tasks.

Dear readers, do you remember the Claude Code architecture I talked about a couple of days ago?

It uses a single Agent + Main Loop, extracting suitable subagent business processes as Skills, and system read/write to Tools/MCP. Subagents that need to be kept can still be called by the main agent via tools.

That Claude article mainly discussed whether repeated handoffs among multiple expert agents within a task lose information and increase latency. This DSH article mainly discusses how to advance a set of tasks in parallel over the long term while requiring less human oversight. The former simplifies the reasoning structure within a task; the latter organizes execution across tasks.

The DSH team published an architecture that allows developers to continuously advance between IM terminals and GitHub, and also observe feedback in groups, evaluate and locate related problems, then actively fix them.

This Super-Agent architecture is characterized by being continuous, efficient, proactive, and persistent.

This reminds me of yetone, the author of Magpie, who also shared his workflow earlier.

His approach is three /loop loops: one watching GitHub to decide whether to fix, one watching x for feedback, one watching code to see if it needs cleanup.

So that's how /loop can be used! I now understand why my previous use of /loop for iteration ran for 72 hours and produced a pile of shit.

But for the DSH team, a single ReAct Loop cannot support the four characteristics of a Super-Agent architecture; ultimately it has to start from computer fundamentals.

At this point, you realize that all agent architectures, no matter how they twist, can't avoid those underlying computer concepts.

For example, session sharing, caching, fork threads and child threads in the CPU, worktrees, filesystem.

They proposed an architecture pattern.

This architecture is mainly divided into five parts.

• Dual-layer architecture
• Event-driven
• Multi-channel interaction
• Separation of compute, state, and environment
• Watchdog

Let's discuss them one by one.

Dual-layer architecture

To achieve continuous and efficient concurrency for multiple tasks, the system faces a tradeoff between throughput and continuity at the underlying level.

If all work is given to a single Session, although task continuity is high, it faces low efficiency, slow execution, and low throughput.

But if you use enough Sessions, although throughput is high, you face continuity issues, session fragmentation, and overly independent tasks.

So how to balance is critical.

Based on this, the DSH team proposed a Router and Worker layer mechanism. The Router layer is responsible for human interaction and coordination, while the Worker layer executes specific tasks. The architecture diagram is as follows.

In the Router/Worker dual-layer architecture, the system takes over context management and concurrency at the underlying level, thereby de-emphasizing Session from the user side, so the user always sees a Super-agent.

This reminds me that many multi-agent open-source projects and products also need to treat the user as a project manager, which is not the right approach from the user's perspective. Session should not be a burden to the user.

The Router layer is a persistent global routing layer where all cross-task information and decisions are aggregated; it does not execute specific tasks. From a role perspective, it's like a secretary and a chief steward.

Although the Router makes decisions, it is also a multi-node structure, just like Agent Teams. However, in Agent Teams, the Team Lead manages specific task details, while in the Super-Agent architecture, the Router only handles distribution. According to DSH team's advice, this layer often does not need the most extreme model; using a lightweight model can balance speed and effectiveness.

The Worker layer executes specific tasks. Each Worker has isolated context, mounts full execution tools, and focuses on a single task in its own context. Because it involves actual work, this layer needs the most capable model.

No way around it; the ones actually doing the work have the strongest abilities.

When multiple tasks run simultaneously, each Worker advances independently, and Workers don't need to communicate with each other.

Similar to the Router, the Worker is also multi-node, and a Worker can fork subagents when executing complex tasks; a Worker itself can become an Agent Team.

The following diagram vividly describes the responsibilities of Router and Worker.

This architecture essentially de-emphasizes the Session side; this Super-agent side is both the user-side interaction and the underlying entry point.

Event-driven

We know that our daily use of LLMs is pull-based: we input a prompt, and the LLM responds to it.

The DSH team proposed the concept of Trigger. In Super-agent, environmental events such as group chat messages, emails and schedule reminders, code review comments, CI results, etc., are called Triggers, acting like triggers. With Triggers, the Super-agent can proactively discover and execute tasks.

Around a task from discovery to handling, it goes through a complete lifecycle.

Including event filtering, event routing, context organization, and proactive action.

In real scenarios, most messages are meaningless or don't need an Agent to handle. If a message requires Agent involvement, the first step is filtering to remove noise. The DSH team's noise reduction has two layers.

The first is program-level strategy, also called Fast Path, which filters noise.

The second is semantic-level strategy, the Slow Path. Messages that pass the program-level filter go into the LLM, which decides whether action is needed based on prompt-based strategies and context.

After filtering, it should go to the Router layer for forwarding. With a large number of requests, the Router layer could become highly loaded. So the DSH team optimized: after Fast/Slow Path filtering, messages are directly routed; the global Router only handles cold starts of new tasks and cross-task coordination. Filtered messages go directly to the Worker without passing the Router.

I made a small animation of this. Most messages die at the first layer; the model doesn't even get to judge them. The rest go to the semantic layer.

The DSH team calls requests with continuous/complete context a Thread, such as a GitHub Pull Request, the back-and-forth under the same email, or messages under the same IM topic.

A Trigger is a point; a series of related Triggers forms a line, and that line is a Thread.

In the diagram, three Threads come from IM, PR, and email respectively. They might be different facets of the same thing, or three parallel tasks; the key isn't whether they are the same thing, but that a Worker can subscribe to several simultaneously.

Once Threads exist, the next question is: when new messages arrive, where should they go?

This diagram shows two paths.

The first is the Slow Path: when a Thread just appears and no Worker has claimed it, the Router decides who it belongs to, then creates a Worker and subscribes it to the Thread.

The second is the Fast Path: once a Thread is subscribed, subsequent messages are directly delivered to the subscribing Worker.

When an event enters a Session, the issue of context injection arises: how much context to inject. Too much crowds the window and dilutes model attention; too little causes the model to repeatedly call tools to read, increasing execution rounds. Wasting context window is a big taboo.

Here, the DSH team again borrows the concept of compiler optimization from computer systems (as we said, the underlying stuff plays a big role).

They proposed Inline and Spill.

Inline refers to directly inlining information that is likely needed soon into the current context window, to save extra tool-call round trips. Spill refers to keeping complete information that exceeds window budget or is low-frequency outside the context window, retaining only references or summaries in the window for the model to read on demand.

I think of it as a workbench: keep frequently used items at hand, put the rest in a filing cabinet.

When I see Inline/Spill, my first thought is OS memory page swapping.

The similarity is in the thinking: the window is limited, bring in frequently used pages, swap out the infrequently used, and maintain a page table in the window.

The difference is who does the swapping. OS page faults are handled automatically by hardware and kernel; the program doesn't know. LLMs don't have this mechanism. After something is spilled, the model must realize "oh, I have a reference here" and then actively call a tool to read it back. Whether to read and how much depends entirely on its own judgment.

So this approach actually demands more from the model: it has to know what it's missing. This also explains why the same Inline/Spill setup can produce very different results with different models.

Along with Inline/Spill, there's an interesting thing called Chain of Recall.

The system assigns IDs to objects like Trigger, Thread, and Worker, and injects the next-hop ID when needed. So these objects form a reference graph at the bottom.

Suppose you ask in a group: "How's that issue from yesterday?" The Router only has the message, but the message has the Thread ID. Following the Thread, you can find the Worker handling it; the Worker's state contains the PR's Thread ID; and then you find the modification records.

This chain-of-recall approach doesn't rely on a huge memory bank but on a map that can be rendered in real time.

Borrowing the idea of Speculative Execution from computer systems, the Agent can, when unsure whether a result will be adopted, proactively attempt in the background based on environmental signals, consuming extra background compute to reduce human waiting and involvement costs. If the result is valuable, deliver it; if not, discard it.

Multi-channel interaction

Above we covered noise filtering and routing. Here DSH talks about details of user interaction.

Students who have studied computer networking know the concept of full-duplex communication: information exchange is bidirectional and non-blocking. The DSH team uses asynchronous ReAct Loop to eliminate blocking of foreground dialogue by background time-consuming operations, allowing the conversation to accept new commands at any time without waiting for the previous command or task to complete.

I suspect those who have recently tasted fine grains will know this.

Traditional ReAct is one question, one answer: you ask a question and can only ask the next after the answer completes. This is blocking. Now it becomes full-duplex, an asynchronous ReAct Loop.

On the left is the old ReAct: a run() call, and the whole loop blocks waiting for the result. If you send another message, it queues behind.

On the right is asynchronous: start() immediately returns "started", then continues the loop, calls tools, and returns results after execution.

I specifically looked at ChatGPT and Claude Code: both already have similar capabilities, just with different names and implementations.

Claude Code's subagents are divided into foreground and background: background ones can run in parallel with the main dialogue and deliver results via notifications when done; foreground ones still block the main dialogue.

On ChatGPT's side, while a long task is running, you can continue adding requirements or modifying constraints.

This asynchronous task mechanism is already implemented in DeepSeek Harness but not enabled by default.

Separation of compute, state, and environment

In this section, the DSH team cleverly proposes a concept of Compute-Storage Separation.

I had to read this section three times to figure it out....

Compute is the process of the Agent Loop running; state is the session records and task records left behind; environment is the actual code repository, local files, and toolchain where work happens.

The current problem is that if all three are on one computer, when the computer shuts down, the Agent can't work; if you switch computers, the local environments are gone.

DSH uses two steps to decouple.

First, separate compute and state. The Agent Loop goes into a replaceable cloud container; session state is stored separately in a database. If the container dies, you can replace it, and the state remains, so you can continue executing tasks.

Second, separate compute and environment. Many people's first reaction is to move the local environment to the cloud, but real environments contain uncommitted changes, private credentials, specific hardware, and toolchains. If you move everything to the cloud, the results will likely differ and you'll encounter tricky issues. So their approach is the opposite: keep the local environment where it is, and install a lightweight daemon on the endpoint that only executes commands and sends results back.

This is BYOM, Bring Your Own Machine. Your personal computer, even a machine that only comes online occasionally, can connect this way.

However, there's a precondition: cloud and endpoint must trust each other. Once the cloud is compromised, all connected devices are at risk.

Watchdog

To achieve persistent online status, besides the compute/storage separation, you also need to recover from abnormal states.

A persistent distributed system can hardly rely solely on the main system's internal logic for long-term reliability; you need an independent external control loop outside the main system, i.e., a Control Loop.

When designing keep-alive for agents, many people just build a bunch of heartbeat and keep-alive scripts. But in agent systems, traditional process liveness detection or monitoring scripts are not enough. Often the problem is not process loss but deadlock in the LLM internal loop or deviating from execution goals.

A mechanism is needed to break this. The DSH team configured a Watchdog Session.

The Watchdog is driven by timed messages; its role is to intervene promptly to detect anomalies, correct deviations, and recover from failures.

The Watchdog is also an Agent Session; developers can ask it about error causes and adjust in time.

Afterword

Finally, I want to say that when I saw this, I was very excited.

Many large models on the market are playing with concept hype, fizzling out after a couple of days, then moving on to the next hype.

So when someone who has seriously worked on infrastructure sees what the DSH team says, I feel a sense of "why didn't I meet you earlier."

Finally, there's a serious team that can start from the bottom, rather than playing with a bunch of tools and skills. No matter how you optimize, on the Transformer attention mechanism it's still pulling cards.

Rather than creating flashy things to attract attention, it's better to optimize the underlying layers. I think this is DeepSeek's path to AGI.