# Super Agent AI: DeepSeek's Router vs Octomind

> Super agent AI design: DeepSeek's router and workers as a coding agent architecture, what its test shows, and a docs-only Octomind setup.

DeepSeek's design for a super agent AI says a coding agent shouldn't make one chat session juggle every team request. A long-lived Router receives events and assigns tasks; isolated Workers do the coding. I read the [DeepSeek Harness design article (2026)](https://x.com/DeepSeekHarness/status/2116857257245987236), an English machine translation of a Chinese original, posted on DeepSeek Harness's own account, and the public [dsh-superagent prototype (2026)](https://github.com/deepseek-ai/dsh-superagent-prototype). The distinction matters: the essay is a design exploration, while the repository says its implementation is research code and differs from the internal system.

I build Octomind. **The short answer:** copy the permission boundary and event filtering before you copy “autonomy.” DeepSeek's small simulation supports a scheduling argument, not better code. A Router without execution tools can make delegation structural; code should reject routine events before a model sees them. Octomind has roles, per-role models, code-filtered webhook hooks, and pointer-based recall, but it does not implement DeepSeek's thread subscriptions or silent reproduce-then-PR behavior.

## What does “super agent AI” mean in this design?

It means one team-facing agent backed by more than one session. The Router is the durable front door: it talks to people, tracks work, and assigns each new task. A Worker gets one task in a separate context, uses execution tools, and reports back through the Router. The Router can be denied code tools entirely.

That is different from asking one agent to split a large request into sub-tasks. DeepSeek's Router assigns independent requests; a Worker can still use [subagents](/blog/multi-agent-delegation-octomind) internally for a complex task. The point of this coding agent architecture is to keep team intake and code execution in separate permission and context boundaries.

In the table, “measured” means the essay's own experiment, not independent validation.

| Design part | What it buys | Cost or risk | Evidence in DeepSeek's source | Structural enforcement | Octomind status, checked November 2026 |
|---|---|---|---|---|---|
| Router and disposable Workers | One human-facing voice; task contexts stay separate | More sessions and token use; shared workspace conflicts remain | Measured in a small scheduling simulation | Give Router only delegation tools; give each worker its own role and task text | **Has:** `[[roles]]`, `agent_<name>`, and `allowed_tools` |
| Cheaper Router, stronger Workers | Spend reasoning capacity where code work happens | Routing quality may suffer; no model comparison measured this choice | Reasoned design choice, not measured | Set a separate `[roles.model] name` per role; compare routing mistakes and worker results | **Has:** per-role model names; no result proving this allocation is better |
| Force delegation by design | Stops one busy session from deciding to do every task itself | A separate worker can add overhead to tiny tasks | Measured: neutral prompt delegated 0/5; delegate-first prompt 4/5 | Remove shell and coding tools from Router's allowlist; expose only `agent:*` | **Has:** role tool allowlists; tool grants are not an OS sandbox |
| Two-pass event intake | Drops predictable noise cheaply; reserves model judgment for ambiguous events | A code rule can drop a valid request; a model can misclassify candidates | Reasoned design, not measured in the essay's experiment | Filter source, repository, sender, and event type in code; pass only candidates to a model | **Partial:** webhook script filters in code before injection; no model-based second pass with team-written rules |
| Thread subscriptions | Later comments reach the worker already handling that thread | Wrong ownership can strand or misroute an event | Measured for scheduling and cache-read effects, not code quality | Persist a thread→worker subscription; route follow-ups directly, with an explicit hand-back path | **Partial:** Cloud gives each Slack/GitHub thread its own session, as described in [the connector post](/blog/agents-where-you-already-are); it does not subscribe a claimed worker under a Router |
| Context as a cache | Keeps recent IDs and summaries handy; retrieves detail only when needed | Bad pointers or stale summaries can hide needed context | Reasoned design; no retrieval-quality measurement reported | Store stable IDs, short summaries, and links to full records; fail on unknown IDs | **Has:** compression summaries cite block IDs for `recall`; learning records link by ID and expand one hop |
| Proactive reproduction | May find a fix before someone explicitly assigns it | Extra compute and risk from acting on untrusted reports | Internal policy described by DeepSeek; no measured outcome | Our recommendation: start in a log-only “would have done this” mode; require reproduction and verification before opening a PR | **Missing:** build this behavior yourself; Octomind's observe-only hindsight is a different feature |
| Long-term operation and safety | Recovers work and limits attention spent on session management | Cross-month memory, prompt injection, and credential exposure remain open | DeepSeek names these as open problems | Put signature checks at ingress; label outside text untrusted; limit tools and isolate credentials | **Partial:** monitor data is labeled untrusted; hook listener does not verify signatures; pending inbox messages do not survive process exit; learning keeps a hot store plus a lossless `.archive/` cold archive and promotes used cold records back, with no measurement over months |

The essay says a person “can usually follow only 3 to 5 active sessions at once.” It offers that as experience, not a study with a method or sample. Treat it as a motivation, not a capacity limit for your team.

## What did DeepSeek actually test?

The evidence says that architecture affected scheduling in one synthetic workload; it says nothing about the quality of generated code. The essay describes about 300 chat and CI messages per run, about 20 work requests, and 5 runs per design. Coding was replaced by a tool that consumed time.

| Setup | p50 / p95 completion (min) | Delegation result | Cache-read tokens per run |
|---|---:|---|---:|
| DeepSeek Router + Workers | 12.4 / 15.7 | Router assigns work by design | 23.2M |
| Router + Workers without pass-through | 12.6 / 15.5 | — | 31.8M |
| Single session, neutral subagent prompt | 20.4 / 29.5 | 0 of 5 runs called a subagent | 6.1M |
| Single session, delegate-first prompt | 13.8 / 29.0 | 4 of 5 delegated | 10.8M |

*The essay's caption: “mean of 5 runs; message intervals and work durations scaled by 1/4; model call times not scaled.” Minutes are not wall-clock times for real work.*

Those are [DeepSeek's reported results (2026)](https://x.com/DeepSeekHarness/status/2116857257245987236), not an independent benchmark. The Router design used more cache-read tokens than either single-session setup. Turning off worker pass-through left completion times roughly similar but raised cache-read tokens from 23.2M to 31.8M, about 37%.

The useful inference is narrow: if parallel intake matters, a tool boundary can enforce delegation more consistently than a prompt. The test doesn't show that the Router writes better code, that the design scales, or that an always-on agent is safe.

The Router-only batching test used a real Router model and mock Workers. As decision-trigger rate rose from about 1 to about 40 per minute, average batch size rose from 1.0 to 2.8 and amortized inference time per decision fell from 6.4 to 1.6 seconds. That's evidence about batching under the tested setup, not a production capacity guarantee.

## What do secondary summaries attribute to DeepSeek that the original does not say?

The MindStudio article is a summary; several details differ from DeepSeek's original essay, checked 2026-11-04.

| MindStudio summary claim | What the original says |
|---|---|
| “$7 in cached tokens” at “flash-tier pricing” versus “$4.64 … at Sonnet-tier pricing” | The original names no model, price, or cost; its token figure is cache-read tokens per run. |
| “would have done this” logging mode for proactive behaviors | Not in the original. Its example is a “silently reproduce and fix” policy that “delivers a result only after it has confirmed the issue and found a simple fix. Otherwise, it stays quiet the whole time.” |
| “12.4 minutes on average” | The original reports p50 12.4 / p95 15.7, with durations scaled by 1/4. |

Our arithmetic: $4.64 equals 23.2M cache-read tokens × $0.20 per million, the cache-read rate our model catalog lists for Claude Sonnet 5; neither source states this calculation. Check numbers against the [original essay](https://x.com/DeepSeekHarness/status/2116857257245987236) before quoting them.

## How can I enforce delegation instead of asking for it?

Give the Router a permission set that cannot perform the work. This docs-only Octomind sketch wires one `issue_worker` role, gives the Router only `agent:*`, and assigns the worker a stronger model plus filesystem tools. It follows the config shapes in Octomind's [multi-agent guide](/docs/use-cases/05-multi-agent-delegation) and [roles guide](/docs/usage/06-roles); it hasn't been run. Install and configure `octofs` first, then replace the model names with models enabled in your environment.

```toml
[[mcp.servers]]
name = "filesystem"
type = "stdio"
command = "octofs"
args = ["mcp"]
timeout_seconds = 30
tools = []

[[roles]]
name = "router"
welcome = "Ready to route team work."
system = "Assign each request to issue_worker. Do not inspect or edit code. Report worker results to the requester."

[roles.model]
name = "deepseek:deepseek-flash"

[roles.mcp]
server_refs = ["agent"]
allowed_tools = ["agent:*"]

[[roles]]
name = "issue_worker"
welcome = ""
system = "Complete the assigned repository task. Return the result and the evidence used."

[roles.model]
name = "anthropic:claude-sonnet-4-6"

[roles.mcp]
server_refs = ["filesystem"]
allowed_tools = ["filesystem:*"]

[[agents]]
name = "issue_worker"
description = "Handles one assigned repository task and returns its result."
command = "octomind acp issue_worker"
workdir = "."
```

The allowlist keeps the filesystem server and the worker's tools away from the Router, but it isn't the whole tool surface. An interactive CLI session also gets `schedule` and `monitor`, and `monitor` can run commands; daemon, ACP and WebSocket sessions use the role's grants only ([roles guide](/docs/usage/06-roles), [scheduled tasks guide](/docs/use-cases/07-scheduled-tasks)).

Automatic capability activation can add tools unless the root key `auto_capabilities = false` sits before all table headers, and executables in `.agents/tools/` are added regardless of the allowlist. So run the Router as a daemon, keep `.agents/tools/` out of its working directory, and check the effective tool list with `/mcp list` before you trust the boundary.

The worker has filesystem access, so keep it in a disposable worktree or use an OS sandbox and repository policy for containment. Octomind's tool allowlist isn't itself an OS sandbox. The two model names are examples, not a recommendation that those exact models fit every team's cost or quality target.

## How should a proactive coding agent handle incoming events?

Filter cheap facts in code before asking a model to judge meaning. DeepSeek's fast path checks where an event came from, which group it belongs to, and allowlists of users or bots; each source can be set to “respond only to explicit requests”, “treat as candidate events”, or “ignore”. For chat replies, the essay names one rule it verified: “a cap of 100 words per reply”. For a PR-comment listener, first reject events from unapproved repositories, users, or event types. Only then send a bounded candidate to the model, with the comment marked as untrusted content and the task's allowed actions stated separately.

DeepSeek proposes a second, semantic pass where a model applies team rules to candidates. Octomind's documented webhook path currently stops after the code filter: a hook script can return empty output to ignore an event (HTTP 204) or output text for the daemon inbox. The script receives the raw request body. The [event-driven agent guide](/docs/use-cases/02-event-driven-agent) documents the hook flow, but the listener doesn't verify webhook signatures or provide TLS; put authentication and TLS in an ingress proxy.

Don't treat issue text, commit messages, or CI logs as instructions. DeepSeek calls prompt injection an unresolved security problem. Octomind's monitor labels delivered text as untrusted data, but that label doesn't remove the need for narrow tool grants, protected credentials, and review before a write or merge. Also account for a lifecycle limit: Octomind's pending inbox messages do not survive process exit.

## Which parts can I use in Octomind today?

Use Octomind when configurable roles, model selection, code-filtered hooks, or recall by stable IDs solve the step you need. Use another runtime or build an adapter when you require a Router that assigns a worker to a thread and forwards its later events directly; Octomind Cloud's per-thread sessions are a different arrangement. For how the two tools differ day to day (install, release status, memory, spend limits), see the [DeepSeek Harness comparison](/alternatives/deepseek-harness), checked 2026-10-22.

Octomind also has an observe-only hindsight feature and a shadow-to-trial lifecycle for generated behaviors, both off by default. These give you a place to observe and test a proposed behavior; they don't silently reproduce a reported bug and open a PR. That behavior would need to be built and independently guarded. There's no Octomind benchmark against DeepSeek's AI super agent design, so these are implementation facts, not a head-to-head result.

## What should I adopt first?

Start with the permission boundary, then add events, then add proactivity only after observing the false-positive rate. Log-only observation is our recommendation, not a reported DeepSeek practice. That order addresses the part the experiment most clearly illustrates and leaves the least-grounded behavior behind a reviewable gate.

1. **Split Router and Worker roles.** Remove code tools from the Router's allowlist and verify the effective tool list after startup.
2. **Filter before inference.** Reject routine events in code; log candidate events before adding a model-based rule pass.
3. **Keep task context small and traceable.** Put an ID and short summary in the prompt, then retrieve full text by pointer when needed.
4. **Run proactive agent behavior in log-only mode.** Compare “would have acted” events with human decisions before granting access to create branches or pull requests.
5. **Test the failure path.** Restart the daemon with queued events and verify what was persisted, replayed, or lost.

DeepSeek's essay is a useful architecture proposal and a small scheduling result. Build the hard boundaries into sessions, tools, and ingress rules; let prompts explain those boundaries, not substitute for them.