DeepSeek's Router doesn't do the work because 47 lines of prompt forbid it

The paper presents the Router/Worker split as architecture. In the repo, a third of the prompt text is prohibition — and that text, not the tool permissions, is what keeps the Router from writing code.

Three days ago DeepSeek published a design doc for a “Super-agent”: a long-lived Router that talks to humans, isolated Workers that do the work, and five modules around them. I wrote about the numbers in it earlier today. This one is about the code, because the code is where the architecture either exists or doesn't.

The prototype is public — deepseek-ai/dsh-superagent-prototype, 15,088 stars, 216 files. Most of it is TypeScript. But if you open the five prompt files that actually define how the roles behave, you find something the paper never mentions: the Router is prevented from doing engineering work by sentences, not by permissions.

What's actually in there

47 negations across 148 lines. Counting by line rather than by phrase, about a third of the instruction surface is a list of things the model must not do.

That is not stylistic. Reading them in order tells you exactly which failure modes the team hit while building this.

The Router prompt is four prohibitions in twelve lines

Here is the one that matters most, from prompts/orchestrator.md:

Outside proactive assessment, do not follow context references,
read code or logs, assess technical scope, design a solution or
investigate blockers yourself.

Notice what this means. The Router is a full agent session — it has tools. Nothing in the runtime stops it from opening a file. What stops it is one sentence listing six specific acts it may not perform, followed by a note that a short request must arrive at the worker unparaphrased:

“Do not paraphrase a short request into a work plan, pick examples or categories, invent requirements, or append implementation, tests, documentation, licensing, CI or review checklists.”

The same file gives the example they expect: “Could we add a dark mode?” should reach the worker as that sentence and its source reference — without router-selected colour schemes or a maintenance plan. Every team that has shipped an agent with a planning layer has watched it do exactly the opposite. This prompt is a scar.

Three mechanical constraints that do more than any prompt

Prohibitions are cheap to ignore, which is why the interesting parts of this repo are the places where a rule became arithmetic.

1. A routing note is capped at 30 words, and the prompt says the cap is counted “with Chinese word segmentation for mixed text”. They are not limiting the note for tidiness — a limit on words in English is a limit on tokens in Chinese, and a Router that writes essays is the whole failure mode being prevented. So the cap is measured in the unit that a mixed-language deployment actually pays for.

2. An accept is idempotent by trigger ID. Not by content, not by fuzzy title matching — by the ID of the event that started it. Duplicate work is the default failure of an event-driven system, and the fix is a key, not a sentence.

3. Undecided candidates expire. A candidate that the Router never routes is dropped at the assessment timeout and the thread moves on. Without that, a stalled Router silently accumulates a queue that looks like a backlog and behaves like a black hole.

The model split is real code, not a claim

The paper says the Router's work “is often simpler than expected, and a lighter model can usually provide both speed and quality”. src/app/role-models.ts implements that as: each role has a configured provider/model/reasoning-effort, resolved at session creation.

Two details in 44 lines are worth stealing. First, they deliberately do not call selectModel — the comment says it “mutates the global DSH default” — instead they append a model/selection event and intercept only the initial request, so a later manual model choice by a human survives. Second, the override is removed as soon as the session sees its own request/header event: the role default is a seed, not a ceiling.

That is the unglamorous half of an “architecture”. The paper's five modules are a diagram. The thing that decides whether your Router silently rewrites a customer request into a spec is thirty words about what not to do, plus an event type.

Why this matters if you're building one

Copying the diagram gives you a router that plans. Reading the prompts tells you the real design constraint:

1. Your agents will over-plan by default. Every model, unprompted, turns “add dark mode” into five acceptance criteria. Prohibitions are load-bearing.
2. Turn the important prohibitions into numbers. Word caps, ID-based idempotency, timeouts. A rule the model can restate is a rule it can drift from.
3. Give each role its own model budget. The Router answers in short outputs over a long history; the Worker needs the strongest model. One global model setting forces you to overpay one of them.