In one line: the interesting claim in DeepSeek Harness’s architecture note is not its five modules — modules change with deployment. It is one sentence: sessions should be an implementation detail of the system, not a mental burden on its user. Everything below is that sentence, taken seriously.
Published 2026-10-31, the note opens by telling you what it is not: an architecture discussion, not a description of shipping features. The prototype went up on GitHub the same day, MIT-licensed, with a README that says the same thing more bluntly — research code, not equal to the internal version. Read it as a paper first, as a product spec second. The two readings disagree, and the disagreement is the useful part.
1. The problem: the bottleneck moved to attention
The authors’ observation is small and sharp:
The ceiling on a single task is model capability; the ceiling on many tasks is human attention. In our experience one person can follow only 3 to 5 active sessions at once.
No method, no sample — but anyone who has run three agents in parallel will recognise it. The reason is not laziness. It is that today’s agents weld two jobs onto one object:
| What a session is | What that costs |
|---|---|
| the container of the model’s context | you cannot switch without paying to rebuild context |
| the user’s unit of project management | so “close the session” means “lose the project” |
Three structural limits follow: a single session blocks on long operations, contexts from different tasks contaminate each other, and everything stops when the laptop sleeps. CLIs, MCP servers and connectors do not touch any of the three, because the problem is not the interface — it is that the session was made the boundary of the system.
2. What it proposes: five modules
Four properties are claimed — continuous, productive, proactive, persistent — and no single ReAct loop can deliver them. So they land on different modules:
| Property | What buys it | What breaks without it |
|---|---|---|
| Continuous | two layers, all channels funnelled through the Router | you become the one who remembers which session saw which sentence |
| Productive | context-isolated workers running in parallel | one task at a time |
| Proactive | Triggers, two-stage filtering, speculative work | a more expensive command line, still waiting for orders |
| Persistent | compute/state split, endpoint daemons, a watchdog | a laptop lid ends the work |
The design does not claim to invent anything. It maps classic computer-systems ideas — two-level scheduling, fast and slow paths, treating the context window as a cache, speculative execution, compute-storage separation, an external control loop — onto an agent system. That framing is the honest one, and it tells you how to read the rest: for each analogy, ask where it holds and where it breaks.
3. Two layers: a Router that only dispatches
Continuity and throughput are a genuine trade-off. Send every event to one session and the context is maximally continuous, but a ReAct loop runs one step at a time, so throughput collapses and the details of unrelated tasks interleave. Give every event a fresh session and throughput is maximal, but related work loses its shared context and several sessions talk to the user at once. The note splits the cost across two layers instead of trying to beat it.
The Router layer carries three hard constraints:
- It does not execute tasks. Interaction and dispatch only — “it can run without a Bash tool at all”.
- It is the global sequence point, coordination point and memory. Everything cross-task converges there.
- It can be a lighter model. The note’s claim is that Router work “is often simpler than expected”.
The third has a non-obvious support: batching. Triggers that queue during one inference turn are merged into the next call. The Router’s steps are long input, short output, and merged triggers are computed in parallel during prefill — so up to a point, the deeper the backlog, the lower the amortised inference time per decision. Section 7 shows the measurement.
The difference from an Agent Team is worth a table, because the two get conflated constantly:
| Agent Team | A Super-agent’s two layers | |
|---|---|---|
| Who decomposes the work | the lead splits subtasks and coordinates often | the Router never splits; workers derive requirements from the raw event |
| Where the reasoning load sits | heavy, on the lead | light on the Router, heavy on each worker |
| Failure mode | the lead misreads the task, everyone drifts | workers drift separately; the Router only sees progress or its absence |
| Can you get there from a Team | — | yes: forbid the main session to execute work, leave it interaction plus dispatch |
That last row is the practical one: the two-layer architecture is a prompt constraint plus a main session that does not do the work. You can try it without changing frameworks.
The cost is visible in the prototype’s prompts. Because the Router must not decide for the worker, prompts/dispatch.md is a wall of prohibitions:
Do not expand a request’s scope, add implementation plans, acceptance criteria or policy checklists… Do not paraphrase a short request into a work plan, pick examples or categories, invent requirements…
It even carries the example: “Could we add a dark mode?” must arrive as that request, with its source reference, and no Router-chosen colour scheme. The verbosity of that prompt is the receipt: being light is not free; it is paid for by writing down “do not get clever” as a rule.
4. Event-driven: one Trigger’s life
The input is no longer a prompt someone types. It is a semi-structured event: a group message, a pull-request comment, a CI result. The note walks one event from arrival to action in four increasingly specific steps.
Filtering. A programmatic gate takes deterministic conditions — source, group, allowlists — and drops most traffic before any model call. What survives goes to a semantic gate: a model deciding against policy written as prompts. The prototype keeps the two genuinely separate: src/admission.ts is an admission matrix over “listed or not” and “addressed or not” (three cells; a listed sender who addresses the agent is always an explicit request), defaulting hard to caution, and the semantic half lives in src/app/assessment.ts.
Routing. Consecutive events on the same pull request, IM thread or email chain form a Thread. The Router only handles cold starts: it creates the worker for a thread’s first event and subscribes it. After that, code passes follow-ups straight through; the Router can still see them, but does not forward them. Subscriptions are many-to-many, which is how two workers that touch the same PR learn about each other without point-to-point messaging.
Pass-through does not buy speed; it buys the Router’s budget. Remove it and completion time barely moves (12.6 / 15.5 minutes against 12.4 / 15.7), while the Router makes about 30% more decisions and cache-read tokens rise from 23.2M to 31.8M.
Context. The window is treated as a cache. Inline what is needed soon; spill what is not, leaving a pointer and a summary behind, then walk the reference graph hop by hop when a question reaches back.
In code this is plain but real: preview() in src/app/cards.ts compresses a body to 160 characters, and the card carries an id plus read: ticket/<id>; inputLine() inlines up to 80 characters and leaves a pointer beyond. The thresholds are guesses; the direction is right. What is missing is the multi-hop part — relatedTickets hops once, and the article’s reference graph has no implementation yet.
Speculation. Act before the outcome is known to be useful: when someone reports an issue, reproduce it and look for a cheap fix in the background, speak only once the problem is confirmed. The prototype’s version of this is a good product decision — proactive work starts in a mode that only records what the agent would have done, so you can read the intent before granting the action.
5. The human side: full duplex, many channels
A classic ReAct loop calls run() synchronously: until the tool returns, the session hears nothing. Make the call asynchronous — start() returns Started at once, the result arrives later as a new event — and the foreground stays available while work continues.
Then the note says something worth quoting exactly:
DeepSeek Harness already implements this asynchronous task mechanism, but it is not yet enabled by default.
So full duplex is a switch, not the default interaction contract — and the felt experience of the whole system depends on that switch.
The multi-channel half is more immediately copyable. Two rules:
- Instant messaging: behave like a colleague — notify only when a decision or sign-off is needed, ask direct questions, give short conclusions. Their hard rule is 100 words per reply.
- Asynchronous channels (GitHub, email, documents): structured, information-dense delivery — full problem background, what changed, how it was verified.
The hundred-word rule is not a style guide in the prototype; it is transport-enforced. prompts/replies.md says “100 words is a hard ceiling, not a writing target”, and the transport rejects longer IM messages, including when someone asked for technical detail. A constraint the system can execute beats a request to “be concise”.
6. Persistence: brain in the cloud, hands where they are
A local agent welds three things to one machine: the compute that runs the loop, the state that must survive, and the execution environment — repositories, toolchains, credentials. Close the lid and all three stop.
The note decouples in two steps. First, compute becomes stateless containers and session state moves to a database, so the agent stops sharing a machine’s lifetime. Second, the cloud loop is separated from the heavy execution environment: the endpoint runs a daemon that keeps no session state, executes commands and returns results.
This is Anthropic’s brain/hands split, reached from a different starting point:
| Anthropic Managed Agents | DeepSeek Super-agent | |
|---|---|---|
| What it connects first | on-demand sandboxes, customer VPCs | the developer’s own machine, uncommitted work included |
| Availability assumption | cloud and sandbox are up | the endpoint may be online only intermittently; tasks resume on reconnect |
| Security approach | tokens never reach the sandbox: git tokens wired into the remote at init, MCP through a vault and proxy | listed as an open problem (§8.4) |
| Published payoff | TTFT p50 −60%, p95 −90%+ (vendor-published) | no numbers for the split |
That last row is the interesting asymmetry: one side reports a latency number, the other reports a design. The latency number is what makes the split more than architecture hygiene — it lands on the part users feel.
The watchdog is the other half of persistence: not a liveness probe, but a session outside the main system, driven by scheduled messages, with the full toolset. It fixes infrastructure failures and asks a model whether each worker is making substantive progress or drifting from the goal. Maintainers can ask it, in natural language, why something failed — and have it edit prompts or trigger rules while the system runs. Supervising agents with an agent is elegant on the happy path; see section 9 for the other path.
7. Numbers, with their sources
Two experiments, both synthetic: about 300 messages per run with about 20 work requests, coding replaced by a tool that only consumes time, five runs per design.
| Metric | Value | Source |
|---|---|---|
| Completion p50 / p95, Super-agent | 12.4 / 15.7 min | own ablation, synthetic load, 5 runs |
| Same, without pass-through | 12.6 / 15.5 min | same |
| Single session + subagent, neutral prompt | 20.4 / 29.5 min | same |
| Single session + subagent, delegate prompt | 13.8 / 29.0 min | same |
| Cache-read tokens per run | 23.2M / 31.8M / 6.1M / 10.8M | same, in the same order |
| Batching, 1 → 40 triggers per minute | mean batch 1.0 → 2.8; request 2.5 → 3.9 s; per decision 6.4 → 1.6 s | same |
| Indirect injection success against DSH | 17.0% text, 25.5% file (hidden Unicode), 16.0% skills channel | A.I.G, 14,560 runs, arXiv:2608.16393 |
| TTFT after the brain/hands split | p50 −60%, p95 −90%+ | vendor-published, not re-measured |
Three things have to be read together:
- It measures scheduling, not execution. A timer stands in for coding, so “12.4 minutes” contains no written code. These numbers support “two layers are more stable than one session”; they do not support “the work is better”.
- The single-session row is a story about prompts, not models. With a neutral prompt the model delegated in none of five runs and p95 hit 29.5 minutes; told to prefer delegation it delegated in four of five, and the fifth judged the work “small” and did it itself — the long tail in the figure. Leaving “should I split the work?” to prompt engineering and on-the-spot judgement is exactly the fragility the two-layer design removes.
- The tokens are real money. 23.2M against 6.1M is 3.8×. The note says it plainly: more tokens buy shorter, more stable completion times.
8. The open-source prototype: what runs
The prototype is a bundle for DeepSeek Harness, MIT, one repository, GitHub and Feishu as sources, state in a local stateDir. Put the article’s concepts next to the code and the boundary gets sharp:
| In the article | In the prototype | Status |
|---|---|---|
| Router layer | main session (prompts/orchestrator.md), src/core/engine.ts as the single transactional entry | implemented (one local session) |
| Trigger / Thread | src/core/model.ts, src/core/intake.ts | implemented |
| Two-stage filtering | src/admission.ts gate + src/app/assessment.ts | implemented |
| Thread subscription, many-to-many | Subscriptions held by the Thread, src/core/tickets.ts | implemented |
| Inline & Spill | preview() 160 chars, inputLine() 80 chars, then a pointer | implemented (one level, not a mechanism) |
| Chain of recall | relatedTickets / referenced_tickets | partial (one hop) |
| Speculative work | proactive work recorded, not executed | partial (policy side, no budget) |
| Async ReAct | src/executor/background.ts, on DSH’s jobs and subagents | implemented (depends on the host) |
| Compute/state split, BYOM daemon | none: local SQLite, local session | absent |
| Watchdog | no watchdog session; only component health and retry state | absent |
| Router sharding | none | absent (the note lists it as open too) |
The summary of that table: the prototype finishes routing and authorization, and leaves persistence and self-healing on paper. Those two are the hard ones — one changes deployment, the other changes operations.
Two details say more about the engineering than the module diagram does. The domain model is far more verbose than the article: eleven concepts in docs/001-domain.md, plus a table of rejected concepts — “at most one ticket per thread” is rejected because a thread can carry several unrelated pieces of work. And authorization is separated from context: a trigger reaching a ticket is context, granting nothing; what authorizes work is an immutable Mandate on the ticket — who authorized, under which policy version, how far it may go. The article does not stress this, but it is the precondition for being proactive safely.
9. Where it does not hold
Security is not an open problem, it is a precondition. Section 8.4 admits the design assumes cloud and endpoints trust each other, and that a compromised loop puts every connected device at risk. That is not hypothetical: Tencent’s A.I.G measured indirect-injection success against DSH over 14,560 controlled runs at 17.0% (text mode, semantic judge), 25.5% (file mode, hidden Unicode, rule judge) and 16.0% (skills channel, file mode). At that order of magnitude, in a “cloud loop plus endpoints holding credentials” structure, one injection is roughly one set of devices. Anthropic’s structural answer — credentials never enter the sandbox — is worth copying; DeepSeek states the problem and stops.
The watchdog is an attack surface. It shares the system’s permissions and can edit prompts and trigger rules live. Supervising an agent with an agent is elegant until the supervisor is injected; the note does not discuss it.
Long-horizon memory is the real ceiling. Section 8.1 says chain-of-recall handles recent tasks and session history; once the system runs for months, memory is the bottleneck. Recall and memory are different problems — finding something is not the same as knowing what to keep and what to forget.
“3 to 5 sessions” has no method. It is the premise of the entire motivation: no sample, no measurement. It may well be right; as a foundation, it is self-reported.
Synthetic load has a ceiling. A timer, 1/4-scaled durations, five runs. Enough for “scheduling helps”, not enough for any absolute time. The note says so itself.
Complexity moves, it does not disappear. The design takes session management away from the user — good. But the system’s own complexity has to land somewhere, and DSH’s own reception suggests it lands on the operator. Add one more layer and the user loses the handle on what the agent is doing: section 8.2 admits that presenting tasks without sessions is unsolved. Traceable mandates and auditable decision records may matter more than another architecture diagram.
And a methodological note. Attention is the only thing being optimised here. That is right for parallel work, and it systematically undercounts a second need: understanding what happened, why, and whether it can be reproduced. Saving attention and staying explainable pull in opposite directions, and this note only does the arithmetic on one side.
References
- DeepSeek Harness, “Super-agent 设计探索：迈向更自主的 Agent 系统” (Exploring Super-agent Design: Towards a More Autonomous Agent System), 2026-10-31 — every quote and number above comes from it.
- deepseek-ai/dsh-superagent-prototype (MIT) — the code anchors in section 8:
src/admission.ts,src/core/engine.ts,src/core/model.ts,src/app/cards.ts,src/executor/background.ts,prompts/dispatch.md,prompts/replies.md,docs/000-philosophy.md,docs/001-domain.md. - Anthropic, “Scaling Managed Agents: Decoupling the brain from the hands” — session, harness and sandbox as three interfaces; the TTFT numbers.
- Tencent Zhuque Lab, A.I.G, “Evaluating DeepSeek Harness with A.I.G: A Security Assessment of Indirect Prompt Injection”, arXiv:2608.16393 — 14,560 runs over 16 indirect-content channels.
- deepseek-ai/deepseek-harness (MIT, everything-is-a-plugin).
- Reception, not evidence: DSH discussion #11714 and Elliot Hu’s “DeepSeek Harness: a good framework, a bad product”.