DeepSeek's super-agent: one always-on router, many silent workers — and human attention as the real bottleneck

DeepSeek did not announce a new model on October 31. It published something quieter and, for anyone running coding agents against a real codebase, arguably more useful: a systems design for agents that keep working across chat threads, inboxes and pull requests without a human playing traffic controller. The full text of the DeepSeek Harness team's article, titled “Super-agent Design Exploration: Toward More Autonomous Agent Systems,” reads less like a product launch and more like an engineering notebook — including the parts the team has not solved yet.

The diagnosis comes first, and it is not about model quality. Single-task agents have proven they can solve complex problems with less supervision, and stronger models are spawning personal assistants wired into messages, calendars, email and work platforms. But mainstream designs still take a single session as the basic unit, with sessions independent of one another. Run several tasks at once and the user must switch sessions manually and remember each one's context. According to DeepSeek's observations, a person can usually follow only 3 to 5 active sessions at the same time. “The upper limit of single-tasking depends on model capability, while the upper limit of multi-tasking depends on human attention,” the team writes. Bolting on a CLI, an MCP server or an external connector does not fix it: the agent still blocks on one synchronous session, mixes contexts across tasks, and stops when the local device goes offline.

Router up top, workers down below#

The answer is a dual-layer architecture. A resident router layer handles every human interaction, holds the global context and memory, and dispatches tasks. It does not execute tasks directly — it may not even be given shell tools — and because routing is mostly lightweight, DeepSeek says lighter models can often carry it. Below it, a worker layer of context-isolated sessions executes one task each with a full toolset and never replies to humans directly. Workers report status and results to the router, which answers the user in one voice, so nobody gets five competing replies from five sessions.

Sessions become an implementation detail rather than something the user manages, and workers sharing a pull request subscribe to the same event thread, giving them a chance to spot conflicts themselves. The team is explicit that this is borrowed thinking from traditional computer systems.

Events in, noise out#

For the agent to be proactive, the input changes. Instead of waiting for prompts typed one by one, the super-agent listens to semi-structured events — group chat messages, emails, calendar reminders, code review comments, CI results — which DeepSeek calls triggers. Most of that stream is noise. Events therefore pass through two filters before any large model is consulted: a programmatic fast path drops the obvious irrelevance by source, group scope and whitelist, and a semantic slow path lets the model judge only the candidates that need understanding.

Routing follows the same fast/slow split. The router cold-starts new tasks, but once a worker owns a thread of events — one pull request, one chat topic — later events go straight to that worker. Context is rationed too: the design inlines information likely to be needed soon and spills the rest outside the window, keeping only references — Inline & Spill. Objects carry IDs of their neighbours, forming a reference graph the model walks hop by hop (Chain of Recall) to recover an old task from another channel. Output is matched to the channel: instant messaging gets replies of no more than 100 words, only when a decision is needed, while GitHub and email get structured delivery. The asynchronous loop behind it is implemented in DeepSeek Harness but not yet enabled by default, the article notes.

Built to stay online#

Persistence is treated as architecture, not hope. Today's local agents bind the loop, the session state and the execution environment — repository, toolchain, credentials — to one device, so sleep or a dropped connection ends the run. DeepSeek decouples all three: the loop runs in stateless, replaceable cloud containers, session state lives in a database, and the heavy execution environment stays where it is, reached through a lightweight daemon holding no session state. That keeps uncommitted changes and credentials in place instead of forcing a cloud migration, and supports BYOM — bring your own machine — including intermittently online devices.

Then comes the watchdog: an independent session outside the main system, driven by timed messages, forming an external control loop. Many agent failures are not crashes — a model stuck in an ineffective loop looks alive to a process monitor — so the watchdog judges whether each worker is making real progress in the right direction, intervenes when it is not, and re-checks until things are normal. Maintainers can ask it in plain language why something failed and have it correct the main system, for instance by adjusting prompts or trigger rules.

A prototype, not a product#

Some of the design is already code. The article points to dsh-superagent-prototype, a bundle for DeepSeek Harness that turns events from Feishu and GitHub into managed agent tasks. DeepSeek is careful about what it is: “This plugin is merely a prototype provided to validate the technical route and is not an official product of DeepSeek.” It is published under the MIT license and, according to AI Frontier Daily's October 31 roundup, crossed 2,100 GitHub stars on its release day. The repository describes itself as grown out of the team's daily development work, with much of the engineering done by coding agents.

A close read of the prototype's design documents shows the attention budget in the plumbing. Events and permissions are separated into five primitives — Sources, Triggers, Threads, Mandates and Tickets — with a stateless evaluator deciding whether a trigger becomes work and an immutable mandate fixing each ticket's scope. Each ticket gets its own isolated git worktree; commands over five seconds move to background jobs capped at thirty minutes. When a human is needed, the agent writes to a structured attention field, which parks the ticket and posts a single structured question to the original channel.

What the early numbers do — and don't — show#

DeepSeek ran preliminary experiments on synthetic loads and simplified environments, and says so plainly: the results are “only for preliminary reference.” Each run drove about 300 messages (about 20 work requests) through group chat and GitHub CI streams, five times per design, with coding work replaced by a time-consuming stand-in — so the test measured scheduling, not task quality. The design finished tasks in a median 12.4 minutes and 15.7 minutes at p95, against a 29.5-minute p95 for a single session under a neutral prompt, where the model never invoked a subagent in five runs. Overhead is reported, not hidden: removing direct-access routing raised the router's cache tokens from 23.23 million to 31.77 million per experiment, about 37%. Scaling the router, long-term memory and security remain open questions.

What to watch#

The test now is whether the prototype hardens into something teams run, and whether the framing spreads: human attention as the scarce resource, with architecture — not prompting — doing the rationing. The design is already dogfooded: an internal instance runs continuously on issue reproduction, code review and iteration on DeepSeek Harness itself.

Sources: ChainCatcher's full text of the DeepSeek Harness team's article; PANews' October 31, 2026 report; Reid Marlow's October 31, 2026 read-through of the prototype's design documents; and AI Frontier Daily's October 31, 2026 roundup, checked October 31. Images are AI-generated editorial illustrations.