DeepSeek’s Super-agent Design Explained: Architecture, Experiments and Open Problems

A capable coding agent can fix a bug while you do something else. Running a dozen such tasks creates a different problem: someone still has to remember which session owns each task, carry context between conversations, notice failures and decide when to step in.

The DeepSeek Harness team’s “Exploring Super-agent Design” proposes moving more of that coordination into the agent system. Its design pairs a persistent coordinator with separate workers, routes events from places such as chats and code reviews, lets long commands run in the background, and separates the agent’s state from the machines where it acts. An outside supervisor would watch for failures and stalled work.

The team reports using an internal system to help reproduce issues, respond to reviews and develop DeepSeek Harness. It also reports preliminary experiments in which its architecture completed simulated tasks faster than two single-session setups, while reading more cached tokens. Those experiments test scheduling, not whether the agent writes good code or saves an organization money.

There is also a public research prototype. The team says it differs from the internal system and the article’s design, is not an official DeepSeek product, and is not production-ready. We did not install or test it. This explanation is based on the full English machine translation supplied to us. The linked X article is the English translation; we could not fetch it directly or compare the supplied text with the Chinese original. The article credits Yujia Qiao with implementing the system and writing the piece, based on shared work by the DeepSeek Harness team.

What is a Super-agent?

Despite the name, the proposal is an architecture around models and tools, not an announcement of a new model. The authors describe an agent that can work across tasks, channels and machines without making the user manage each underlying session.

They set out four goals:

• Continuous: The agent can connect a discussion in one place to related work somewhere else. A change in direction in a pull-request review should reach the work that began in chat.
• Productive: It can progress several tasks and receive further instructions while earlier operations continue.
• Proactive: It can respond to relevant events under policies instead of waiting for every step to be requested, and stay quiet when it has nothing useful to add.
• Persistent: It remains available across machine restarts and network interruptions and can recover from operational problems.

These are design aims, not demonstrated guarantees. The authors say that, in their experience, a person can follow roughly three to five active sessions at a time. That is an observation from their work, not a measured universal limit. Their larger point is that the friction grows when people must act as the link between otherwise isolated agents.

The distinction matters because an agent loop can already combine reasoning and actions. The ReAct research describes a pattern for interleaving those steps. DeepSeek’s article is concerned mainly with the surrounding system: deciding which events deserve attention, assigning work, preserving context and managing execution over time. A synchronous tool loop is one implementation choice; ReAct itself does not require every tool to block.

One coordinator, many workers

Imagine a team member reports a bug in chat. An agent starts investigating. Later, a pull request appears, continuous integration reports a failure, and a reviewer asks for a change. Ideally, each event reaches the work already in progress, while the person can see what needs their attention without reconstructing a conversation across several tabs. This is an illustrative workflow, not a test we performed.

The article considers two simple ways to organize it, each with a cost. Send everything to one session and that session has a shared history, but unrelated details accumulate and long tasks compete for attention. Create a fresh session for every event and work can run concurrently, but the sessions may lack shared context or send disconnected replies.

The proposed compromise has two logical layers:

1. A long-lived Router receives interactions, maintains a high-level view of tasks and relationships, dispatches work and coordinates communication.
2. Workers carry out individual tasks in isolated contexts with the tools and information they need. A complex Worker can itself use subagents or a team of agents.

The Router is deliberately kept away from substantive execution. The authors suggest it can even operate without a shell, while Workers use more capable models for work that determines the result. Their view is that routing can often use a lighter model; the article does not establish which model is sufficient for a particular deployment.

This division also changes the usual team-lead analogy. An agent lead coordinating a tightly coupled task may need to understand every dependency and direct each step. DeepSeek’s Router is meant to assign separate tasks and understand their relationships at a higher level. Neither layer has to be implemented as exactly one model session forever: both are logical responsibilities that could be divided further.

In the article’s design, Workers report conclusions to the Router, and the Router handles external replies. The public prototype has a different reply path, discussed below. Keeping task contexts separate reduces one source of confusion, but it does not automatically stop two Workers from editing the same code or making conflicting changes. The proposed event subscriptions give them a chance to notice overlapping work; they are not locks or a guarantee of conflict resolution.

From a stream of events to a task

A continuously connected agent faces far more input than a person’s direct requests. A message in a group chat, a review comment, a CI result or a calendar reminder can all be a Trigger. Most will not justify action.

The authors split the decision into a fast path and a slower semantic path. First, ordinary code filters events using relatively stable rules: which source or group produced an event, which users or bots are allowed, and whether that source should be ignored, considered or respond only to direct requests. An LLM then assesses candidates that need interpretation against the relevant instructions and context. The aim is to avoid asking a model to deliberate over every passing message.

Related events are grouped into Threads: for example, a pull request and its review comments, or a messaging topic and its replies. When a Worker takes responsibility for a task, it can subscribe to the relevant Thread. Later events can then pass directly to that Worker through code, without a new model routing decision for every comment. The Router retains a global view, and an event that falls outside the Worker’s task can be returned for fresh routing.

Subscriptions are many-to-many. One Worker may follow a chat and a pull request for the same issue; several Workers may subscribe to a shared pull request. That makes shared changes visible to those Workers, though visibility alone does not decide which change should win.

There is a practical distinction between receiving context and receiving authority. A new review comment may be relevant to a task without authorizing every action it requests. The prototype formalizes that distinction more explicitly through mandates and acceptance rules.

Context as a managed cache

A system that keeps receiving events cannot simply place its entire history in every model call. The context window is finite, and additional material can crowd out the information needed for the current decision. At the other extreme, providing almost nothing forces repeated retrieval.

The article borrows two ideas from computing. Inline puts likely useful information directly into the current context. Spill keeps larger or less immediately relevant material outside it, leaving a short summary or reference that can be expanded later. Nearby messages, a reply’s parent, related identifiers and neighboring review comments are examples of material that might be worth including early because they are likely to help interpret an event.

The authors call their retrieval approach Chain of Recall. Objects such as events, Threads and Worker sessions have identifiers and references to one another. The agent can follow those links as needed: from a new comment to its Thread, from that Thread to a related Worker session, and from there to another review discussion. Each step can expose further summaries and identifiers.

This provides a way to find history; it does not guarantee that the model will retrieve the right history or interpret it correctly. The team identifies long-term memory, particularly after months of operation, as an unresolved scaling problem. A persistent record and reliable understanding of that record are separate challenges.

Proactivity, with a reason to stay quiet

The article’s idea of speculative execution is to begin useful preparation before someone asks for the finished result. A meeting invitation might trigger a conflict check, background research or a draft. For software work, the team describes a policy under which its internal system silently tries to reproduce a reported issue and find a simple fix, communicating when it has confirmed the issue and has a useful result. The team reports this behavior; we have not observed it ourselves.

The useful unit is often preparation rather than an unsolicited announcement. A speculative draft that is never used consumes compute, but can be discarded. Our assessment is that an external side effect—posting a comment, changing shared data or merging code—needs a distinct authorization boundary because undoing it may be harder. The article does not provide a dollar return for speculative work or establish that broad autonomous action is safe.

The public prototype’s documented authorization model reflects a narrower approach: proactive modes include off, observe and auto, with observe as the default. In observe mode, the system records what it would accept without starting inferred work. Permitted explicit requests can still proceed. Accepted work gets a scoped mandate, and receiving a subscribed event does not itself expand that mandate.

Long commands should not monopolize the conversation

A command that takes ten minutes to run need not make a user wait ten minutes to send a correction. In the design described by the authors, a tool can start a background job, return control to the agent loop and deliver its result later as an event. A stop operation can cancel work. New input can be processed at the next inference boundary while the job continues.

The authors call the resulting interaction full-duplex. It describes responsiveness while operations are in flight; it does not mean a model can interrupt every token already being generated or reason about an unlimited number of things simultaneously. The article says this asynchronous mechanism exists in DeepSeek Harness but was not enabled by default at the time of its account.

Communication format matters too. A short message may be appropriate when someone needs to make a decision; a pull request needs enough background, change description and verification detail for a reviewer to assess it. The team says it found a 100-word cap useful for instant-message replies. That is a reported local practice, not a universal rule. The broader objective is to make interruptions useful, while leaving detailed execution records in the places suited to them.

Separating the agent from its machines

A local agent often ties together three things: the computation running its loop, the state of its session, and the environment where commands execute. If the laptop sleeps, all three can become unavailable together.

The proposal separates them in two steps. First, session and task state live in persistent storage while the compute running the agent loop can be replaced or restarted. Second, the agent loop can reach execution environments elsewhere through lightweight endpoint daemons. The endpoint runs commands and returns results; the agent’s session state lives separately.

This matters because a real development machine is more than a clean copy of a repository. It may hold uncommitted changes, specialized hardware, dependencies, intranet access and credentials. Recreating all of that in a cloud environment can be difficult. The authors’ Bring Your Own Machine idea is to connect existing machines as well as cloud or on-demand environments. When an endpoint is offline it cannot run commands; in the proposed arrangement, the cloud-side agent can remain active and resume endpoint-dependent work after reconnection. The article does not establish an uptime guarantee.

The team explicitly credits Anthropic’s managed-agent work for the related separation of the agent’s “brain” from its execution environment. DeepSeek’s stated emphasis is on personal machines and their existing local state, including intermittent connectivity. The idea belongs to a broader systems-design discussion, not to one team alone.

A Watchdog for agents that are alive but stuck

A process can be running while making no useful progress. A Worker might repeatedly attempt the same failing operation, lose sight of its task or wait on an external problem. A simple “is the process alive?” check would miss some of those cases.

The proposed Watchdog is a separate agent session triggered by scheduled messages. It would monitor infrastructure failures and use model judgment to assess whether Workers are progressing, then attempt repairs or recheck temporary failures. Maintainers could ask it about failures and adjust operational rules through it.

That is an ambitious supervision design, not measured proof of self-healing. The article supplies no detection accuracy, false-positive rate, repair success rate or security evaluation for the Watchdog. A supervisor with tools also becomes another component whose permissions and mistakes matter. The public prototype’s deployment guide describes setting up an external hourly status and recovery check; that is narrower than the full semantic supervision described in the article.

The experiments: faster simulated scheduling, more cache reads

The strongest quantitative evidence in the article comes from a preliminary scheduling experiment. Four designs received streams of group-chat and GitHub CI messages. A run contained about 300 messages, including roughly 20 work requests, with casual conversation, follow-ups, cancellations and CI feedback making up the rest. Each design ran five times.

The critical detail: coding work was simulated by a tool that consumed time. The results measure scheduling and coordination in that setup, not code quality, correctness or real-world bug fixing. The figure’s caption also says message intervals and work durations were scaled to one quarter while model-call times were not scaled. That changes the timing balance, so the reported minutes should not be treated as production estimates.

Source: the team’s preliminary experiments. Completion time runs from a work request to its result message. Figures are team-reported; we recalculated the comparisons below but did not reproduce the tests.

Against the neutral-prompt baseline, the Super-agent’s median completion time was 39.2% lower, while its cache reads were about 3.8 times as high. Against the delegation-first baseline, its median was about 10.1% lower. The p95 figures were lower as well, but five runs and rounded percentiles do not establish statistical significance or predict behavior across other workloads.

Prompting mattered in these particular baselines. The authors say the neutral-prompt session did not delegate in any of its five runs. The delegation-first version delegated in four; in the fifth, it judged the work small enough to do itself, contributing to a long tail. This illustrates a reason to enforce a division of responsibilities in the system, but it does not show that every single-session agent or delegation prompt would behave the same way.

The pass-through comparison is also instructive. Without direct delivery to subscribed Workers, reported cache reads increased from 23.2 million to 31.8 million and the Router made about 30% more decisions. Expressed in the other direction, adding pass-through reduced cache reads by 27.0% relative to the no-pass-through version. The reported completion times were similar, and the no-pass-through p95 was slightly lower; this table does not show a consistent latency improvement from pass-through.

Cache-read tokens are neither total tokens nor a dollar bill. The account does not provide enough pricing, model, output-token and infrastructure detail to calculate total cost or return on investment. The experiment also does not measure human review time, notification burden, accepted pull requests or incidents.

What batching did—and did not—show

The team ran a separate stress test on the Router. Here the Router used a real model and Workers used mock models. As the arrival rate of events requiring decisions rose from about one to about 40 per minute, events accumulated and were processed in larger batches.

In this setup, request duration increased more slowly than batch size, while reported amortized inference time per decision fell by 75%. A decision can involve several model requests or context-retrieval steps, so dividing request duration by batch size does not reproduce that metric.

This is evidence that batching helped the tested Router handle the offered workload. It is not an end-to-end measure of how long a person waited for a response, a certified sustainable throughput limit, or proof that an organization can process 40 useful tasks per minute. The account does not supply the full workload generator, raw per-run data, confidence intervals or a decision-accuracy measure needed to assess the result more broadly.

What the public prototype actually provides

The prototype README describes a DeepSeek Harness research bundle for one GitHub repository, with GitHub, optional Feishu, isolated task sessions and directories, and a web panel. It says the public code was adapted and differs from the internal implementation and article. A proposal for cloud-hosted agents spanning personal machines should therefore not be read as a list of features already delivered in this repository.

The documented domain model groups source events into Threads and accepts authorized work as Tickets with Mandates. Assignments connect execution to that work. The model is useful because it makes origin, scope and relationships explicit, but a relationship between records is not permission to act.

There is also a material difference in communication. While the article’s Workers report to the Router for external replies, the prototype’s prompt documentation allows Executors to acknowledge and handle follow-ups within their scope; questions can be reported to the main session for forwarding. Readers should use the article for the proposed division and the code’s documentation for the public implementation.

The execution documentation describes per-Ticket sessions and directories, Worker concurrency limits, and five-second foreground limits that let longer commands continue as jobs. Instructions about delivery do not replace repository controls: required approvals need enforcement through GitHub branch protection.

The deployment caveat is more consequential than the label “isolated directory” might suggest. The deployment guide says both presets use danger-full-access as the operator’s operating-system user. Wrappers and separate directories are not a security sandbox; the process can access what that user can, including the home directory. The guide recommends a dedicated OS account for isolation.

The documented architecture uses a local SQLite database and a directory lock to prevent another process writing the same state. It also describes persistent effects with retries and notes that old records are not yet deleted. These are concrete research-code choices, not evidence that the proposed elastic cloud system has been deployed or independently tested.

The hard problems are still open

The authors identify four areas that determine whether the concept can grow beyond a small team’s workflow.

Scaling coordination. A single Router has the benefit of a shared view, but may eventually become a bottleneck. Splitting it into shards could increase concurrency while fragmenting memory. Direct communication between Workers may help tightly coupled tasks, but introduces more coordination choices. The article proposes investigation, not a settled threshold or topology.

Making work legible to people. If one visible conversation can correspond to several underlying sessions, users need a way to see tasks, inspect decisions, intervene and take over. Hiding session management should not mean hiding what is happening. Different domains may require different interfaces: a pull request can carry useful structure that a chat window cannot.

Setting context boundaries. A personal agent and a team agent may need different access and different memories. When they collaborate, they must communicate across those boundaries without silently sharing everything. The article uses “A2A” generically for agent-to-agent communication; it does not establish an implementation of a named protocol.

Security and privacy. An agent that reads external content and can execute commands crosses a serious trust boundary. A malicious instruction can be embedded in material the agent is supposed to analyze; prompt injection remains an open security problem. Admission rules and instructions to treat comments as data are helpful design elements, but neither proves that later untrusted content cannot redirect behavior. The authors also note that credentials can reach model context during normal work, even without a server intrusion.

Under the study’s synthetic workload, separating coordination from execution changed completion times and resource use. Assessing broader autonomy requires stronger evidence: reproducible real-task evaluations, decision accuracy, total cost, human supervision time, failure and recovery rates, and adversarial tests alongside the scheduling numbers.

The Kingy Brief

Get the free AI price sheet.

26 AI plans and models on one page, from official pricing pages, updated every month. Free when you join The Kingy Brief: AI changes, original tests and one practical thing to try, Fridays at 09:00 Vancouver time.

Free · Double opt-in · Unsubscribe anytime

Privacy policy

Sign up for The Kingy Brief on Beehiiv.

Signup help and newsletter schedule

Signup form provided by Beehiiv. After submitting, check your inbox for "Confirm your subscription to The Kingy Brief" and open its confirmation link. Your price sheet download is on the page that opens. Check Spam or Promotions if you cannot find it.

Fridays at 09:00 Vancouver time: source-checked AI changes, original tests and one practical thing to try. We skip a week when there is not enough verified material. Free. Unsubscribe anytime.

Get the free sheet