The DeepSeek Harness team shares the Super-agent architecture design: using...

DeepSeek Harness Team's Super-agent Design Exploration: Toward a More Autonomous Agent System

An engineering architecture discussion shared by the DeepSeek Harness team. The team believes that single-task Agents are already strong enough, and the bottleneck has become "how many Sessions a person can keep an eye on at the same time." Super-agent aims to turn the Agent into an entity that is continuous across channels, capable of parallel multi-tasking, event-driven and proactive in getting work done, and persistently online in the cloud; the approach no longer stacks up a single chat window, but instead uses classic computer system ideas (two-layer Router/Worker, event filtering and direct pass-through, asynchronous ReAct, separation of storage and compute plus an on-device daemon, external Watchdog) to turn Session into an implementation detail, with humans only making high-level decisions and acceptance checks.

Where do the problems come from Coding Agents have proven that models can get work done with less supervision; personal assistants have also brought in messages, schedules, and emails, becoming continuously online and event-driven. But mainstream designs still use a single Session as the basic unit: to do several things in parallel, a person has to manually switch Sessions and keep track of context themselves, and one person can usually only keep up with about 3–5 active Sessions. So the ceiling for single-task work depends on the model, while the ceiling for multi-task work depends on human attention. Hanging a CLI/MCP on only a local single session still cannot avoid synchronous blocking, contexts getting mixed together, and everything stopping when the device goes offline.

# Four foundational characteristics

Continuous (IM and GitHub comments look like the same Agent, without asking "is there a Y in Session X"), efficient (can parallelize multiple tasks without having to wait for the previous one to finish before saying the next), proactive (continuously observes the environment and acts only when it should), and persistent (always online, able to self-heal from anomalies). The article gives examples: the same development task advances continuously between IM and GitHub; in a public group, even without anyone @-mentioning it, it can proactively locate the root cause and submit a fix PR.

A single ReAct Loop cannot support these four points, so it is split into five modules.

1. Two-layer architecture: continuity vs throughput · Everything in one Session: the context is the most connected, but it is slow due to serialization and details contaminate each other. · A new Session for every event: high throughput, but lacks global context and is confusing to users.

Solution: the Router layer is always resident, handles human interaction and global coordination, and serves as the sequencing point, coordination point, and memory; it does not personally execute specific tasks (it may not even have Bash attached). The Worker layer has isolated context, is fully equipped with tools, specializes in single tasks, and uses the strongest model; it does not speak directly to the outside, but reports status to the Router, and the Router replies uniformly. The article deliberately distinguishes this: a common Agent Team splits roles within one complex task, and the Lead does heavy reasoning; here the Router only handles high-level dispatch between tasks. In practice, the Router often only needs a lighter model. When events pile up, the Router batches multiple Triggers into one call with long input and short output; when the backlog is moderate, the inference time allocated to a single decision actually decreases (Section 7.2 has stress tests). Only at larger scale does it discuss multi-layer filtering or horizontal splitting within the Router—the finer the split, the higher the throughput and the worse the global continuity, and this trade-off remains until global memory is solved.

Inside a Worker, Subagents can still be opened, or the Worker itself can be a Team, transparent to the Router. The personal assistant front end is one chat box, but underneath it can also split Workers by topic.

2. Event-driven: Triggers, not waiting for people to type one by one The main input driver changes to semi-structured Triggers such as group chats, emails, schedules, Code Review, and CI. · Two-level filtering (Fast/Slow Path): the program layer first cuts noise according to deterministic rules such as source, group, and whitelist; what passes is then handed to the LLM for semantic judgment (prompts can change strategy at any time). · Subscription and direct pass-through: the same PR / IM topic / email thread = Thread. After the Router cold-starts a Worker and subscribes it, subsequent events in the same Thread pass directly to the Worker at the program level, no longer forwarded through the Router each time; the Router can still observe globally, but only manages new unsubscribed events. Thread↔Worker is many-to-many: when multiple people modify the same environment, they share events and discover conflicts on their own, and conclusions are still reported to the user through the Router. · Inline & Spill + chained recall: treat the context window as a Cache, inline recent high-probability information, and spill long content into summaries/continuation entry points. Objects carry unique IDs, and when injected, the next-hop associated ID is inlined to form a reference graph, expanding on demand across multiple hops when needed (message→Thread→Worker→another review Thread). · Speculative execution: for a meeting invitation, it can first check the schedule, prepare materials, and draft a reply; when a bug is discussed in a group, it can silently reproduce it in the background, and only deliver results once it confirms it is simple and fixable, otherwise stay quiet.

3. Human-oriented interaction · Asynchronous ReAct: time-consuming tools change from synchronous run() to start()/stop(), immediately returning Started, with results later posted back as events; the foreground can continue receiving instructions. The article says DeepSeek Harness has implemented this but has not yet enabled it by default. · Adjust output bandwidth by channel: IM is low-interruption, with a single reply not exceeding about 100 words; GitHub/email writes structured background, change descriptions, and verification.

4. Separation of compute, state, and environment Local Agents often bind Loop computation, session state, repositories, and toolchains to one machine, and stop when it sleeps. Split into two steps: · Put the Loop in a stateless elastic container in the cloud, and put Session state into a database → persistently online in the cloud. · Keep the heavy-state execution environment in place, and run only a lightweight daemon on the device side that has no session state, executing commands and returning results (BYOM: everyday development machines can also connect). The article aligns this with Anthropic's "brain-hand separation," but the scenario emphasizes uncommitted changes and local credentials on personal machines even more, not just hosted sandboxes/VPCs.

5. Watchdog (external Control Loop) An independent Watchdog Session, driven by scheduled messages: it watches infrastructure such as interfaces/status, and also uses models to see whether a Worker is making substantive progress and whether it has gone off track. Maintainers can ask it in natural language, have it change prompts, or trigger rules.

Experiments (synthetic load, preliminary reference) About 300 messages and about 20 work requests, with coding using a time-consuming placeholder tool. Super-agent task completion time p50/p95 is about 12.4 / 15.7 minutes, better than "single Session + Subagent": under neutral prompts, the model did not delegate in any of 5 runs and was interrupted by new messages, with p95 about 29.5 minutes; even after emphasizing delegation, it was still slower overall and occasionally had a long tail. The cost is higher read-cache tokens due to multiple sessions. After removing direct pass-through, completion time was about the same, but Router decisions increased by about 30% and read-cache tokens by about 37%; direct pass-through mainly saves Router overhead and does not directly speed up completion. Router stress test: Triggers went from about 1/min to about 40/min, average batch 1.0→2.8, single request 2.5s→3.9s, and inference time allocated per decision 6.4s→1.6s.

Unsolved problems (Section 8) When the Router should split, and when Workers need direct communication; long-range memory across months; after Sessions are hidden from users, how to present tasks on the product side and how to intervene midway; organization-level context boundaries and A2A; the attack surface of cloud Loop + on-device daemon and credential use "without touching the credentials themselves." The article concludes by emphasizing: if security and privacy cannot be solved, Super-agent can only shrink into a very small trusted scope.

GitHub dsh-superagent-prototype lead author Yujia Qiao https://t.co/X0QHiz1EWP WeChat official account article address https://t.co/uV7BYwUpGu