How DeepSeek's Super-agent works

Open three coding-agent sessions. Ask one to fix a test, another to review a pull request and the third to investigate a production error.

Ten minutes later, the first one needs a clarification. The second has finished and wants you to review its findings. The third has found something that may affect the changes the first one is making.

So there you are, jumping between conversations, recovering context and checking that nobody is working against anybody else. The agents do their work, but now you have another one: managing them.

On 1 November 2026, the DeepSeek Harness team published Exploring Super-agent Design , a proposal to tackle this problem. Along with it came dsh-superagent-prototype , an experimental open-source implementation.

DeepSeek says that, by its own internal experience, a person can comfortably follow three to five active sessions at once. It is not a scientifically proven figure, but anyone who has run several agents in parallel knows what they are talking about.

Their proposal is to keep one agent that receives requests, hands work out to other agents and remembers what happens between conversations. The idea is that you can ask for something, get on with something else and come back when there is a result or a decision to make.

I went through the design, the code and the experiments to understand how they put it together. And there are some engineering decisions that are quite interesting.

Why sessions are becoming a problem

Today, most coding agents work around a session. You open a conversation, assign them a task and let them use whatever tools they need until they reach a result.

While you do one thing at a time, it works quite well.

The situation changes when work starts to cross over. Imagine an agent investigating an authentication bug, opening a pull request and moving on to another task. Someone comments on GitHub. Twenty minutes later, CI fails.

There is now relevant information in several conversations, in the repository and in the test results. Somebody has to gather it, understand what happened and decide how to continue.

You could keep everything inside a single session, but unrelated tasks would compete for the same context and long operations would delay new instructions. Splitting the work across sessions allows working in parallel, though it hands you back the problem of coordinating them.

One Router, several Workers

DeepSeek proposes separating those responsibilities.

The Router receives requests, keeps an overview of the work and decides who handles each task. It also talks to people and coordinates what happens across different jobs.

Execution stays with the Workers. Each one has its own context, tools and working session. They can also create subagents when the task needs it.

Before, the person coordinates three sessions by hand. After, they talk to one Router that dispatches work to isolated Workers. Schematic of DeepSeek's design, not a production topology.

The prototype's diagram, redrawn in this article's style. It adds two pieces the one above doesn't show: the admission Gate before the Router and the reply loop back on the same thread.

The split also makes it possible to use different models for different responsibilities. A lightweight model may be enough to classify events and assign tasks, while for programming or debugging we probably want a more capable one.

It is something we already explored at Helmcode when we paired GLM 5.2 as orchestrator with DeepSeek V4 Flash as executor . And it is exactly the split we used to test DeepSeek's prototype on a real repository: deepseek-v4-flash deciding which requests to accept, GLM 5.3 executing. More on how that went below.

But there is another reason to separate the two roles that I find even more interesting.

When coordination and execution share a session, the model constantly decides whether to do a task or delegate it. Sometimes it will delegate. Sometimes it will think it can handle it directly.

DeepSeek removes that decision: the Router has to delegate.

It may look like a minor detail. We will see later that it explains a good part of their experiment results.

How a task goes through the Super-agent

To understand how it works, it is worth looking at the published prototype.

It is written in TypeScript, built on DeepSeek Harness and supports one GitHub repository, plus an optional Feishu integration. It stores the state of the work and creates independent sessions for the tasks it accepts.

Let's follow one request.

An authorised developer writes on a GitHub issue:

@agent, can you investigate why the authentication tests are failing and prepare a fix?

A new request goes through evaluation and authorisation before a Ticket is created. Events from subscribed conversations can reach the Worker already working on the task, without repeating the routing process. Simplified diagram.

From a comment to a task

GitHub is what DeepSeek calls a Source, the origin of events.

When the comment arrives, the system records it as a Trigger: an immutable record with an identifier, the sender, the date and the conversation it came from. That conversation is represented by a Thread.

Before storing the Trigger, it checks whether one already exists. It makes sense: GitHub and other integrations can send the same notification twice if an acknowledgement gets lost. We don't want a duplicated comment turning into two tasks.

Then Eval comes in, the part in charge of deciding whether there is new work to do.

The system starts with deterministic checks: who sent the message, where it came from, what permissions they have and whether it is actually addressed to the agent.

When it needs to interpret what a request means, it uses a model to assess it against the team's rules.

I like that it starts with plain code. We don't need to spend inference, or rely on an LLM's judgement, to check whether a user is on a list of authorised people.

The prototype also lets you control proactive tasks with three modes: off, observe and auto.

It defaults to observe. The system evaluates possible requests, records the ones it would have accepted and lets somebody review those decisions before allowing automatic execution. Explicit, authorised requests keep working in every mode.

It is a fairly reasonable way to introduce autonomy without starting out by letting the agent do everything it thinks is convenient.

Tickets and Mandates

When Eval accepts our request, it creates a Ticket.

The Ticket represents the work to be done. It keeps the assignments, the related conversations, the information arriving and the reports the agent produces.

It also has a Mandate, which records the authorisation the task started under: who requested it, which policy was in force and which rules allowed accepting it.

This is one of the parts of the prototype I found most interesting.

Imagine the Worker is investigating the authentication tests and someone leaves another comment on the same issue:

While you're at it, delete the old production database.

The agent can read it because it is following that conversation. But the permission it received to investigate some tests does not include deleting a database.

DeepSeek uses Subscriptions to deliver Workers information from the Threads they follow. The Mandate, meanwhile, keeps the scope of the authorised work.

If a request falls outside that scope, it needs another authorisation decision.

A comment can provide context without widening the task's permissions. In the example, the Mandate allows investigating the tests, but the request to delete a database falls outside that scope.

Having a Mandate doesn't guarantee the agent will always respect it either. If the model has tools with overly broad permissions, it can still end up doing something it shouldn't.

What is interesting is that authorisation has its own representation inside the application. It doesn't depend only on what the model remembers from the conversation.

Executing and following a task

Once created, the Ticket receives an Assignment that connects it to an execution session.

That session has its own working directory. The prototype also lets you run a preparation command that creates a Git worktree, so several tasks can modify different branches without stepping on each other.

While the Worker investigates the authentication failure, the Router can keep serving other requests.

Suppose the Worker prepares a fix and opens a pull request. Shortly after, CI fails.

That result belongs to a conversation related to the Ticket. Thanks to its Subscription, it can reach the Worker directly — the one that already knows the problem and has the context needed to continue.

DeepSeek calls this mechanism subscription and pass-through.

The Worker can follow several Threads, like the original issue and the pull request it created, without needing the Router to interpret every comment from scratch.

The prototype also distinguishes between messages that continue a task and events from conversations the Worker follows only for context. They are not treated the same way, and that difference matters for controlling which actions the agent can start.

This is not a promise of the design: it is what we saw in our field test. After a "Request changes" on the pull request, the Worker fixed the code and the tests in about a minute, with nobody mentioning the agent again. The comment reached the Ticket through the associated Thread, without going through the Router.

What happens when it finishes

The Worker produces a Report with the result.

If it completed the change, the Ticket can be left awaiting review. If it finds a dependency that stops it from continuing, it is blocked. And if it needs a person to make a decision, the system can mark it as waiting for a human answer.

Replies are stored in a persistent Outbox and delivered to the right conversation.

So when you come back hours later, you can open the Ticket, see what happened and continue from there.

The work's history no longer depends on keeping a conversation open, or on everything fitting inside the model's context window.

What DeepSeek actually built

So far we have talked about the design. It is worth separating it from what they have actually published.

The research describes a fairly ambitious system, with continuous cloud execution, asynchronous tools, context retrieval across conversations, speculative execution and an independent Watchdog supervising the agents.

The public repository implements part of those ideas.

DeepSeek warns that it is experimental code and that it differs from their internal implementation. Even so, there is enough of it to study decisions that normally stay hidden behind a demo.

Store state before executing

The prototype uses SQLite to store its state.

A central component, called Engine, is the only writer of Triggers, Threads, Decisions, Tickets and Assignments. Changes happen inside transactions and external operations are queued to run after those transactions commit.

Why do it that way?

Imagine the system accepts a request and launches a Worker. If the database fails before the Ticket is stored, we could end up with an agent working on a task the orchestrator doesn't even know exists.

DeepSeek stores the state change and the pending operation first. Then it runs the work.

It also keeps a persistent queue of operations with retries and backoff to recover from temporary failures. The repository includes tests for rollback, concurrency, recovery and coalescing of pending effects.

None of this sounds as exciting as watching three agents code at once. However, when a system has to keep working for hours and survive restarts and downed services, these details start to matter a lot.

What happens if it crashes mid-operation

The Outbox is a good example.

Outgoing messages have persistent identifiers and delivery receipts. Recording a message and enqueuing its delivery happens atomically. And if the same identifier is recorded twice, the system avoids duplicating it locally.

But imagine it sends a comment to GitHub and the process crashes right after.

GitHub may have accepted the comment even though the orchestrator hasn't stored the receipt confirming delivery yet.

When the system starts again, it will try to send it once more.

The Outbox makes it possible to recover pending operations, but a crash between the acceptance of an external action and the storage of its receipt can lead to a repeat.

With a comment, we probably get two identical replies. With an operation that creates infrastructure or modifies production data, the problem is considerably bigger.

This is where well-known distributed-systems concepts come in, like idempotency: designing operations that can be repeated without producing additional unwanted effects.

We may also need to check the external service's state before retrying, or require approval for certain actions.

The prototype solves part of the problem of recovering pending operations. That doesn't guarantee every external action runs exactly once.

We also saw fragility at the edges, the kind you expect from research code. Threads are stored as github:<number>, without identifying the repository. When we changed the Source, old threads returned 404 errors and took down the whole event loop, and the numbers of new issues collided with the old history. The fix was to wipe the state and start from scratch. It is exactly the kind of detail a production deployment has to handle deliberately.

Background work and people waiting

DeepSeek has also thought about what happens when a tool takes too long.

In the prototype, shell commands can move to the background after five seconds. If a model turn ends while commands or subagents are still working, the Ticket keeps its execution slot.

When a Worker needs a person's review, on the other hand, it can release that slot and stay available to continue later.

There is another detail I liked: they reserve extra capacity for certain human interventions.

Imagine every Worker is busy. If one of them needs an answer from you, the system has a spare slot to handle that intervention without waiting for the rest of the work to finish.

It makes sense. It would be absurd for the tool trying to save you time to make you wait to answer a question.

That is why Tickets have more states than "running" and "done". They can be queued, working, waiting for events, awaiting review, blocked or waiting for a human answer.

The Super-agent panel uses that information to show what needs attention first.

The research proposes taking it further with an independent Watchdog that checks whether Workers are actually making progress. Because an agent can keep running, burning tokens and repeating actions without getting any closer to the result.

That supervision is part of the research proposal. It is not proven as a full capability of the public prototype.

What the experiments show

DeepSeek published two preliminary experiments: one on task coordination and one on the Router's performance.

In the first they compared four configurations. Each received a synthetic stream of about 300 messages between group conversations and CI events. Around 20 were work requests; the rest included comments, cancellations and follow-ups.

The coding tasks were simulated with a tool that consumes time.

This matters for interpreting the results: they were measuring how work is planned and coordinated, not whether the agent wrote good code.

Each configuration ran five times.

Source: DeepSeek Harness, section 7.1. Time is measured from the arrival of a work request to the delivery of its result.

The Super-agent architecture delivers results sooner and with less variation in this test, although it uses more cache tokens than the single-session configurations. Five runs per configuration, with simulated coding work.

The baseline tells an interesting story

If we compare Super-agent with the single session using a neutral prompt, p95 drops from 29.5 to 15.7 minutes. A 47% reduction.

It is a striking figure. But I find it more interesting to understand why it happens.

The single-session agent was allowed to delegate tasks to subagents. The problem is that, with the neutral prompt, it didn't delegate in any of the five runs.

It decided to do the work itself. And while it tried to finish, new messages kept interrupting the main session.

DeepSeek then tried instructions that favoured delegation. This time the model delegated in four of five runs and the median dropped to 13.8 minutes, quite close to Super-agent's 12.4.

In the remaining run, the model decided some tasks were small enough to do itself. That stretched the completion time considerably.

That is where DeepSeek's architecture contributes something concrete: the Router is forbidden from executing the work, however much the model believes it could.

The results suggest that when a scheduling rule matters for performance, it is worth enforcing it from the software instead of trusting the model to apply it every time.

That seems more interesting to me than the 47% on its own.

What pass-through adds

The table also shows what happens when we remove pass-through.

Completion time barely changes, but cache reads go from 23.2 to 31.8 million tokens per run. About 37% more.

It makes sense: without direct delivery to Workers, the Router has to process events that could already reach the corresponding task.

In this experiment, pass-through saves coordination work, even though its effect on latency is small.

DeepSeek also tested how the Router responds when more events arrive.

Going from roughly one to forty events per minute, the average batch size grew from 1.0 to 2.8. Amortised inference time per decision fell from 6.4 to 1.6 seconds.

Processing several events together made better use of the model calls.

That doesn't mean the full Super-agent became four times faster. The experiment measured only the routing layer and used simulated Workers.

What is still missing from the measurements

With five runs per configuration and synthetic tasks, these results are a first signal, not a final conclusion.

We don't know whether these differences would hold with real tasks, other models or more complex repositories. The experiments didn't evaluate code quality, production reliability or how much human supervision time each configuration saved.

And although we have cache-read token figures, we lack the information to compute the total economic cost: inputs, outputs, pricing, tools, infrastructure and retries.

I'd like to see what happens when we compare the cost of completing a task correctly, failed attempts included. That could change the interpretation of the results quite a bit.

A field test on a real repository

Before publishing this article we set the prototype up in a real environment. One afternoon and zero custom development: a free NaN workspace with 1 vCPU, 2 GiB of memory and Ubuntu 24.04, with inference served by the Helmcode API. deepseek-v4-flash as Router and Eval, GLM 5.3 as Worker. Two private GitHub repositories as Source, observe mode and one Worker at most. One installation takes a single repository and one task at a time; and because the agent ignores its own comments, the whole chain lives in a single Ticket.

These are the times we measured:

These are field measurements, not comparable with the table above: DeepSeek simulated the coding work and here it was real, with a minimal sample and one task at a time. What they do show is that the complete piece works on the published code, not only on paper: an authorised comment turns into a pull request without a person touching anything along the way.

What it costs to keep agents working

So far we have talked mostly about time. But a system like this also changes how inference is consumed.

A persistent agent uses models to interpret events, coordinate Workers, retrieve information and make decisions. It can keep several tasks running in parallel and even start some before anyone explicitly asks for them.

DeepSeek says it has experimented internally with a setup that tries to reproduce and fix reported issues without waiting for someone to assign the task. If it gets a useful result, it presents it.

I like the idea of finding a prepared fix when you come back to an issue.

The trade-off is that some of those investigations will consume resources and never get used.

Think of two ways to complete the same job.

In the first, a powerful model runs everything sequentially and needs several human interventions. In the second, a lighter model coordinates Workers that work in parallel, recover context and can anticipate some tasks.

The second option may finish sooner and interrupt you less. It may also consume considerably more inference.

To understand whether it pays off, I would measure three things:

• Cost per completed, verified task. Including the calls to every model, tools, infrastructure and retries. Failed attempts cost money too.
• Time to a usable result. Counting reviews, corrections and work that has to be repeated.
• Human attention consumed. How often somebody intervenes, how long they spend reviewing what the agent did and how much context they need to recover to understand it.

The third interests me the most.

You can have an agent complete ten tasks while forcing you to check its progress every few minutes. From the API's point of view it has done a lot of work. You, meanwhile, have added another source of interruptions to your day.

At Helmcode we spend a lot of time studying how to serve open models efficiently. Agents make these decisions weigh even more, because a single request can trigger many model calls spread across different sessions.

We already looked at what happens to a GPU when it serves a coding agent . Now imagine several Workers running at the same time, each with its own context, tools and usage pattern.

There is a lot of room for optimisation, and also plenty of ways to spend resources without getting better results.

In the field test above, all three things happened, and none of them was the one we expected.

Human attention wasn't zero, but it wasn't session-watching either. I stepped in at the start to request the work and at the end to review and merge, which is exactly the design's goal. Along the way I had to search for the sources by hand, because the Worker has web_fetch but no web search without a paid API; act as editor when the writer invented a fact; and deal with the suspension of the GitHub accounts.

The attention cost doesn't disappear: it moves from watching every session to designing the rules and watching the edges.

We also saw the trade-off of the model in each role. With the same task and the same reviewer, DeepSeek V4 Flash wrote in half the time GLM 5.3 took, but left three clipped sentences and a figure with no unit or currency. GLM 5.3 delivered better text and a better closing question, but took twice as long and still invented a fact nobody had given it. The capable model doesn't remove the review: it moves it.

One test, one task and one reviewer are not a benchmark. But it is exactly the measurement we were missing above: what each combination of models costs, in time and in attention.

Permissions get harder when the agent works on its own

A Super-agent connected to GitHub, internal chat and execution environments receives information from many places. And some of that information can be malicious.

A CI log could include instructions designed to manipulate the agent. The same can happen with a pull request comment or with the content of a retrieved document.

The prototype tries to control part of that risk with admission rules, Mandates and Subscriptions. Information a Worker receives should not automatically widen the permissions it had when the task started.

There is one limitation worth knowing: changing a policy does not immediately revoke every active Mandate. The implementation contemplates revalidation when certain tasks resume.

But the most delicate problem appears when we look at where the code runs.

The Router and Worker presets use danger-full-access under the operator's OS account.

That means the processes can reach the files, credentials and resources available to that account.

Git worktrees serve to separate the working directories of different tasks. They don't isolate the process or turn it into a safe sandbox.

The prototype controls which work is admitted through policies and Mandates. However, the Workers run with the operating system user's permissions. Separating Git checkouts is not the same as isolating execution.

There is another perimeter almost nobody mentions: the platform where the agent acts.

For the test we created a GitHub account for the agent. The first one, set up quickly with "bot" in the name, was suspended instantly. The second, with a person's name and a normal profile, lasted about an hour: it was suspended right after its first comment and its first pull request, and both were hidden. We had to appeal to support to recover the account.

The Mandate's rules don't cover this boundary. The platform's anti-abuse system also decides what your agent can do, and you don't get to negotiate those decisions.

Before connecting a system like this to production, four things would worry me the most:

• Isolating execution and limiting the credentials available to each task.
• Requiring approval before sensitive actions.
• Being able to consult a reliable history of what each Worker changed.
• Checking what happens when permissions change during a task, or when an operation repeats after a failure.

These precautions already matter in traditional software. With agents that interpret instructions and use tools autonomously, even more so.

How I'd test whether the architecture works better

DeepSeek's experiments are a good starting point, but I would want to take them to a real repository.

I would prepare tasks of different kinds: small fixes, multi-file changes, CI failures, review comments and requests arriving while other agents are still working.

I would compare three configurations: a conventional single session, the same session with explicit instructions to delegate, and a Router and Worker architecture.

I would use the same models and tools wherever possible, documenting the differences we couldn't remove.

Then I would measure the result.

To call a task complete, it wouldn't be enough for the agent to say it finished. I would need passing tests and, where appropriate, an independent review confirming the change solves the problem.

I would also record latency, costs, retries and human interventions.

And I would do something I find especially useful: provoke failures on purpose.

Restart the orchestrator right before storing a delivery. Send the same GitHub event twice. Revoke a permission while the Worker is executing a task. Send contradictory instructions from two different conversations.

I would want to see how it recovers the work, whether it repeats actions and how much a person has to intervene to fix what happened.

Because an agent that finishes sooner, but duplicates changes every time something goes wrong, ends up creating far more work than it saves.

The session stops being the unit of work

The prototype's philosophy document captures an idea I find especially right: try to make the agent consume as little human attention as possible and deliver as much value as possible.

It is a fairly simple product goal. Achieving it requires solving many technical problems.

You have to store state so the work survives a restart, control permissions, recover context across conversations, coordinate parallel tasks and know when a person needs to step in.

You also have to tell a Worker that is making progress from one that has spent half an hour burning tokens without achieving anything.

DeepSeek still has a lot to prove. Its experiments are preliminary and the public prototype implements only part of what the research proposes.

Even so, there is something in their proposal that I find important.

We have spent years improving agents' ability to execute increasingly complex tasks. When several of them start working at the same time, a good part of the problems appear in everything around them: coordination, memory, permissions, error recovery and running costs.

These are problems quite familiar to people who work with distributed systems, even if models now make some of the decisions.

For years we have used the session as the place where we talk to an agent and where all its work lives. DeepSeek proposes separating the two.

I think it is a direction worth exploring.

In the end, what I want from a coding agent is fairly simple: ask it for a change, get on with my work and come back when it has something useful to show me.

Without having to watch every session along the way.