DeepSeek splits Agent into Router and Worker, cutting p95 task time in half

DeepSeek published a long English article on the Super-Agent architecture, and its core design can be summed up in one sentence: split the agent into two parts. The Router only talks to the user and is responsible for assigning tasks to Workers; each Worker runs one task in an isolated environment. The featured video shows a concept diagram: on the left is you, in the middle is the Router, and on the right is a row of workstations handling GitHub fixes, replying to messages, checking the calendar, and drafting emails, respectively.

The split is not complicated. Someone in the comments explained it with a single diagram: the Router stands between the user and the Workers, tasks are routed away, and execution is isolated. The simpler the concept diagram, the easier it is to overlook the engineering challenges. Scheduling, result aggregation, failure retries, and permission boundaries all have to be implemented in the system.

The early test numbers are more direct: p95 task time was 15.7 minutes, versus 29.5 minutes for a single session. p95 looks at how many minutes 95% of tasks fall within, and a long tail still exists. This result shows that the split helps with waiting time; at least in this set of early tests, task time was nearly halved. There is also a TL;DR image in the comments that compresses the long article into a few sentences, which is useful for reading the conclusion first and then going back to the original.

Some commenters point to human attention bandwidth as the bottleneck, with model intelligence coming after it. A traditional monolithic agent is like one person taking on all the work at once: conversation, context, and execution results are crammed into one session, and the user can only wait serially. The Router narrows the conversation entry point, while Workers isolate execution, so users no longer have to watch every task and switch back and forth. This judgment comes from the comments, not an official conclusion, but it explains why splitting into workstations can save time.

A bit of skepticism is still warranted. Someone in the replies asked: the readme says some capabilities have not yet made it into the prototype, so what comes next? What the feature provides is also just early tests and concept diagrams. The division of labor between Router and Worker looks smooth, but the truly difficult parts are how to recover after a task fails, how Workers avoid duplicating work, and how results are merged into a paragraph the user can read. When reading the long article, do not mistake the concept diagram for a product that has already shipped.

The long article link is here: https://x.com/i/article/2116829218935857152
Quoted tweet: https://x.com/DeepSeekHarness/status/2116857257245987236

The latter half of the same thread switches to Amoeba Farm. DSH users can provide data sources to the Amoeba Farm oracle to earn bounties. Sources are published as Heads, backed by $AMBA; submissions use a bonded claim with data and web evidence, and can be completed in Petri or the DeepSeek plugin. Bad data can be challenged, and the bond will be lost. Q4 2026 is already open; the entry point is http://amoeba.farm/oracle.

The external page shows that the Oracle publishes the price source behind each market, advancing month by month, from proposing sources to reporting changes with public evidence; accepted contributions receive rewards from a limited budget. The page shows markets such as RAMX and NANDX, with sources including memorymarket's RDIMM, SODIMM, and UDIMM price records.

This thread puts two things together: the Agent is split into Router and Worker, and data collection is split into bounty tasks. Workstations can be isolated and tasks can be assigned, but in the end, it is still people who feed the system price sources, web evidence, and challenge bonds. Human attention bandwidth has not disappeared; it has just switched to a more granular unit of account.