DeepSeek Harness team publishes long-form article on Super-agent design exploration

By Moer Observation

Many engineers who have brought AI into their daily development work have all had a similar maddening experience: you just finish typing a prompt, get up to grab a glass of water, and come back to find the process in the terminal long since stuck halfway, with the cursor sitting alone on the screen, waiting for you to manually press Enter to confirm.

For a while now, the marketing for all kinds of coding assistants has emphasized how fast they generate: type a line of natural language, and the large model instantly spits out hundreds of lines of code, with all the test cases in the terminal turning green. But in real software teams, this seemingly impressive instant feedback is turning into a high-frequency tug-of-war over energy.

Every time the agent reads a file, changes a line of configuration, or runs a command, it has to pop up and ask for permission. You just finished explaining the business context in a group chat, then turn to the code review tool to suggest changes, and have to carry the whole backstory over again. Once a task involves cross-module troubleshooting or dependency refactoring, the conversation window quickly gets stuffed to bursting by dozens of rounds of context, and one slip means the answers stop matching the questions.

The one who laid this awkwardness bare was an architecture proposal from a top domestic technical team. On the evening of October 31, 2026, the DeepSeek Harness team published a long technical article titled "Super-agent Design Exploration: Toward a More Autonomous Agent System" on its official WeChat account, systematically laying out a research prototype design aimed at software engineering.

According to the official article, the team did not spend much of the opening hyping how fast large models can write runnable code, but instead stated a core principle right up front: occupy as little of people's attention as possible, and deliver as much value as possible.

This long technical article directly points out the most awkward bottleneck in AI programming today: as the underlying models' single-point generation capability grows stronger and stronger, the bottleneck limiting output scale has long since changed—what is really holding teams back is the attention limit of human developers. Forcing the agent to reply to humans instantly and ask for permission in a chat box often just wears people out. Throwing it into the background and turning it into a distributed system that can schedule itself and isolate its parts from one another is the path AI should take to truly integrate into software engineering.

In existing coding agent architectures, the single-session serial mode has never been cheap—what it consumes is human energy.

Most mainstream code assistants today, whether command-line tools or desktop plugins, are basically built on a single think-and-act loop. This little chat box is stuffed with too many chores: it has to understand human language on one hand, reach out to run command-line operations and read and write files on the other, and still withstand the ultra-long context of dozens of rounds of tool calls.

According to the observations of the DeepSeek Harness team in the article, a human engineer at work can usually keep only three to five active sessions in deep memory and effectively follow up on them. Once that number is exceeded, the human brain can no longer maintain the continuity of multiple contexts and is forced to jump back and forth between different chat windows.

Active sessions usually number only three to five

The more realistic trouble than model capability lies in the collaboration gap. In real R&D scenarios, communication is never single-point. A product manager may propose a plan adjustment in an instant-messaging group, an architect may give two lines of comments in code review, and the CI pipeline may report a compilation failure in the background. Under a single-session architecture, these three pieces of information are scattered across different platforms, and the agents are cut off from one another; the only synchronization link is the harried human developer in the middle.

This design reduces developers to cheap context porters and approval tools for high-frequency click-to-confirm. The model may seem to reply instantly in front of the screen, but in reality it is pushing the most tedious multitasking state management onto humans. When most of an engineer's energy is spent checking what the model intended to execute a few minutes ago, so-called efficiency becomes a hidden drain on energy.

Completely separating the "dispatcher" from the "doers"

Since a monolithic loop cannot handle complex tasks, the most intuitive engineering solution is to borrow the divide-and-conquer thinking of modern operating systems.

The prototype approach broken down in the article centers on splitting the system into two layers: a Router resident on the front end that oversees the whole picture, and multiple mutually independent Workers mounted on the back end. The two are clearly decoupled in responsibilities, permissions, and model resource allocation.

The Router, resident in group chats or repository backends, serves as the system's scheduling hub. It is only responsible for reading incoming event messages, assessing intent, and generating work orders with strict permission boundaries, which the article calls Tickets with authorization letters. The Router itself does not even need to be equipped with underlying high-risk execution tools, and in terms of resource allocation it only needs to run a lightweight model. It does not touch specific code changes and does not take part in long logical reasoning; its purpose is to keep the global interaction channel open so that it does not deadlock over some complex task.

The one that really tackles the hard problems is the Worker, automatically started in the background after receiving a ticket. Each Worker has an independent execution session and an isolated workspace. As long as the environment allows, the system automatically assigns the Worker an independent temporary Git worktree, letting it mess around freely in a clean copy of the code—changing configuration and running tests without affecting the main branch.

This physical isolation directly cuts off cross-contamination between long tasks. Developing a new interface and troubleshooting production errors can be advanced in parallel in the background by different Workers; even if one of them crashes due to an infinite loop in the code, it will not contaminate the main branch, let alone confuse the Router's main control context. The rough and heavy work is absorbed in the background by isolated child nodes, while externally the dispatcher uniformly reports to humans, and only then does multi-task parallelism have reliable engineering support.

Don't let all information harass the brain

Beyond separating execution from scheduling, how to remain restrained amid the flood of complex messages is the key to whether an agent can truly take up residence in a team.

In a daily collaboration environment, group chat discussions, code commit pipelines, and automated test errors are generated all the time. If the agent behaves like an eager new intern who craves attention and jumps in on every message, the entire R&D team's attention will instantly be drowned by notifications.

In its design, DeepSeek introduced an event filtering and pass-through mechanism similar to traditional network protocols. When messages pile up, the system first uses a few lines of lightweight code rules to block small talk and noise at the door. Only real events that hit the whitelist are handed to the large model to understand intent.

For potential tasks inferred from discussions, the system sets an extremely restrained default level in permission control. DeepSeek has put a tight leash on proactive task-taking: by default, only observation mode is enabled. Even if the large model sees at a glance that the code is flawed and should be refactored, it only dares to quietly note in the local log that this job could have been taken; without a human saying yes, it absolutely will not presume to claim a ticket and change the code.

Another highly practical engineering design is subscription pass-through. After a Worker claims a Pull Request, the system automatically establishes a many-to-many event mapping at the underlying layer. All subsequent review comments on that PR are delivered directly by the underlying system to the Worker process responsible for the task, with no need to go through the Router again for a second round of reselling. According to simulated test data published by the DeepSeek Harness team, after eliminating repeated interruptions to the main controller, the number of redundant decisions by the scheduling hub dropped by about 30%, and the computing resources needed to read the cache were reduced by more than one third. Only by compressing the communication link inside the context of the work actually being done can the system stay quiet amid multi-party collaboration.

Only if the math works can it join the team

When a technical solution moves from a single-machine demo to round-the-clock team residency, the final assessment never looks at how smart a single conversation is, but only at the robustness and operating efficiency of the entire system.

In the blind imagination of many teams, the more omnipotent the agent seems, the better—ideally with unlimited memory and autonomously thinking nonstop in the background. But in the real computing ledger, such castles in the air can collapse at any time because of a brief network glitch or a process crash.

What DeepSeek demonstrates in its long article is a typical engineering perspective of disenchantment. To cope with the freezes and anomalies unavoidable in long-running operation, the system completely separates state storage from model computation. Task authorization status, ticket progress, and interaction history are all persisted to a local lightweight database, while the execution environment is fully containerized. Even if the local host restarts or the session process times out, the system can be revived through an external independent watchdog mechanism, read the last snapshot from the database, and continue advancing, without humans having to type out the whole cause and effect again.

In the team's simulated scheduling experiment with about 300 messages and 20 work requests, this divide-and-conquer system's task completion time showed a clear engineering advantage. When facing high-concurrency message bursts, this divide-and-conquer system's tail latency (P95 task duration) was firmly capped within 15.7 minutes. By contrast, the single-session solution without layering, once concurrency rose, had its slowest task dragged out to nearly half an hour.

P95 task duration capped at 15.7 minutes

This system-level throughput is not without cost. Multi-process concurrency and fine-grained state maintenance essentially use more model invocation frequency and cache overhead in exchange for the stability of overall execution and the liberation of human attention. For software engineering, as long as developers can be saved from endless context alignment, this incremental computing resource cost is worthwhile on the team's ledger.

Final thoughts

But the underlying laws of software engineering never care about human niceties; they recognize only state machines, pipelines, and deterministic delivery interfaces.

The most interesting part of DeepSeek's architecture proposal is that it in turn questions instant replies themselves. It does not spend effort on how to make the large model speak more politely or make typing animations in the terminal cooler, but instead moves the scheduling rules, permission sandboxes, and caching mechanisms that computer systems have tested for decades, unchanged, into the large model architecture.

A truly mature industrial-grade agent does not need to be a chatterbox assistant that keeps people on edge in the R&D pipeline; it is enough for it to honestly be an automated tooling system sunk at the bottom of the code repository, not grabbing attention, and delivering according to the rules. Don't perform those flashy instant-reply tricks in the chat box; just steadily finish the dirty work in the background. Only when it can deliver silently will AI programming bid farewell to being a geek toy and mature into a reliable foundation in software engineering.