Inside DeepSeek Harness's Super-agent Architecture

DeepSeek Harness is arguing for a change in the unit of agent design. The conversation should not be the product boundary, the model call should not own the work, and one machine should not define where the work can happen. Instead, an agent should remain one continuous collaborator while a routing layer, isolated workers, event infrastructure, persistent state, and an external watchdog handle the difficult parts behind the interface.

This article is a complete adaptation of the DeepSeek Harness article Exploring Super-agent Design: Towards a More Autonomous Agent System. The original was written in Chinese and published with a machine-translated English edition. This version rewrites that argument for technical readers and checks the implementation claims against the separately published dsh-superagent-prototype. The distinction matters: the article describes an architecture and research direction; the repository is explicitly research code, not an official DeepSeek product or a production-ready release.

Why the session stops being the product

Coding agents and other single-task agents have crossed an important threshold during the past year. They can use tools to solve substantial problems, and they increasingly tolerate stretches of execution without a human supervising every command. Models are also becoming better at coordinating subagents. The human moves upward from low-level execution toward choosing a direction, reviewing a result, and giving approval.

That progress has produced a new class of personal agents connected directly to chat, calendar, email, and work platforms. These agents watch incoming information and help with everyday tasks. Personal assistance is only one expression of the underlying pattern. The same always-online, event-driven behavior is useful in software development, operations, research, and other collaborative work.

The limiting factor is now architecture. Mainstream agent products still treat a session as both the model's context container and the user's project-management unit. A person juggling several tasks must switch among isolated windows and remember which window knows what. The DeepSeek Harness team says its experience is that a person can track only about three to five active sessions at once. Individual task quality may be limited by the model, but multi-task productivity is limited by human attention.

Connecting a local single-session agent to MCP servers, a command-line interface, or an external messaging service does not remove that boundary. The session still blocks on long operations. Contexts from unrelated tasks still interfere. Work still stops when the machine sleeps or loses network access. Keeping the setup alive becomes another job for its owner.

DeepSeek Harness calls its proposed system a Super-agent: one continuous agent that preserves context across interactions and carries several complex tasks at once without forcing the user to manage their sessions.

The team describes four properties that must coexist:

• Continuous. The user can speak to the same agent in IM, GitHub, email, or another existing workspace without wondering whether a particular session has the relevant information. A decision made in one channel should reach the work happening because of another.
• Productive. The agent answers quickly and advances several complex tasks concurrently. A user can issue the next instruction before the previous command has finished, and each task can still receive enough focused context to produce a high-quality result.
• Proactive. The agent does not wait for every instruction. It watches relevant events, decides which ones merit action, and remains silent when nothing does. Proactivity is not the same as commenting on everything.
• Persistent. The agent stays available, reaches the environments where real work lives, and recovers from failures during long-running operation.

No single ReAct loop can supply all four properties. They have to come from the surrounding system. DeepSeek Harness groups that system into five parts: a two-level Router and Worker architecture for continuity and concurrency; event-driven Triggers for proactivity; full-duplex, channel-aware interaction; separation of compute, state, and execution environments; and an external Watchdog for persistence.

The team also argues that personal agents and commercial coding agents are likely to converge on similar structures. Their use cases differ, but both require a continuously available system that reacts to events and runs work concurrently. The constraints are similar, so many ideas that operating systems and distributed systems have used for decades become relevant again.

In another internal example, the agent watches a public product group without being @-mentioned. When a user describes a repeatable double-click failure, the agent reproduces the bug in the background and opens a pull request. This is a much stronger form of proactivity than reacting to a direct command, but it also explains why admission rules and a narrow operating scope are necessary.

The five-part system at a glance

The architecture diagram makes the division of responsibilities explicit. Inputs from chat, GitHub, email, and other environments become Triggers. A Fast Path and Slow Path filter them before a long-lived Router decides whether and where work should begin. Worker Sessions execute isolated tasks. Persistent state sits outside the workers. An external Watchdog observes the whole system and repairs failures.

This is a useful inversion of the usual agent diagram. Most diagrams place the model at the center and surround it with tools. Here the model is a component inside a control system. Scheduling, admission, state durability, execution reach, and failure recovery are not prompt concerns. They are infrastructure.

Router and Worker: continuity without serial execution

A system that needs both continuous interaction and high task throughput faces a direct trade-off between continuity and concurrency. Sending every event into one session maximizes shared context. That session sees everything, but its ReAct loop still advances one step at a time. Tasks become slow, throughput stays low, and unrelated task details contaminate the context.

Creating a fresh session for every event reverses the problem. Concurrency rises, but related tasks no longer share global context. Results become disconnected, and several sessions may reply to one person without knowing that the others exist.

DeepSeek Harness separates those responsibilities into two logical layers:

• A long-lived Router layer receives interaction from every channel, maintains global memory, handles external communication, and dispatches new work.
• A context-isolated Worker layer runs the actual tasks in parallel. Each worker has a full set of execution tools and focus on one assignment.

Once this division exists, sessions become an implementation detail. Users should not have to manually shard their work because an LLM API exposes separate context windows. The product can choose project views, task dashboards, issue threads, or domain-specific interfaces without making each view correspond one-to-one with an execution session.

The Router is intentionally shallow

The Router is the global sequence point, coordination point, and memory of the system. It receives human interaction and tracks cross-task relationships. It is deliberately prevented from executing tasks itself. In the authors' design it can operate without a Bash tool at all: it talks to people and dispatches work.

This is what distinguishes the structure from a conventional Agent Team. A Team Lead usually decomposes one complex task into coupled subtasks, reasons deeply about their dependencies, and coordinates members frequently. In a Super-agent, the Router works at a higher level. It decides that a new task exists, assigns it, tracks which threads and workers relate to it, and relays the few conflicts that cannot be handled locally. The Worker owns task decomposition inside its own scope.

That shallow role makes a lighter model viable. It also makes batching natural. If Triggers arrive while the Router is inside an inference turn, they queue and are merged into the next call. Under a steady trickle, each event is handled quickly. Under a burst, the Router processes a larger batch in one prefill. Because its output is short and its input is mostly context, request latency grows much more slowly than batch size, at least until context length or decision accuracy becomes the limit.

The team's simple implementation uses one long-lived LLM session as the Router. It can be sharded later if scale demands, but sharding introduces the same continuity problem at the Router layer: finer shards increase throughput while reducing the global context each shard can see.

Workers execute, but do not speak for the system

Each Worker Session has one task, an isolated context, and a full execution toolset. This is where the strongest model and the deepest task-specific reasoning belong, because worker output determines the quality of the code, analysis, or other result.

Workers do not reply directly to users. They report to the Router, which owns external communication. That prevents several sessions from producing competing answers in the same conversation. Workers can still cooperate through shared environments. If two workers subscribe to the same pull request Thread, both receive new comments and can notice a conflict. The Router handles only cross-task coordination that cannot happen through the shared thread.

A Worker may itself contain subagents or an internal Agent Team. The Router does not need to know. This recursive boundary is useful: independent tasks such as reproducing an issue, reviewing a pull request, and implementing a feature can run concurrently, while each can still use a richer internal structure when the task justifies it.

Triggers turn the environment into the input

A proactive system cannot be driven primarily by a human typing prompts into a session. Its input is a stream of semi-structured events. DeepSeek Harness calls these events Triggers. A Trigger may be a group-chat message, an email, a calendar reminder, a pull-request review, an issue update, or a CI result.

Real event streams are mostly noise. Letting a large model inspect every message from scratch would waste compute and add latency. The design therefore borrows the Fast Path and Slow Path pattern from systems engineering. Deterministic code handles stable, cheap decisions; model reasoning is reserved for ambiguous cases that actually require semantic judgment.

The first stage defines conditions such as “respond only to explicit requests,” “treat as a candidate,” or “ignore.” The second stage receives the remaining event and its context, applies policies expressed in natural language, and decides whether action is warranted. The natural-language rules are a deliberate extension point: a team can change admission behavior without changing routing code.

Threads and pass-through routing

Consecutive events on the same pull request, IM topic, or email chain form a Thread. When the Router starts a Worker for the first event, the Worker subscribes to that Thread. Later events in the same Thread go directly to the subscribed Worker instead of making another round trip through the Router.

Subscriptions are many-to-many. A Worker can subscribe to several related Threads, and a Thread can have several Workers. Events in a shared pull request therefore fan out to every interested Worker at once. Workers still report conclusions to the Router, which updates global memory and sends the external response.

The Router continues to observe unclaimed events so it can maintain global state, but it evaluates only those that do not already have an owner. This split is the event-routing equivalent of separating the expensive cold path from the cheap steady-state path.

Treat the context window as a cache

Once events arrive continuously, deciding what to place in context becomes a systems problem. Too much information dilutes attention and fills the window. Too little forces repeated tool calls and extra reasoning steps. The authors describe context injection with two operations inspired by compiler and memory systems:

• Inline puts information likely to be needed soon directly into the context window.
• Spill leaves large or rarely used material outside the window and keeps only a summary or reference that can be expanded by a tool call.

The process starts with minimal context: an object's ID and a short summary. It progressively inlines related objects based on locality. The system might add the first few dozen characters of a message, the preceding and referenced messages in a chat, or nearby comments in a review discussion. Long content is truncated at a small cap and replaced with a pointer to the full object.

Applying the same rule to every object creates Chain of Recall. Triggers, Threads, and Worker Sessions receive stable IDs. When a recalled object enters context, it includes the IDs of adjacent objects. The Router can begin at the current message, follow a reference to its Thread, move to the Worker Session that owns it, and then follow another reference into a related code-review discussion.

Speculative execution buys attention back

The agent can also borrow speculative execution from computer architecture. Environmental signals may justify starting background work before it is certain the result will be used. If the result becomes useful, it is delivered. If not, it is discarded. Extra background compute replaces some of the user's waiting time and intervention.

A personal agent might read a meeting invitation, check for calendar conflicts, collect relevant context, and draft a response before the user asks. In the DeepSeek Harness group, the team configured a “silently reproduce and fix” policy. When someone reports a possible issue or proposes a change, the agent attempts a reproduction and looks for a simple fix. It stays silent unless the issue and fix are confirmed.

Full-duplex interaction across different channels

Two-level scheduling preserves continuity at the context level, but it does not by itself make an interaction responsive. A classic ReAct loop blocks when it calls a synchronous run() tool. Until the command returns, the session cannot process a new message. A long build or test job therefore makes the agent appear offline even though it is technically working.

DeepSeek Harness replaces blocking tool calls with asynchronous start() and stop() operations. start() returns a “Started” acknowledgement immediately. The tool continues in the background, and its final result is delivered to the session as a new event. The model can call stop() when a command runs too long or is no longer relevant.

The article is explicit that DeepSeek Harness implements an asynchronous task mechanism, but does not enable it by default. That detail is important when evaluating the design: the architectural idea exists, yet the default product behavior may still be more synchronous than the target.

Responsiveness also has a communication dimension. Detailed reasoning and raw tool logs may be appropriate in a single-user terminal, but they overwhelm a group chat. Because Workers do not speak externally, the Router can translate outcomes into channel-appropriate communication.

For instant messaging, the authors recommend light-touch replies only when a person must decide or sign off. Questions should be direct, conclusions should be short, and the agent should interrupt as little as possible. They report that a hard cap of 100 words per reply worked well. For asynchronous channels such as GitHub, email, and documents, a structured and information-dense response is appropriate: problem context, change description, verification evidence, and the conventions of the project.

This is not cosmetic prompt tuning. Channel choice affects interruption cost. A technically correct message delivered at the wrong level of detail can reduce team productivity even if its conclusion is right.

Separate compute, state, and execution environments

A local coding agent usually binds three things to one device: the agent loop's compute, the session state that must survive between turns, and the execution environment containing the repository, dependencies, credentials, and toolchain. The binding makes local work convenient, but it also means that sleep, network loss, or a device restart stops the agent. It also prevents the agent from reaching a different machine where a task actually belongs.

DeepSeek Harness decouples the stack in two steps.

Compute becomes elastic; state remains durable

The agent loop can run in stateless cloud containers. Session state is stored in a database. Containers can restart, scale out, or be replaced without erasing the task. A user's laptop going offline no longer stops a long-running agent, because the laptop is not the host of the agent loop.

The execution environment stays where the work is

Cloud sandboxes are useful when a task can be reconstructed from a repository. Real working environments often contain uncommitted changes, private credentials, intranet dependencies, specialized hardware, and local toolchains. Pulling all of that into a fresh sandbox is expensive and error-prone. Asking every user to migrate their work into the cloud can be even more disruptive.

The alternative is to keep the heavy execution environment where it already lives and connect it to the cloud agent through a small endpoint daemon. The daemon stores no session state. It executes commands and returns results. The cloud can therefore switch among execution devices according to what a task needs.

The authors compare this with Anthropic's “decoupling the brain from the hands” approach. Both keep the harness stateless, store session logs outside it, and connect execution environments on demand. The difference is the primary audience. Anthropic's discussion centers on a managed service, on-demand sandboxes, and customer VPC resources. DeepSeek Harness first needs to connect the personal machines people already use, including machines that are online only intermittently.

When such a device reconnects, the cloud agent can resume the work that specifically requires that device. The result is not merely remote control. The agent has a durable identity and a set of execution endpoints that can change over the life of a task.

The Watchdog must inspect progress, not only uptime

Persistent operation requires more than durable state. Distributed systems also need an independent control loop that can repair failures the main loop cannot repair itself. Agent systems add a less conventional failure mode: the process is healthy, but the reasoning has entered an unproductive loop or drifted away from the user's goal.

DeepSeek Harness therefore uses an external Watchdog Session driven by scheduled messages. It handles infrastructure failures such as API errors and broken state recovery. It also asks the model whether each Worker is making substantive progress or drifting from its mandate. Transient external failures are retried until resolved.

The Watchdog is itself an agent with tools, not a fixed dashboard or a narrow liveness check. Maintainers can ask it in natural language why something failed. It can inspect the system, add or remove prompts, or adjust Trigger rules while the main system continues to run. That makes operational debugging a first-class capability, but it also creates a significant security and governance requirement: the observer with enough power to repair the system is also a high-value target.

What the preliminary experiments actually show

The article reports two experiments on synthetic workloads and simplified environments. The authors explicitly warn that the setup is not a full benchmark and that some parts could be more rigorous. The results should be read as evidence about scheduling behavior, not as evidence that the system can execute arbitrary engineering work faster.

End-to-end ablation

Four designs processed the same style of event stream: about 300 messages per run, including roughly 20 work requests, with the rest made up of casual chat, follow-ups, cancellations, and CI messages. Coding was simulated by a tool that consumes time. Each design ran five times. The measured interval went from a work request to its result message.

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

The two-level design completed tasks faster and with a tighter tail than the single-session designs. It also used more cache-read tokens because it maintained several independent contexts. That is the central trade-off: tokens buy isolation, shorter completion times, and less human coordination.

The comparison to a single session is also a comparison to prompt luck. With a neutral prompt, the model never called a subagent in five runs. Work stayed in the main session, incoming messages interrupted it, and p95 reached 29.5 minutes. With a delegation-first prompt, the model delegated in four of five runs. Performance improved on average, but one run classified the work as “small,” performed it in the main session, and produced a long tail. Prompting the agent to delegate is not the same as making delegation part of the architecture.

Pass-through had a different effect. Removing it barely changed completion time, but the Router made about 30% more decisions per run. Total cache-read tokens rose from 23.2M to 31.8M, roughly 37% more. In this workload, pass-through was not a latency optimization. It was a reduction in redundant routing and inference overhead.

Router batching

The second experiment isolated the Router. It used a real model for the Router and mock models for Workers, then increased the arrival rate of Triggers requiring a decision from about one to about forty per minute.

At the low rate, the average batch size was 1.0. At the high rate it was 2.8. Time per request grew only from 2.5 seconds to 3.9 seconds. Amortized inference time per decision fell from 6.4 seconds to 1.6 seconds. A decision can require several model requests, which is why its total time can exceed time per request.

This result explains why removing pass-through did not overload the single Router in the first experiment. The system could absorb a higher event rate by batching. It does not prove that one Router will scale forever. It does show that a single long-lived Router is a defensible default for a team of modest size, and that sharding should be introduced only when measurements justify the loss of global context.

Four problems the architecture has not solved

The experiments support the core scheduling claim only within a simplified setting. DeepSeek Harness identifies four large open areas.

1. Scaling the Router and Worker topology

A single Router, Thread subscriptions, and little direct Worker-to-Worker communication have handled most of the team's daily work at low engineering cost. It is not clear how the design should change when tasks become larger and more tightly coupled. The team still needs to determine when to shard the Router, how finely to shard it, when Workers should communicate peer-to-peer, and which collaboration topologies work best.

Model and system co-design is another direction. A model trained specifically to judge events, dispatch batches, and follow recall chains might improve Router throughput and decision quality. Memory eventually becomes a harder constraint. Chain of Recall can retrieve recent task history on demand, but a system running for months needs a stronger long-term memory design.

2. Designing a product without sessions

If sessions disappear from the user's workflow, what replaces them? The chat window is not inevitable; it became central partly through path dependence. Some interaction will move into domain-specific surfaces, such as issue trackers and pull requests. Sessions may remain visible for familiarity, but one visible conversation no longer has to map to one internal session.

The harder interaction problem is mid-task intervention. The article focuses on task initiation and sign-off, yet current models still need human input on key details. A product needs a way for a person to inspect, take over, or collaborate with background work without destroying the autonomy that made the work efficient.

3. Defining context and permission boundaries

The architecture assumes one Super-agent instance has a global context for its scope. Organizations complicate that assumption. Deciding how to provision instances becomes a decision about which teams share context and which teams require isolation.

Once isolated instances exist, they need agent-to-agent communication across permission boundaries. A personal agent may need to coordinate with a team's Super-agent without inheriting all of its data or authority. The article uses A2A in the general sense of agent-to-agent communication, not as a claim about one specific protocol. Secure, reliable collaboration between agents with different context and permissions remains open.

4. Security and privacy

Event-driven operation broadens the attack surface. Chat messages, issues, code, documents, and external tool results can all contain untrusted input. A prompt injection or malicious repository instruction may try to turn the agent against the user or the execution environment.

The cloud-loop and endpoint-daemon design implicitly assumes a trust relationship between the cloud and each endpoint. Endpoints hold private code, sensitive data, and credentials. If an attacker compromises the cloud Agent Loop, every connected endpoint could become reachable. Credentials can also leak without a server compromise if they enter the model's context during normal execution.

The authors' conclusion is direct: the agent needs a way to use credentials without seeing them. A useful Super-agent must retrieve context from many environments while maintaining strong isolation, least privilege, and auditable action boundaries.

What the prototype does, and what it does not prove

The public dsh-superagent-prototype is useful precisely because it is narrower than the article's full vision. It is an MIT-licensed TypeScript bundle for DeepSeek Harness. The repository describes a proactive coding agent for one GitHub repository, with optional Feishu integration. It listens to events, creates a work item for an allowed request, executes the work in an isolated agent session and directory, and answers in the original conversation, often with a pull request.

The project's operating principle is closer to attention accounting than to autonomous volume:

Take as little human attention as possible and create as much value as possible. The agent acts only when asked or when a written team rule allows it, and speaks only when a person must act or can use a result.

The implementation contains the building blocks one would expect from the architecture: a main Router-like session, isolated worker sessions, Trigger admission, Thread subscriptions, GitHub and Feishu sources, worker slots, retries, stored effects, and a management panel that surfaces items needing a person. It also documents recovery behavior, background jobs, merge rules, and the difference between working, waiting, blocked, failed, and ready states.

The repository is equally clear about its limits. It is research code, not production-ready software. It is not an official DeepSeek product. It was adapted for publication and is not identical to the internal version or to every implementation described in the article. Some ideas in the article are future directions rather than shipped behavior. The prototype is a way to validate parts of the technical approach, not proof that the complete Super-agent has been solved.

The real shift: from invocation to collaboration

The article does not propose a new model architecture or claim that one prompt can produce autonomy. Its contribution is to move familiar systems ideas into the agent stack: separate control and execution, use fast and slow admission paths, cache context selectively, batch queued work, exploit speculative execution, persist state independently, and monitor task progress from outside the system.

These ideas matter because the bottleneck is moving. As models need less step-by-step supervision on individual tasks, human attention becomes the scarce resource. A team cannot obtain more leverage by opening more chat windows and manually remembering which agent knows what. It needs an agent that remains one collaborator while the system manages sessions, distributes work, preserves context, and routes attention back to the moments where a person can make a difference.

The internal DeepSeek Harness instance described in the article is already used for reproducing and fixing issues, answering code review, and developing DeepSeek Harness itself. The public prototype demonstrates a narrower slice of that behavior. Both are best understood as evidence for a direction: the agent becomes less like a chat window waiting for commands and more like infrastructure for continuous, bounded collaboration inside the environments where work already happens.

---

Source: DeepSeek Harness, “Exploring Super-agent Design: Towards a More Autonomous Agent System,” published on X on 2026-11-01. Original post: x.com/DeepSeekHarness/status/2116857257245987236. The X Article is x.com/i/article/2116829218935857152. System implementation described by Yujia Qiao and the DeepSeek Harness team; Yujia Qiao implemented the system and wrote the original article. This edition is fully adapted from the article's English machine translation and cross-checked against the public prototype documentation.