TL;DR

On October 31, 2026, the DeepSeek Harness team published a design essay, Exploring Super-agent Design: Towards a More Autonomous Agent System, together with an MIT-licensed research prototype called dsh-superagent-prototype. It is not a new model. It is a proposal for the system that sits around the model.

• The thesis: the limit on agentic coding is no longer the model. It is the person who has to babysit three to five agent sessions at once.
• The answer: one long-lived Router that talks to people and dispatches work, plus isolated Workers that each own exactly one task.
• The most useful finding: telling a single agent to delegate does not work reliably. Delegation has to be built into the structure.
• The numbers: encouraging but synthetic. Median completion of 12.4 minutes against 20.4 for a single session, at about 3.8 times the cache reads.
• The prototype: honest about itself. Research code, full OS-user access, one GitHub repository, optional Feishu, proactive work off by default in favour of an “observe” mode.

My verdict in one line: the architecture is worth stealing, the code is worth reading, and nobody in a bank should run it as is.

First, Get the Names Straight

Half the posts I read this week mix up three different things. “DeepSeek SuperAgent Harness” is the label the community stuck on the combination, but the layers matter if you want to evaluate any of it.

Name	What it is	Released
DeepSeek Harness (DSH)	Open-source, MIT-licensed coding agent runtime. Everything is a plugin, including the agent loop, on top of a composability framework called Cordis. Works with other providers and OpenAI-compatible endpoints.	August 13, 2026, alongside DeepSeek V4 Pro
Super-agent design essay	An architecture proposal for an always-on, multi-task agent system. Credited to Yujia Qiao on behalf of the Harness team.	October 31, 2026 (WeChat and X)
dsh-superagent-prototype	TypeScript bundle v0.1.0 that runs as a dedicated DSH profile. One GitHub repository, optional Feishu, a local web panel.	October 31, 2026

The prototype is not a fork. It is a set of DSH plugins: a core Super Agent plugin, a GitHub watcher and a Feishu watcher, wired in through a Cordis patch file, plus stripped-down Router and Worker presets.

One caveat I will keep coming back to. The README says the public code differs from DeepSeek’s internal system, and that some designs in the essay are future directions, not features. In this article, “the design” means the ambition and “the prototype” means the code. I label which is which.

The Real Bottleneck Is You

DeepSeek’s starting point is something every heavy user of Claude Code, Codex or Copilot agent mode already feels. One agent fixing one bug is solved. Ten agents on ten tickets is a different job, and that job lands on you.

The team’s observation is that a person can follow roughly three to five active sessions before things slip. You forget which session is waiting for an approval, which one is stuck in a loop, and which two are quietly editing the same pull request. It is a field observation, not a measured law, but I have never met a developer who disagreed with it.

The essay frames four goals for an agent system that removes this load:

• Continuous: a change of direction in a PR review reaches the work that started in a chat thread.
• Productive: several tasks move forward, and new instructions land while old commands still run.
• Proactive: the agent reacts to relevant events under policy, and stays silent when it has nothing useful to add.
• Persistent: it survives restarts and network drops, and recovers from operational faults.

The principle the prototype puts in its README says it best: take as little human attention as possible, and give as much value as possible. I would print that on the wall of any team building internal agents.

The Architecture: One Router, Many Workers

The design rejects both obvious options. Push every event into one giant session and you get shared context, but the session does one thing at a time and unrelated tasks bleed into each other. Spawn a fresh session per event and you get speed, but no continuity, and several agents answering you at once.

The compromise has two layers.

• The Router is one long-lived session. It receives interactions, keeps a high-level map of tasks and how they relate, dispatches work and handles replies to humans. It does not write code. The authors suggest it can run with no shell at all, which removes the temptation to do the work itself. A lighter, cheaper model is enough for it.
• Workers each own one task in an isolated context and working directory. The strongest model goes here, because Workers produce what you actually judge. A complex Worker can open its own subagents or an agent team, invisible to the Router.

Every event crosses a cheap code gate before any model sees it. Once a Worker owns a thread, later events on it skip the Router.

This inverts a habit I see in most enterprise agent pilots, where the “orchestrator” gets the premium model. DeepSeek’s Router does not decompose problems. It assigns and tracks. That is a cheaper job.

From noise to work: Triggers, the gate and Threads

An always-on agent receives far more input than direct requests. Chat messages, PR comments, CI results and calendar reminders all become Triggers, and most of them deserve nothing.

1. A deterministic gate filters first. Plain code checks the source, the sender against an allow-list, bot lists, and whether the agent was addressed at all. No model call is spent on obvious noise.
2. A model assesses what survives. Candidates are judged against plain-language rules the team writes.
3. Accepted work becomes a Ticket with a Mandate. The Mandate records who asked, under which rules and policy version, and how far the work may go.

Related events are grouped into Threads: a PR and its review comments, a chat topic and its replies. Once a Worker owns a Ticket, it subscribes to the Thread, and later events go straight to that Worker by code, without a new routing decision. DeepSeek calls this pass-through. Subscriptions are many-to-many, so two Workers on the same PR see the same events. That gives them a chance to notice a conflict. It is not a lock.

Context as a cache, and the chain of recall

The essay borrows two ideas from computer systems. Inline puts likely-useful material straight into context: nearby messages, a reply’s parent, neighbouring review comments. Spill keeps the rest outside, behind a short summary and an ID that can be expanded later.

Because events, Threads and sessions all reference each other by ID, the Router can walk from a new comment to its Thread, from the Thread to a Worker session, and from there to a discussion from weeks ago. DeepSeek calls this the chain of recall. It is a retrieval path, not a guarantee that the model picks the right history. The team itself lists long-term memory as unsolved.

Proactive, but With a Reason to Stay Quiet

This is the part I found most mature, and it is where the prototype is more careful than the hype around it.

Context is not authority. In the prototype’s authorization model, the host enforces allow-lists, rules and Mandates. Messages, comments and quoted documents are inputs to a decision. They cannot change permissions. A comment arriving on a subscribed Thread reaches the Worker as context and grants nothing new.

Three acceptance modes for proactive work:

Mode	What happens to inferred work (unaddressed messages, bot messages, follow-ups from people not on the list)
off	Nothing inferred becomes a candidate
observe (default)	Candidates are assessed, and a positive result is logged as “would accept”. Nothing runs.
auto	A positive assessment accepts the work

Explicit requests from allowed people work in every mode. The documented advice is to start in observe, read the logged decisions, and only then switch to auto. DeepSeek reportedly ran its own internal deployment the same way. If you take one thing from this release into your own agent platform, take this.

A few more details worth knowing:

• Bots cannot give orders. A listed bot such as Dependabot can produce an inferred candidate, never an explicit request, and it cannot stop a Ticket.
• Mandates are revalidated. Change the policy, remove someone from the list, and a waiting Ticket can lose its Mandate before it resumes.
• Stop is a human act. A person saying “stop” in a thread goes through evaluation. A stop in the panel is a direct command. A Worker cannot declare on its own that someone asked it to stop.

Silent reproduce-and-fix. Internally, DeepSeek uses a policy where a bug reported in a chat is reproduced in the background. If the agent confirms the bug and finds a fix, a pull request shows up while the conversation is still going. If not, nobody hears about it. Speculative work costs compute, but it is cheap to throw away. A posted comment or a merged change is not, which is why the authorization boundary sits there.

The Runtime: Full-Duplex, Your Own Machines, a Watchdog

Long commands should not hold the conversation hostage. In the design, a tool can start a background job, hand control back to the agent loop, and deliver its result later as an event. The team calls this full-duplex: you can send a correction while a ten-minute build runs. In the prototype, any shell command still running after five seconds moves to the background, so a Worker keeps receiving messages. The essay notes that the general async mechanism exists in DSH but was not on by default.

Separate the agent from its machines. A local agent usually ties three things together: the compute running the loop, the session state and the environment where commands execute. Close the laptop and all three disappear. The design pulls them apart in two steps. State lives in persistent storage, so the loop can restart anywhere. Then the loop reaches execution environments through light endpoint daemons. DeepSeek calls this Bring Your Own Machine: your laptop, with its uncommitted changes, its GPU, its intranet access, becomes one endpoint among cloud sandboxes. The team credits Anthropic’s managed-agents work for the brain/hands split and puts its own emphasis on personal machines with intermittent connectivity. To be clear, this is design, not something the prototype ships.

A Watchdog for agents that are alive but stuck. A process can run and make zero progress: retrying the same failing command, losing track of its task, waiting on a dead dependency. The design proposes a separate agent session, woken on a schedule, that checks infrastructure, judges whether Workers are progressing, and attempts repairs. No detection or repair rates are given. The prototype only documents an external hourly status-and-recovery check, which is far narrower.

Communication discipline. The team reports that capping instant-message replies at about 100 words worked well for them, while PRs carry the full context. Detail goes where it belongs, and chat stays for decisions.

The Numbers, and What They Do Not Measure

The Super-agent finished simulated tasks about 39% faster at the median than a single session, at about 3.8 times the cache reads. Read the setup before you quote that.

Each run fed about 300 group-chat and CI messages, roughly 20 of them real work requests, the rest chatter, follow-ups and cancellations. Four designs, five runs each. The coding itself was simulated by a tool that just consumed time, and message intervals and work durations were scaled down while model calls were not. This measures scheduling, not code quality.

Design	Completion p50	Completion p95	Cache-read tokens per run
Super-agent	12.4 min	15.7 min	23.2 M
Super-agent without pass-through	12.6 min	15.5 min	31.8 M
Single session, subagent tool, neutral prompt	20.4 min	29.5 min	6.1 M
Single session, subagent tool, delegation-first prompt	13.8 min	29.0 min	10.8 M

Source: DeepSeek’s essay, as reported by Kingy AI and Dataconomy. Team-reported, not independently reproduced.

Three findings stand out to me.

1. Prompts do not produce delegation. With a neutral “use subagents when appropriate” prompt, the single session never delegated in five runs. With a prompt pushing delegation, it delegated four times, then decided the fifth job was too small and did it alone, which blew up its tail latency. Structure beat wording.
2. Pass-through pays for itself in tokens. Without direct delivery to subscribed Workers, the Router made about 30% more decisions and cache reads rose by about 37%. Latency barely moved.
3. The Router gets more efficient under load. In a separate stress test, as decisions per minute rose from about 1 to about 40, average batch size grew from 1.0 to 2.8. Each model call slowed from 2.5 to 3.9 seconds, but amortized time per decision fell from 6.4 to 1.6 seconds. One Router can plausibly serve a team before you need to shard it.

On cost, DeepSeek’s argument is that this design only makes economic sense with cheap, fast models. Cache reads multiply, and on flash-tier pricing that stays affordable. On frontier pricing it gets expensive fast. Missing from the evaluation: real tasks, code correctness, accepted PRs, human review time, notification load and adversarial tests. Those are the numbers a bank would actually need.

What the Open-Source Prototype Actually Gives You

The repository passed 17,000 GitHub stars in under four days. Stars are not deployments, so here is what you get if you clone it.

What it does. It watches one GitHub repository and, optionally, Feishu. When an allowed person asks for work, it opens a Ticket, runs it in its own DSH session and directory, and answers in the original conversation, usually with a pull request. A local web panel shows what needs a human. Setup is long enough that the README tells you to have a coding agent walk you through SETUP.md. The docs are numbered 000 to 008, from philosophy to a cookbook for adding a new Source, and they are the best part of the release.

Requirements. Node.js 22.19+ or 24+, Git 2.32+, Python 3.8+, tmux and GitHub CLI 2.48+, plus a compatible DSH version (^0.2.1-alpha.2). In practice it is POSIX-only. Community reports show native Windows needs patches, or WSL.

The warnings that matter:

• No sandbox. Both presets run with danger-full-access as your OS user. Separate directories are not isolation. The deployment guide recommends a dedicated OS account. I would add a dedicated VM.
• State is local. A SQLite database and a directory lock. The cloud-hosted, bring-your-own-machine system from the essay is not here.
• The reply path differs from the essay. In the prototype, Workers can acknowledge and handle follow-ups in their scope themselves. The Router does not relay everything.
• Approvals are your job. Instructions to the agent about merging do not replace GitHub branch protection.
• Expect rough edges. The prototype repo has issues and PRs disabled, so bug reports land in DeepSeek Harness Discussions. Within a week, users documented a GitHub polling stream that stalls after 100 events sharing a timestamp, late mentions getting lost, and worker lifecycle races where a retry reaches a worker after its authorization changed.

None of this is a scandal. DeepSeek said clearly that much of this code was written by coding agents and is research code. It is a reference to read and learn from, not a product to install on Monday.

My Take: Harness Engineering Just Got Its Reference Architecture

If you followed my series on prompt, context and harness engineering, this release is the third layer made concrete. The model is a commodity input. What decides speed, cost and safety is the system around it.

What DeepSeek got right

• Attention as the scarce resource. Most agent metrics count tokens or pass rates. This one counts how often a human gets interrupted. That is the right metric for a team, and almost nobody measures it.
• Delegation as structure, not instruction. Their own experiment shows a model told to delegate will sometimes refuse. If your orchestration depends on the model choosing to hand off, you have built a suggestion, not an architecture. Remove the tools from the Router and the problem goes away.
• Events instead of prompts. The agent stops being a chat window you visit and becomes a colleague who lives in GitHub and the team chat. A cheap deterministic gate in front of an expensive semantic one is plain good engineering.
• Context is not authority. Separating what an agent may read from what it may do is the single most important security idea in agentic systems. Seeing it written as a domain model, with Mandates, revalidation and policy versions, is valuable even if you never run the code.
• Observe before auto. Log what the agent would have done, review it, then grant autonomy. This is how we roll out any automated control in a bank. It is good to see an AI lab arrive at the same place.

What worries me

• The evidence is about scheduling. Faster coordination of simulated work tells us nothing yet about correct code, accepted PRs or review burden. I want those numbers before I believe the productivity story.
• The attack surface is huge. An always-on agent that reads chat threads and PR comments, runs with full user access, and can open PRs is a prompt-injection target. The Mandate limits what work is authorized. It does not stop a poisoned comment on a subscribed PR from steering what the Worker does inside that scope, like reading an .env file. The essay itself admits credentials can end up in model context during normal work.
• Invisible sessions can become invisible work. One voice for humans is great until you need to audit who did what and why. The panel is a start, not an audit trail.
• Memory over months is unsolved, and the team says so. Chain of recall gives a path to history. It does not make the model choose the right history.
• The economics depend on cheap models. Nearly four times the cache reads is fine at flash-tier prices. With a frontier model on the Workers, do your own math.

Is the idea new?

Not really, and that is fine. Supervisor and worker patterns, event sourcing, background jobs and watchdogs are decades old. Anthropic published the brain/hands separation, and DeepSeek credits it. Hosted coding agents already turn an issue into a PR. What is new is a lab publishing the whole operating model in the open: the domain model, the authorization rules, the experiment, the failures, under MIT. That makes it the most useful reference document on multi-agent operations I have read this year.

What This Would Look Like in a Bank

The pattern fits a regulated dev team well, as long as you put the controls where the design already leaves room for them. Here is a fictional but realistic walkthrough.

The setting. A twelve-person team maintains the portfolio reporting service of a private bank. A Super-agent-style system watches their Git repository and the internal support channel used by the relationship-manager helpdesk.

1. A message lands. A helpdesk analyst writes in the support channel that quarterly statements show a wrong FX rate on CHF positions. She does not mention the agent.
2. The gate decides. The channel is configured, the analyst is on the list, the message is unaddressed, so it becomes an inferred candidate. The policy has one enabled rule: reproduce reporting bugs on synthetic data, never touch production.
3. Observe, then auto. For the first weeks the system only logged “would accept”. The team lead reviewed those decisions every Friday before switching this one rule to auto.
4. A Worker reproduces it. In a dedicated VM with masked test portfolios and no production network, the Worker writes a failing test, finds a rounding step applied before conversion, fixes it and opens a PR.
5. Humans approve. Branch protection requires two approvals, one from a code owner. The agent has no merge rights. A reviewer comment goes straight to the subscribed Worker, which pushes a revision.
6. One short reply. The Router answers the analyst in under 100 words with the PR link and the expected release window. Nobody else was interrupted.

What the agent never gets in this story: production credentials, real client data, merge rights or a change-management approval. Those stay human.

Adoption checklist for regulated teams

• Treat dsh-superagent-prototype as a reference design. Rebuild the pattern on your approved agent platform, or harden a fork after a full security review.
• Run Workers in a dedicated OS account inside a VM or container, with no route to production and an egress allow-list.
• No long-lived secrets in the agent environment. Use short-lived, least-privilege tokens and run secret scanning on every agent PR.
• Synthetic or masked data only. Client data never enters a prompt, in line with banking secrecy and data-protection rules.
• Decide where inference runs. The default DSH adapter points to DeepSeek’s API, so assess the provider, or route to an approved or self-hosted endpoint. For EU-regulated groups, DORA third-party ICT risk rules apply.
• Keep the allow-list to named people and leave admission cells for unlisted senders on ignore. Never open an explicit-request cell on a broad channel.
• Start every proactive rule in observe. Switch to auto per rule, only after reviewing a real sample of logged decisions.
• Enforce approvals in the platform: branch protection, code owners, four-eyes. Prompt instructions are not a control.
• Export Mandates, decisions and policy versions to your SIEM and link them to change tickets, so an auditor can answer who authorized what.
• Red-team the event channels with poisoned issues, comments and CI logs before go-live.
• Measure what matters: human interruptions per week, accepted PR rate, review time, rework and incidents.
• Put a cheap model on the Router, the strongest one on Workers, and run your own cost numbers before scaling.

Bottom Line

DeepSeek did not ship a product. It shipped an operating model for agents, with its trade-offs, its numbers and its open problems on the table. The lesson for anyone building internal agent platforms is simple: stop optimizing the conversation with one agent, and start designing the system that spares your people from having many conversations at all.

Read the essay. Read the numbered docs in the repo, in order. Then steal the four ideas that matter, in this order: a deterministic gate, Mandates that separate context from authority, observe before auto, and a Router that cannot do the work itself.

I would love to hear from teams who try this pattern in a regulated environment. What would you put in front of the gate?

Sources

• Exploring Super-agent Design: Towards a More Autonomous Agent System, DeepSeek Harness team (English version on X)
• dsh-superagent-prototype README and 002 Authorization, DeepSeek on GitHub
• DeepSeek’s Super-agent Design Explained, Kingy AI, November 1, 2026
• DeepSeek releases open-source dsh-superagent coding agent, Dataconomy, November 2, 2026
• DeepSeek’s Super Agent Harness: Fixing the Attention Bottleneck, MindStudio, November 3, 2026
• DeepSeek Harness Explained: The Plugin Architecture Behind Super Agent, MindStudio, November 4, 2026
• DeepSeek Superagent Tutorial, DataCamp
• Community bug reports: #11700, #11774, #11801, DeepSeek Harness Discussions