DeepSeek published the blueprint for an agent that runs a whole team's work
Synergised Consulting Ltd
Last Updated: 3 November 2026
DeepSeek's research team has published a design essay describing a "Super-agent": one continuous agent, split into a coordination layer and an execution layer, that listens for events, runs tasks in parallel and recovers from failures on its own. It ships with an open-source prototype on GitHub. The important detail for anyone planning an agent deployment is not the name but the shape: the work of coordinating tasks is deliberately separated from the work of doing them, and the parts most likely to cause damage, acting without being asked, are switched off by default.
What DeepSeek Actually Published
What appeared on 1 November is an architecture essay, not a product. The DeepSeek Harness team sets out five modules that an always-on agent needs: a two-level router-and-worker structure, event-driven triggers, full-duplex interaction across channels, separation of the agent's compute from its state and environments, and an external watchdog that keeps the system alive and explains its own failures. Alongside the essay sits dsh-superagent-prototype on GitHub, MIT-licensed [1].
The gap between the two matters. The prototype's own README describes it as research code, "not an official DeepSeek product", adapted for publication and not identical to the internal system, with some designs in the essay left as future direction rather than shipped behaviour [2]. What the prototype actually is: a proactive coding agent for one GitHub repository, which listens for requests, opens a work item, runs it in its own session and directory, and answers in the original conversation. That is a long way from the always-on agent for a whole team that the essay sketches, and anyone reading coverage of this release should hold the two apart.
The essay itself is explicit that its purpose is architectural. It argues that today's agents are built around a single session, that a person can usually follow only 3 to 5 active sessions at once, and that multi-tasking is therefore limited by human attention rather than model capability [1]. Everything in the design follows from attacking that constraint.
One Dispatcher, Many Workers
The core of the design is a two-layer split. A long-lived Router session receives every human message and every event, holds the global picture, and dispatches work. It deliberately does not execute tasks; the essay notes it can run without a shell at all, and that a lighter model is usually enough for the job. Worker sessions each own one task with an isolated context and a full tool set, and they never talk to humans directly: they report to the Router, which handles all replies [1].
The distinction from a familiar "agent team" is worth pausing on. A team lead coordinating one complex task has to understand every dependency and direct each step. DeepSeek's Router is closer to a dispatcher: it decides which task goes where and tracks how tasks relate, without decomposing any of them. Coordination and execution get different models, different tool sets and different lifetimes, because they are different jobs [1].
This is an illustration of the shape, not a tested deployment. A customer reports a bug in a group chat. The Router receives the message, opens a task, and hands it to a Worker, which investigates in its own isolated context. A pull request appears; a reviewer comments; continuous integration fails. Each follow-up event routes straight to the Worker that owns the thread, without a new routing decision, and the human sees one thing: what needs their decision. Nothing in the published material demonstrates this end to end on real work, but the division of labour is the transferable idea.
What the stress test actually measured
The essay includes one stress test of the Router layer alone, and the authors attach their own caveat: synthetic workloads, simplified environments, results "indicative only". With that caveat carried, the numbers describe the batching mechanism: as decision-requiring events rose from about 1 to about 40 per minute, the average batch grew from 1.0 to 2.8, time per request rose only from 2.5 seconds to 3.9 seconds, and the amortised inference time per decision fell from 6.4 seconds to 1.6 seconds. In bursts, the Router merges queued events into one pass, so each decision gets cheaper as the backlog grows [1]. It is the same idea as group commit in databases, applied to model inference.
Events In, Noise Out, Action Gated
An agent connected to real chats and code platforms sees far more input than it should act on, so the design filters in two stages. Deterministic code applies stable rules first: which source produced the event, which users or bots are allowed, whether that source should be ignored or only respond to direct requests. Only candidate events that survive those checks reach the model, which judges them against policies written as prompts [1]. The cheap, predictable decision happens in code; the expensive, flexible one happens in the model, and only when needed.
What gating looks like in the prototype
The proactivity question, the one that decides whether an owner should let an agent near live systems at all, is answered with a switch. The prototype documents three accept modes: off, observe and auto, with observe as the default. In observe mode the system records what it would have accepted without starting any inferred work; only explicit requests proceed. Accepted work then runs under a scoped mandate, and receiving a new event does not expand that mandate [2][3].
That default is the most consequential design decision in the whole release. The interesting failure mode for an agent in a business is not doing a task badly, it is doing a task nobody asked for. Starting an agent in a mode where it can only record its intentions turns the first weeks of deployment into an audit: the owner reviews what the agent would have done, decides which of those behaviours to authorise, and graduates autonomy on evidence. The essay's authors, running their own internal instance, describe precisely this pattern: their agent monitors public group chats and, even unmentioned, investigates reported issues and opens fixes, but communicates only when it has a confirmed root cause [1].
What It Cannot Do Yet
The honest list is long, and it starts with status. The prototype is research code, not production software, published in adapted form and not identical to the internal system that produced the essay's results [2]. The internal instance the authors describe is theirs, on their workload, at their team size; the essay itself says the right structure for larger, more tightly coupled work "is not yet settled" [1].
The security gap
Security isolation is the sharpest edge. The prototype's deployment guide runs both the Router and Worker presets with full access, as the operator's operating-system user: wrappers and separate directories are not a sandbox, and the process can reach anything that user can, including the home directory. The guide's own recommendation is to run the agent under a dedicated OS account for isolation [2][4]. DeepSeek has published an architecture for autonomous agents before publishing the permission model that would make one safe to deploy, and a business adopting the pattern has to build that layer itself.
Coordination has limits too. Shared event subscriptions make overlapping work visible to the Workers involved, but visibility is not a lock: two Workers editing the same code can still conflict, and nothing in the design guarantees resolution [1][4]. Long-term memory across months of operation is named by the team as an unresolved problem [4]. And the watchdog, the component that watches for failures and repairs them, comes with no detection accuracy, no repair success rate and no security evaluation; it is itself an agent with tools, which means its own permissions and mistakes matter [4].
The Part an Owner Can Use
Strip away the branding and the essay describes an operating pattern that has nothing specific to do with DeepSeek: separate deciding from doing; filter events with cheap deterministic rules before spending model attention on them; start automation in a mode that can only record what it would do; and give something whose only job is watching for failure. Those four moves apply to any workflow an owner is considering delegating to software, whether or not a large model is involved.
The attention arithmetic is the part that lands in a first hundred days. The essay's authors put the human limit at 3 to 5 simultaneously trackable sessions [1]; the constraint is theirs to state, and it matches what owners describe in practice. In discovery conversations, the picture that surfaces is rarely a capability gap: an owner considering an agent deployment is usually imagining one more chat window to supervise, on top of everything else, and the honest answer is that a deployment structured that way fails on attention before it fails on capability. The blueprint's value is that it names the alternative: the human sits above a dispatch layer that answers for the work, sees only what needs a decision, and reads a record of what the system would have done unprompted before deciding what to authorise. Autonomy gets graduated the way any other delegation to a new starter does, except that this architecture builds the record-keeping in rather than leaving it to policy documents.
None of this makes the Super-agent a product, and the prototype's own documentation says not to treat it as one [2]. What it does do is put a worked reference design, with its stress-test data and its security gap both in the open, in front of anyone structuring their first serious agent deployment. Reading how DeepSeek drew the line between coordination and execution, and between observing and acting, is a better preparation for that decision than any vendor's deployment page.
Sources
- [1] [1] DeepSeek Harness, "Exploring Super-agent Design: Towards a More Autonomous Agent System", published 1 November 2026:
- [2] [2] deepseek-ai/dsh-superagent-prototype, README and deployment documentation, GitHub, MIT licence:
- [3] [3] MarkTechPost, "DeepSeek Open-Sources dsh-superagent, a Router-Worker Coding Agent", 1 November 2026:
- [4] [4] kingy.ai, "DeepSeek Super-agent Design Explained: Architecture and Results", 2 November 2026:
