Animated explainer: DeepSeek's Super-agent architecture

The DeepSeek Harness team published a long essay: Exploring Super-agent Design: Towards a More Autonomous Agent System. It is not about chat tricks. It is about what sits underneath an agent that lives in the company group chat and on GitHub and pushes several things forward at once. The original is engineering-heavy; below we unpack it as: where people get stuck → a diagram → the mechanism.

Inside DeepSeek there is a Super-agent. It lives in the company's group chats and on GitHub, and it moves several things forward at the same time.

On the ground it looks roughly like this:

One agent, working on both sides at once.

Along the way, someone in the group complained about a bug — without @-mentioning the agent. The agent reproduced it on its own, found the root cause, and submitted a pull request with the fix.

Nobody called it at any point:

Nobody called it, and it still got to work.

This is not an idealized demo scenario. It comes from that instance, which keeps running. The whole essay is really answering one question: what does this "always on, handle events as they come" form need to look like underneath?

People hit the wall first

Single-task agents, with Coding Agents leading the way, have already shown that models can use tools to solve complex problems, and need less and less step-by-step human supervision.

At the same time, models are getting better at multi-agent collaboration. Organizing and scheduling a batch of agents across sessions is starting to become feasible.

The human role shifts with it: less hands-on involvement in low-level execution, more energy spent on decisions and acceptance.

That is where personal assistants (Personal Agents) come from — plugged straight into everyday messages, calendars, email and work platforms, always watching the information flow, taking care of things along the way.

"Always on, handle events as they come" — personal assistants are only one use of it. In commercial settings like software development, it is just as valuable.

The problem: today's mainstream agent designs cannot carry multi-tasking and team collaboration at that scale.

Agents mostly use a single Session as the basic unit. Sessions do not talk to each other. If you want to push several things at once, you have to switch between windows yourself and remember where each Session left off.

DeepSeek observed that one person can usually keep up with only 3 to 5 active Sessions at a time.

Once there are more Sessions, people can no longer keep up.

When windows pile up to that number, attention breaks:

A single task is limited by the model; several at once are limited by people.

So what if you hook an existing agent up to a CLI, MCP or external connectors so it can also receive outside messages?

You can. But there are problems.

A single session is synchronous and blocking — until one thing finishes, the next cannot get in. The contexts of multiple tasks get tangled together. Once the local computer goes offline, the agent stops too. Maintaining it takes a lot of human effort.

So the agent needs to be unbundled from "one session a person opened by hand" and turned into a continuously existing entity: it remembers context across sessions and pushes several complex things forward at once without them stepping on each other.

This form of agent, together with the system architecture behind it, is what DeepSeek calls Super-agent.

Take that internal instance running on DeepSeek Harness again: the same development task can be raised in the group chat and continued on GitHub. When the same thing is said somewhere else, it still picks up the thread.

A plan agreed in the chat, changed in the PR — both ends lead back to the same avatar:

Say it somewhere else, and it still picks it up.

The "fixes a bug even though nobody @-ed it" scene at the start also comes from this instance: it keeps watching feedback in the public group chat and, without anyone naming it, proactively locates the root cause and submits a fix.

Four traits, five modules

DeepSeek gave Super-agent four basic traits:

Continuous: you talk to it in familiar places like the group chat and GitHub comments, and it always feels like there is only one agent. "Does Session X's context have piece of information Y?" is its problem, not yours. For example, if you first settle on plan A in the group and later switch to plan B in a pull request comment, it understands and adjusts.

Efficient: it replies quickly and can finish several complex things in parallel, with high quality; it can take the next instruction before the previous command or task is done.

Proactive: it watches what happens in the environment itself and pushes forward the things worth handling; when it is not needed, it stays quiet.

Durable: always online, plugged directly into your real work environment, and able to recover by itself when something goes wrong over long runs.

What the four words look like in concrete scenes:

Four words, not slogans.

A single ReAct Loop (the model thinks one step, calls a tool once, looks at the result, then thinks the next step) cannot hold all four at once. Underneath there has to be a matching architecture.

Similar design constraints lead to similar architectures. Whether it is a personal assistant or an agent for software development, as long as the goal is "always on, responding concurrently to events in the environment," the foundation will most likely look much the same.

And the problems met along the way are highly similar to ones traditional computer systems research has studied for decades. So many classic system design ideas still work here. You will keep seeing old faces: Fast Path, caching, locality, speculative execution, compute-storage separation.

Real deployments will come in many variants, but DeepSeek believes the following five modules form the basic framework holding up those four traits:

1. Two-layer architecture: continuous and efficient at the same time
2. Event-driven: proactive
3. Human-facing interaction: continuous and efficient while going back and forth with people
4. Separating compute, state and environment: always online across devices
5. Watchdog: recovers by itself when something goes wrong

A group chat message, from arriving to getting a reply, passes through these five modules one after another.

The message comes in and clears five gates in turn:

One message, five gates.

Two-layer architecture

To keep interaction continuous across channels while running many tasks efficiently in parallel, the way sessions are organized underneath runs into one fundamental trade-off: continuity versus throughput.

One extreme: give every event to the same Session. Context is as continuous as it gets, but a single ReAct Loop can only work serially, step by step. Speed has a ceiling, tasks finish slowly, throughput is low; the intermediate details of several tasks get mixed together and drag down the quality of the work.

The other extreme: open a new Session for every event. Concurrent throughput is highest, but tasks are often not fully independent; without global context the results of different Sessions are disconnected; several Sessions each reply to the user on their own, and the interaction becomes a mess.

Where each extreme gets stuck —

Take a look:

Continuity or throughput — picking just one does not work.

DeepSeek's answer is to split "maintaining global continuity" and "highly concurrent execution" into two layers:

• On top is a resident Router layer that receives all human interaction and handles global coordination
• Below is the Worker layer; each Worker's context is isolated, and they execute concrete tasks concurrently

With two layers, people only talk to the Router, and the Workers do the work:

Chatting and working, split apart.

Context management and concurrent execution are both taken over by the system underneath. On the user side you barely notice Sessions exist; you always face the same Super-agent.

Seen this way, making users manage Sessions by hand is largely design inertia carried all the way up from the underlying LLM API. Sessions should be an internal implementation detail of the system.

There is another layer to it: today's Session does two jobs — technically it manages context, and in the product it manages projects. Once the product form is decoupled from the underlying Session, project management can be designed separately from Sessions. "What kind of interaction and task management to give users" becomes an independent product question (it comes up again in the open questions at the end).

Also, "two layers" describes a logical division of labor. Each layer can have its own internal structure and be made of several Sessions.

1. The Router layer

The Router layer is resident and receives human interaction from every entry point. All cross-task information and decisions are gathered here. It is at once the global Sequence Point (where everything is put in order), the coordination point, and the memory.

To keep this global node light and fast, the Router only handles interaction with people and task dispatch; all concrete work is handed off, and it can even go without a Bash tool.

One central node dispatching to multiple execution nodes looks a lot like a common Agent Team at first glance. The difference is how fine-grained the central node's management is.

Managing tasks, or managing every step:

Manage the task, not the steps.

An Agent Team is mainly used to break down a single complex task and have different roles collaborate. Sub-steps are usually tightly coupled, so the Team Lead has to understand task details deeply, plan subtasks and coordinate members at high frequency, carrying a heavy reasoning load itself.

The Router only deals with high-level relationships between tasks and with dispatch. How to break down the inside of a single task is left to the Worker.

Conversely, if you use prompts to constrain an Agent Team's main session to only handle outside interaction and hand different tasks to members to push forward independently, that can also count as this two-layer architecture.

DeepSeek's practical experience: the Router's job is often less complicated than you would think, and a relatively lightweight model often balances speed and quality well.

The Router layer can also be made of several Sessions inside, and some of its logic can even be written in ordinary code. DeepSeek chose the most direct approach: a single resident LLM Session as the core of the Router.

Can one session handle the messages of a whole team?

Better than it looks. The reason is batching: environment events (the Triggers discussed later) that arrive while the previous round of inference is running are held and processed together in the next round, and the extra cost of merging them is small.

At peak times, several Triggers fold into one call:

The bigger the backlog, the cheaper each decision.

When the external event stream is steady, Triggers enter the Router one at a time, and single-response latency is very low.

When events flood in densely and the Router starts to queue, the Triggers that piled up during the previous inference round are merged automatically and injected together on the next LLM call.

Why is merging such a good deal? The Router only does lightweight interaction and dispatch; each step is usually long input, short output. When several backlogged Triggers are merged into one LLM API call, they are computed in parallel during the Prefill stage (the stage where the model reads its input), so the time of a single request grows far more slowly than the batch size.

So within a certain range, the more that piles up, the shorter the inference time per decision actually gets. There are two limits: the context length, and how many Triggers the model can handle accurately in one round.

Section 7 of the essay verifies this quantitatively with experiments, covered later. Together with two more mechanisms, subscription bypass and chain of recall (also later), one resident Router Session keeps context continuous and is already enough at their current team size.

If the scale grows further and one session really cannot keep up, the Router layer can be built internally as multi-stage filtering, or horizontally split (Sharding) into several sessions.

At that point the internal design of the Router layer comes back to the continuity-throughput trade-off: the finer the split, the higher the concurrent throughput, and the less continuous memory and context become between shards. Until global memory is solved, this trade-off will stay.

2. The Worker layer

The Worker layer is made of the sessions that actually do the work. Each Worker's context is isolated, carries the full set of execution tools, and focuses on one thing in its own context.

Workers directly determine task results and code quality, so they usually get the most capable model.

Workers only report status to the Router. Reasoning and tool calls stay inside; the Router replies to the user on everyone's behalf. This keeps concurrency and delivery quality, and avoids several sessions each saying their own thing.

When several tasks run concurrently, each Worker pushes its own forward.

Where they actually collide is usually a shared work environment like the same pull request. As long as they all subscribe to the corresponding Thread (a run of messages under the same topic or the same PR, covered in detail in section 3), they receive the same event notifications and get a chance to notice and resolve conflicts themselves; the few cases that need cross-task coordination are relayed through the Router.

Like the Router, a single Worker can contain several sessions: for a complex single task, a Worker can open Subagents inside, or be an Agent Team itself. All of this is transparent to the Router above.

This structure works well for coding: several unrelated bug reproductions, pull request reviews and new feature work advance at the same time, and nobody blocks anybody.

It is the same for personal assistants. A personal assistant usually has only one chat page in the interface, but when you talk about several things at once in the same dialog, that one front-end chat page keeps the interaction continuous, while underneath each topic can get its own Worker to advance in parallel and draft replies.

Handling several things at once in one dialog looks like this:

One window on the surface, several lines underneath.

Event-driven

To make Super-agent proactive, you first have to change what drives it.

The main input driving the agent changes from prompts a person types into a Session one by one to semi-structured events in the environment: group chat messages, email and calendar reminders, code review comments, CI results… In Super-agent these are all called Triggers.

By listening for and responding to Triggers, the agent can move by itself based on what happens in the environment.

The life of an event, from coming in to being handled, answers four questions in turn: how to filter noise, how to route it to a Worker, how much to put into the model's context, and whether it can act ahead of time.

1. Filtering

Once connected to real group chats and code platforms, the event stream has a clear character: high noise, few things that really need triggering; the vast majority of everyday messages do not need the agent.

If every event had the large model judge it from scratch, neither latency nor compute cost would hold up.

The idea borrowed here is Fast Path / Slow Path from computer systems: large-model inference is flexible but expensive — the Slow Path; hard-coding high-frequency judgments that are already clear and stable into deterministic code gives a fast, cheap Fast Path.

So the first step for an event entering the system is filtering: before calling the large model, deterministic rules screen out the noise, and only candidate events that need semantic understanding are passed to the model. There are two stages:

• Program layer (Fast Path): admission checks done directly in code on definite conditions such as event source, group scope, and user or bot allowlists. For example, different sources can be set to "only respond to explicit requests," "treat as candidate events," or "ignore," screening out most irrelevant messages before the model is ever called.
• Semantic layer (Slow Path): candidate events that pass the program layer go to the LLM, which decides whether to act based on the policies and context written in the prompt. The semantic layer is also a natural-language extension point for people — to switch a policy on or off or add a new one, just edit the prompt.

A message has to pass two sieves before anyone handles it:

Code first, then the model.

2. Routing

The Router layer is responsible for continuity across channels. But if, after a task is handed out, every follow-up event still has to pass through the Router, this global node still carries a heavy load and response latency goes up.

So the Fast / Slow Path trick is used once more, on routing after filtering: the Router only handles cold starts of new tasks and cross-task coordination; follow-up events whose owner is already known are sent by the program straight to the corresponding Worker.

First, meet the Thread. In real work, consecutive events under the same GitHub pull request, the same group chat topic, or the same email exchange form one event stream, called a Thread.

Messages are grouped into strings by what they are about, and all later routing relies on that:

Events grouped into threads; routing follows the threads.

After the Router opens a Worker based on the first event of a Thread, that Worker subscribes directly to the Thread. Event routing then splits into two paths:

• Subscribed (Fast Path): follow-up events in the same Thread are delivered by the program straight to the Worker subscribed to it. If a new event goes beyond the current task's scope, the Worker can unsubscribe or hand it back to the Router for re-dispatch.
• Unsubscribed (Slow Path): the Router still sees all events and keeps the global state, but only judges and dispatches new events nobody has subscribed to yet.

Once subscribed, follow-up messages skip the Router and go straight to the Worker:

Subscribe once, go direct.

Also, subscriptions between Threads and Workers are many-to-many: one Worker can subscribe to several related Threads, and one Thread can be subscribed to by several Workers.

When several Workers meet in the same work environment or the same discussion, new events in that Thread are delivered to all subscribers at once. Each of them can then see what the others did and resolve the conflict themselves.

When two Workers end up changing the same PR, this is how the conflict gets discovered.

Share one Thread, and collisions surface on their own:

A shared Thread lets them spot the collision themselves.

The output side stays the same: Workers report key conclusions to the Router, which replies to the user and syncs global memory.

3. How much goes into context

Once an event is filtered and routed to its target Session, the next question is: how much information goes into the model's context window?

The system's input has changed from limited human prompts to a steady flow of semi-structured events produced by the environment. The design of tool calls and event injection becomes especially important.

Put in too much, and it crowds the window and dilutes the model's attention; put in too little, and the model has to keep calling tools to read, adding execution steps. Wasting the context window means wasting the model's intelligence.

DeepSeek's approach is to manage the limited context window as a Cache. Borrowing terms from compiler optimization and computer systems, context injection boils down to two basic operations:

• Inline: put information likely to be needed soon directly into the current context window, saving a tool-call round trip.
• Spill: complete information that exceeds the window budget or is rarely used stays outside the window; only a reference or summary stays inside, and the model reads it itself when needed.

Combined with the classic principle of Locality from systems design, event injection and tool calls can be optimized step by step:

1. Start with the least information: at first only give the current object's ID and a content summary.
2. Inline related information gradually by locality: first attach the IDs of closely related objects, then content that is adjacent in time or position. For example, the first 50 characters of a piece of content, the few group chat messages before and after it plus the one it replies to, or neighboring comments in the review discussion a code comment belongs to.
3. Spill beyond the limit: set a fairly small length limit for long content and put the excess outside the window. The simplest direct approach is to truncate while leaving a "continue reading" entry, so the model calls a tool to read the full text when it needs it.

Near things go in the window, far things stay outside:

The window as a cache: Inline what's near, Spill what's far.

These rules also solve a long-standing headache for the Router.

Once many follow-up events go straight to Workers and the system has run long enough to accumulate many past tasks, the Router cannot possibly keep the full history of every task in its own window; yet when a user suddenly brings up an old task in another channel, it has to recover the context.

Applying Inline & Spill consistently to every kind of object in the system yields an on-demand, multi-hop retrieval that DeepSeek calls Chain of Recall.

It works like this: the system gives Triggers, Threads, Worker Sessions and other objects unique IDs, and inlines the IDs of closely related objects on injection, so the objects form a reference graph underneath.

Every object recalled by a tool call also follows Inline & Spill, so the result again inlines the summary and ID of the next hop. Starting from the event in front of it, the model can follow references hop by hop and fetch context on demand.

A task from long ago gets recovered exactly this way.

Follow the IDs back, one hop at a time:

Forgot? No problem — follow the IDs.

For example, from the current message read the Thread it belongs to, from the IDs inlined in that Thread find the related Worker Session, and from that Worker find another code review Thread it is linked to. The Router "forgetting earlier things" over long runs is eased a lot by this chain.

4. Acting ahead of time

This one borrows Speculative Execution from computer systems: before it is certain whether the result will be used, the agent tries the work in the background based on signals in the environment.

Spend a bit more background compute in exchange for people waiting less and stepping in less. If the result is valuable it is delivered; if not, it is thrown away.

In a personal assistant, when a meeting invitation or a to-do arrives, the agent can check the calendar for conflicts in the background, gather relevant background and prepare a draft reply; you take a quick look and can send it once you confirm.

The same goes for engineering collaboration. In the company's internal DeepSeek Harness user group, DeepSeek set up a "silently reproduce and fix" policy: when someone in the group reports a problem or is discussing a proposed change, the agent first tries to reproduce it and find a fix in the background; only when the problem is confirmed and a simple fix is found does it hand the result to users, otherwise it stays quiet throughout.

The group is still talking, and the fix is already ready:

Work on it first, deliver once confirmed.

How to talk to people

The two-layer architecture guarantees continuity across channels at the context level. But in the actual experience of human-agent interaction, being continuous and efficient at the same time also requires solving one problem in the interaction mode and one in the interaction channels.

1. Full duplex

In a classic ReAct Loop, once the model makes a synchronous run() tool call, the loop is stuck until the tool finishes and returns its final result. During that time the session cannot take any new messages.

To remove this blocking, the conversation has to change from question-and-answer half duplex to full duplex. After the change, you can keep talking while waiting for tools.

Half duplex blocks the conversation; full duplex splits foreground from background:

The background keeps running, the foreground can still reply.

Concretely, long-running commands and subtask tool calls are changed into asynchronous start() and stop(), forming an asynchronous ReAct Loop:

• After the model calls start(), it immediately gets a "Started" return and the loop moves on.
• When the background tool finishes, the system delivers the final result into the session as a new event message.
• Based on context, the model can also call stop() to terminate a background command that has been running too long.

Foreground conversation and background tasks are thus decoupled: while the agent runs long tasks in the background, it can still reply to people. New messages are handled as soon as the current reasoning step ends.

This asynchronous task mechanism is already implemented in DeepSeek Harness, just not enabled by default yet.

2. Multiple channels

Different work channels have different information density and interaction habits, and the system's output has to match them.

If you move an interaction style designed for a single-user terminal into a group chat as is, dumping long reasoning and dense tool calls into it, a multi-person group quickly drowns in information.

The two-layer architecture already solves part of this: the long reasoning and dense tool calls of concrete tasks are kept inside Workers, and the Router speaks for everyone.

On top of that, the system needs to plug into the various work environments users use every day, and use prompts to customize interaction norms for each channel:

• Instant messaging channels like group chats: minimal interruption, lightweight communication. Like a human colleague, it only notifies you when it needs your decision or acceptance, only asks direct questions, and only gives short conclusions. DeepSeek validated a simple, effective hard rule: no more than 100 words per reply.
• Asynchronous channels like GitHub, email and documents: structured, information-dense asynchronous delivery. For example, when creating or updating a pull request, write up the background, the change and the verification results according to project conventions; in personal assistant scenarios, draft structured emails and document summaries directly.

How the same result is reported in the group versus in the PR:

Short in IM, complete in asynchronous channels.

Always online

Today's local agents by default bind three things to the same device:

1. The compute that drives the Agent Loop
2. The session state that needs to be persisted
3. The execution environment: code repos, local toolchains

Once the device sleeps, all three stop together:

Bound to one machine: when it sleeps, everything stops.

Once the device sleeps or goes offline, the agent stops; it also cannot reach environments on other devices.

To keep Super-agent always online while flexibly plugging into all kinds of real work environments, DeepSeek borrowed the idea of Compute-Storage Separation from computer systems and unbundled these three things in two steps.

Step one: separate compute from state. The compute that drives the Agent Loop can be made stateless; what really needs to be persisted is the session state.

So compute goes into stateless, elastic compute containers in the cloud, and persistent state such as Sessions is stored in a database. Containers can scale horizontally and be restarted or replaced at any time, while the continuity of sessions and tasks is backed by persistent storage. The agent escapes the lifecycle of any single local device and stays online in the cloud.

If the machine running the agent breaks, swap in another and keep going.

When a container dies, start another and pick the state back up from the database:

Compute is replaceable; state lives in the database.

Step two: separate compute from the execution environment.

With the Agent Loop and session state both resident in the cloud, the next question is: how does it reach the execution environment a task needs?

Much of the context a model needs for its work has to be fetched through tool calls from execution environments such as code repos, local files and dependent services. In that sense, context in the broad sense includes the execution environment itself.

There are two common approaches:

• Spin up a sandbox in the cloud, pull the code, and try to rebuild and sync the environment. But real work environments often have uncommitted local changes, private credentials, intranet service dependencies, and specific hardware or toolchains; syncing such an environment is expensive and easy to get wrong.
• Have users give up their local environment and move their work to the cloud. For many people, the migration cost is too high.

Since what is hard to copy and hard to sync is the environment itself, let the execution environment stay where it is.

The Agent Loop runs in the cloud, and only a lightweight daemon is deployed on the device (all session state is in the cloud): it only executes commands and returns results. The execution environment stays outside the cloud, and the agent reads the context inside it on demand.

The agent lives in the cloud and reaches the environment on your computer through a lightweight daemon:

Brain in the cloud, hands on the device.

This idea matches Anthropic's "Decoupling the brain from the hands": likewise keep the harness stateless, store session logs outside the harness, and connect to execution environments on demand through a unified interface.

The difference is the scenario. Anthropic's piece is about a managed service and mainly discusses on-demand sandboxes and resources in customer VPCs; what DeepSeek needs to connect first here are the personal computers users use every day, which may be online one moment and offline the next, with uncommitted changes and local credentials on them.

So this design supports BYOM (Bring Your Own Machine — connecting the dev machine or personal computer you use every day to the cloud agent), as well as cloud-hosted machines and on-demand compute environments.

One agent can switch between different execution devices, picking an environment per task to run commands and fetch context.

It can even take care of devices that come and go: when one of your personal computers comes back online, the cloud agent is triggered automatically and finishes the tasks that need to be done on that device.

A computer that is sometimes offline gets its work as soon as it comes online:

As soon as the device wakes, the work resumes.

When something breaks, who steps in

To stay always online, besides compute-storage separation the system also has to recover from anomalies by itself over long runs.

A long-lived distributed system can hardly guarantee long-term reliability through logic inside the main system alone; it needs an independent external control loop (Control Loop) outside the main system.

And for agent systems, many anomalies come from the model: the process is alive and well, yet the model has fallen into an unproductive loop or drifted from its goal, and liveness probes and monitoring scripts see nothing wrong. So a long-running agent system has to watch both whether the infrastructure is alive and whether the task itself is making progress.

DeepSeek's approach is to set up an independent Watchdog Session outside the main system, driven by scheduled messages, forming an external Control Loop.

What it has to catch are exactly the Workers that drift or spin in place:

A live machine is not enough; the task has to make real progress.

The Watchdog handles infrastructure failures such as API errors and failed state recovery on one hand, and on the other uses the model to judge whether each Worker is making real progress and whether its direction has drifted from the overall goal. When it finds an anomaly it steps in to fix it promptly; when it meets an occasional external failure, it keeps rechecking until things return to normal.

The Watchdog is itself an Agent Session with a full set of tools, so maintainers can ask it in natural language what caused a failure, or have it change the main system's behavior online, such as adding or removing prompts or adjusting trigger rules.

Experiments: is it really faster?

To evaluate the core scheduling and routing design, DeepSeek ran two sets of preliminary experiments: one end to end, comparing the two-layer architecture, subscription bypass and single-Session approaches; and one testing Router-layer batching on its own.

The experiments use synthetic load and a simplified environment, some settings could be more rigorous, and the results are only a preliminary reference.

1. Ablation

The experiment drives four end-to-end approaches at once with two message streams, group chat and GitHub CI. Each run has about 300 messages, of which about 20 are work requests; the rest are chit-chat, follow-ups, stop requests and CI messages.

The coding work is replaced by a tool that only consumes time. So this experiment measures the system's scheduling and collaboration ability. Each approach is repeated 5 times.

The four contenders:

1. Super-agent
2. Super-agent without bypass
3. Single Session + Subagent tool, neutral prompt: "Use a subagent for a piece of work when appropriate..."
4. Single Session + Subagent tool, prompt favoring delegation: "Every message of the chat reaches you, so work you run yourself keeps stopping for new messages. Prefer handing each piece of work to a subagent of its own, and do only small things yourself..."

Who finishes the 20 jobs first —

Take a look:

P50 12.4 minutes; the two-layer setup is steadier.

(The chart shows each setup's P50–P95 completion-time range from 5 runs; message intervals and work durations are scaled by 1/4, while model call latencies are real. Task completion time means from when a work request is sent until the result message comes back.)

Look at completion time first. Super-agent's P50 is 12.4 minutes and its P95 is 15.7 minutes, clearly better than the single Session with a Subagent tool.

On the single-Session side, results are swayed heavily by the prompt, and the main session often decides to do the work itself:

• With the neutral prompt, the model did not call a Subagent even once in 5 runs; all work was done in the main Session, which kept getting interrupted by new messages, and P95 reached 29.5 minutes.
• With the delegation prompt, it delegated in 4 of 5 runs and completion time got somewhat shorter, but overall it was still slower than Super-agent; in the remaining run it judged the work "small" and did it itself — that is the purple long-tail range in the chart.

In a single Session, whether work gets divided depends on the prompt and the model's judgment in the moment; the two-layer architecture fixes the division of labor at the system level: the Router never touches concrete work, and Workers only receive the Threads they subscribe to.

Now the cost. Super-agent maintains several independent sessions, so its cache-read tokens per run are higher than the single Session — it trades more tokens for shorter, steadier completion times.

As for the bypass mechanism, removing it inside Super-agent leaves task completion time basically the same as the full version, but the Router has to make about 30% more decisions, and total cache-read tokens rise from 23.23M to 31.77M, about 37% more.

How much the Router-side bill differs between the full version and the no-bypass version:

Bypass saves the Router-side bill.

Under this experimental load, what the bypass does is save the Router Session a considerable amount of tokens and inference overhead. Completion is not necessarily faster, but the bill and the noise get easier to live with.

2. Router batching

To verify the earlier claim that "one resident Router can cope," DeepSeek stress-tested the Router layer on its own: the Router calls a real model, Workers use a mock model, and the arrival rate of Triggers needing a decision is raised from about 1 per minute all the way to about 40 per minute, measuring how many are in a batch on average, how long a single request takes, and how much inference time each decision costs.

As the arrival rate goes up, how much time each decision costs:

Peaks are handled by merging, and effective throughput goes up.

As the arrival rate rises from about 1 to about 40 per minute, the average batch grows from 1.0 to 2.8 Triggers, while the time of a single request only rises from 2.5 to 3.9 seconds — more slowly than the batch size. The inference time per decision falls from 6.4 seconds to 1.6 seconds.

In other words, when external events suddenly bunch up, the Router can raise its effective throughput by automatically merging the backlog.

This also explains something in the ablation: after removing the bypass, the Router's peak load got bigger, and a single Router could still cope. So at their current team size one Router is enough, and global context stays continuous.

Problems not solved yet

That this system can run with fairly low complexity is largely thanks to a series of engineering and scenario simplifications made at this stage. Outside the range where those simplifications hold, four kinds of problems remain.

1. How the two-layer architecture scales

The combination so far — one resident Router Session, plus subscription bypass, plus Workers each doing their own thing — covers the vast majority of their current daily tasks at very small engineering cost.

But when tasks grow larger and more tightly coupled, beyond what one Router Session can carry, there is no settled answer on how to build each layer internally: when the Router should be split horizontally and at what granularity, when Workers in the same layer need to talk directly and with what collaboration topology — all of this still needs testing in more scenarios.

Here is the hard part of whether to split the Router:

The finer the split, the more fragmented the memory.

System-model Co-design is also worth exploring: training models specifically for the Router's tasks — event discrimination, batch dispatch, context recall — might push the Router's throughput and decision quality up another notch.

Then there is memory. A resident Router with reference-graph-based chain of recall mainly solves on-demand retrieval of recent tasks and session history. Once the running period stretches across months or longer, long-term memory becomes the main bottleneck to scaling.

2. Without Sessions, how do people work with the agent?

The two-layer architecture hides the underlying multi-session management, and Sessions retreat behind the scenes of product design. Once execution sessions underneath are separated from sessions in the interface, how to present tasks to users and offer natural interaction and project management becomes a new problem.

DeepSeek's judgment is that chat-window-centered interaction is to some extent the result of path dependence. Interaction can happen more in domain-specific interfaces — for example, as with the instance in this essay, letting Super-agent work directly in GitHub Issues and Pull Requests.

Sessions can also stay in the interface to respect user habits; it is just that one conversation you see does not necessarily map to only one Session underneath.

Also, what was discussed so far is mainly interaction at the two ends: "starting a task" and "accepting the result." But in this transition period of rapidly evolving model capability, many tasks still need people to participate midway: stepping in or taking over at any point during background execution, or collaborating with the agent in real time. How to serve, in one product, both the need to intervene step by step on key details and the efficiency of autonomous background progress is also worth exploring.

The project management and interaction style users want depends closely on their field of work and personal style; the final form will very likely be highly customized. The DeepSeek Harness architecture is open, which makes such customization easier to support.

3. Context boundaries and A2A

Everything discussed so far is the internal design of a single Super-agent instance, assuming all information within its service scope flows into the same global context.

But once usage expands from individuals and small teams to larger organizations, deciding how to deploy Super-agents is in effect drawing the boundaries of context sharing and isolation: scopes that need shared context share one instance, and scopes that need isolation each get their own.

Between instances, collaboration works like this:

Share one where context is shared; give each its own where it is isolated.

One step further: once there are several mutually isolated instances inside and across organizations — say, each member's personal assistant and the team's shared Super-agent — their collaboration across boundaries is agent-to-agent communication (A2A, not referring to any specific protocol here).

With underlying contexts kept apart and each representing a different permission boundary, how to achieve safe and reliable A2A communication and collaboration still needs exploring.

4. Security and privacy

Event-driven design lets the agent be driven by a wider environment, and also exposes it to more untrusted input. If security and privacy are not handled well, Super-agent can only work in a small, highly trusted scope.

For example, the earlier design of putting the Agent Loop in the cloud and installing lightweight daemons on each execution device assumes by default that cloud and device trust each other.

But the cloud Agent Loop is constantly taking in external environment events, while the devices hold private code, sensitive data and local credentials. This cross-device connection brings clear security and privacy risks: once the cloud Agent Loop is compromised through a server intrusion or prompt injection, every connected device is at risk of being controlled.

Once the cloud falls, where the risk spreads:

Default trust will not hold up in broader settings.

Even if the cloud is not compromised, as long as device credentials can enter the model's context, there is a risk of leakage during normal execution. So mechanisms are needed that let the agent use credentials without ever touching the credentials themselves.

For this architecture to reach wider use, these security and privacy problems have to be solved while still being able to recall context from all kinds of environments.

Finally

Looking back at the whole design, what DeepSeek did was apply classic engineering ideas from computer systems to building agent systems. Specific implementations will change as technology develops; the system design thinking behind them has more lasting reference value.

Right now, the internal Super-agent instance they built on these ideas and DeepSeek Harness keeps running, taking part daily in reproducing and fixing issues, responding to code reviews, and even in iterating DeepSeek Harness itself.

As large models need less and less human intervention for single tasks, the bottleneck to further productivity shifts to human attention. The two-layer architecture, event-driven design, asynchronous multi-channel interaction, compute-storage separation and an external Watchdog push tedious session management and context synchronization down into the system, letting people move one more step up from execution details to decisions and acceptance.

At that point, the agent turns from a chat window waiting for instructions into a collaborator that is always online in the digital environment and moves things forward on its own: for individuals, an assistant that handles daily affairs across devices; for teams, something that grows inside the engineering workflow, taking on work and pushing it forward.

Some of the designs in the essay are already implemented in a plugin called dsh-superagent-prototype. It is a prototype built to validate the technical approach.