The DeepSeek Harness team keeps an agent running all the time. In their internal DeepSeek Harness user group, someone mentions a problem in passing, nobody @-mentions the agent, and it goes off and tries to reproduce the issue in the background anyway. Only if it confirms the problem is real and finds a simple fix does it say anything, by opening a pull request on GitHub. If it can't reproduce it, or the fix isn't simple, it stays quiet, as if nothing happened.
On November 1 the team published a long article on X about the architecture behind agents like this, which they call a Super-agent. Two things to know first. The X version is a machine translation of a Chinese original. And the article says up front that it discusses architectural ideas, not features DeepSeek Harness has today. Part of the design lives in a prototype plugin called dsh-superagent-prototype, which the team describes as a way to validate the approach, not an official DeepSeek product. Everything below comes from the X version.
The bottleneck is people, not models
The starting point is simple. Over the past year, coding agents and other single-task agents have become good enough that they need less and less watching and step-by-step help. Things change once you want several tasks moving at the same time. Today's agents work one session at a time, and sessions don't share anything. Run five sessions for five jobs and you're the one switching between them and remembering what was said where. In the team's experience, one person can keep track of maybe 3 to 5 active sessions. A single task is limited by the model; many tasks are limited by human attention.
Bolting CLIs, MCP or other connectors onto a local agent lets it hear about the outside world, but the old problems remain. It blocks on anything slow and can't respond to anyone in the meantime. Context from different tasks gets mixed together and the results get worse. Close the laptop or lose the connection and everything stops. Keeping it running takes constant babysitting.
What they want instead is one agent that's always there and always the same one. Agree on plan A with it in a group chat, switch to plan B in a pull request comment later, and it follows along; you never have to wonder whether it knows. It works on several hard things at once and takes the next request before the last one is done. It notices what's happening around it, acts on what matters and stays quiet otherwise. It stays online for a long time and recovers on its own when something breaks. A single ReAct loop can't do all that, the article argues. The system around it has to.
One talks, the others work
The central move is to split the agent into two levels.
The top level, the Router, is one long-running session. Every human message from every channel lands there first. It keeps track of the big picture, hands out tasks and coordinates between them, but it never does the work itself; it doesn't even need a Bash tool. The level below is made of Workers: one isolated session per task, each with a full set of tools. Workers decide how good the result and the code are, so they usually get the strongest model. A Worker never talks to people directly. It reports to the Router, and the Router does all the talking. To the user it's one agent; behind it, many sessions run at once.
It looks like the familiar Agent Team, but the jobs differ. A team lead has to break one complex task into pieces and keep coordinating the members, which is hard thinking. The Router only hands out separate, independent tasks and remembers how they relate; it never breaks a task down. In practice, the team found, the Router's job is lighter than you'd expect, and a smaller model is often both quick and good enough.
The obvious worry is that a single Router session becomes a bottleneck. Their answer is that it batches for free. While the Router is thinking, new events wait in line, and the next turn takes them all in one call. Router calls tend to have long inputs and short outputs, and events merged into one call are processed in parallel during prefill, so the time per request grows much more slowly than the number of events. They load-tested this: as events needing a decision went from about 1 to about 40 per minute, the average batch grew from 1.0 to 2.8 events, time per request rose only from 2.5 s to 3.9 s, and inference time per decision actually fell from 6.4 s to 1.6 s. At their current team size one Router is plenty, and there's no reason to split it early and give up the shared context.
There's a line in the article worth thinking about if you build products: making users manage sessions by hand is largely a habit inherited from low-level LLM APIs. Sessions should be an implementation detail, not the user's problem.
Letting it see what needs doing
To make an agent proactive, you have to change what drives it. Instead of prompts typed in one at a time, it runs on things happening around it: group messages, emails, calendar reminders, code review comments, CI results. The article calls these Triggers.
Once you hook up real group chats and code platforms, most messages have nothing to do with the agent, and asking a large model about every one of them is slow and expensive. So they borrowed the fast-path, slow-path idea from computer systems. Code first filters on fixed things like the source, the group and allowlists, with each source set to "respond only to explicit requests", "treat as a candidate" or "ignore". That removes most of the noise. Only what's left goes to the model, which decides using rules written as prompts, and those rules can be added or switched off at any time.
Then there's routing. If every follow-up message had to go through the Router, it would eventually drown. So consecutive events on the same pull request, chat topic or email chain are treated as one Thread. Once the Router assigns a Worker to a Thread's first event, that Worker subscribes to the Thread, and code sends it every later message directly. When several Workers subscribe to the same Thread, they all see each new message at once, which gives them a chance to notice and sort out conflicts between themselves.
As for how much to put in the model's context, they treat the context window like a cache. Things likely to be needed soon go straight in; whatever's over budget stays outside, with a reference left behind to read later. In practice they start small, with just the current object's ID and a summary, then add nearby things, such as the first 50 characters of the content, the surrounding chat messages, or neighbouring comments in the same review, and cut off anything long with a pointer to the rest. Every object has a unique ID and references to others, so the model can follow them back one hop at a time. That's how the Router can recover the background when someone brings up an old task in a different channel.
The fix-it-without-being-asked behaviour at the top comes from another trick, speculative execution: start work in the background on a hunch, hand over the result if it turns out useful, throw it away if not. A little extra compute buys less waiting and fewer interruptions for people.
No blocking, no spamming
Two levels keep conversations connected across channels, but daily use has two more problems.
One is blocking. In a classic ReAct loop, the model calls a tool and waits for it to finish before doing anything else. They replaced slow commands and tool calls with asynchronous start() and stop(). Calling start() returns "Started" right away, and when the tool finishes in the background its result comes back to the session as a new event; if it runs too long, the model can call stop(). The conversation no longer waits on background work. The article notes that DeepSeek Harness already has this asynchronous task mechanism, but it isn't switched on by default.
The other is knowing how to talk. Detailed reasoning and tool logs are fine in a terminal you're watching alone; paste the same thing into a group chat and you've flooded it. The two-level design already keeps a Worker's chatter out of public channels. On top of that, each channel gets its own manners. In chat, bother people as little as possible: speak up only when someone needs to decide or sign off, ask direct questions, give short answers. One hard rule they've found works well is a cap of 100 words per reply. GitHub, email and documents are the opposite: be complete and dense, for example writing a pull request with the background, the change and the test results as the project expects.
Your laptop stays where it is
To keep the agent online and still let it reach real working environments, they split things twice. First, the compute that runs the agent loop is separated from the state that has to persist. The compute runs in cloud containers that can scale, restart or be replaced; sessions and other state live in a database. Closing your laptop no longer stops anything.
The second split is the more interesting one. Real working environments have uncommitted changes, private credentials, services only reachable on the intranet, particular hardware. Copying all that to the cloud is expensive and easy to get wrong, so they don't. Each machine runs a small daemon that keeps no session state and does nothing but run commands and send back results. The article calls this BYOM, Bring Your Own Machine; cloud-hosted machines and environments created on demand plug in the same way. The agent can work on whichever machine a task needs, even one that's only online some of the time: when your computer comes back, the cloud agent picks up and finishes the work that had to happen there.
The article points out that Anthropic's "Decoupling the brain from the hands" takes the same approach. The difference is the setting: that piece is about a managed service, while DeepSeek's first job is connecting the personal computers people use every day.
And a watchdog
A system that runs for a long time rarely stays reliable on its own logic alone; it needs something outside watching it. And agent failures often aren't crashes. The process is fine, but the model is going round in circles or wandered off the goal a while ago.
Their watchdog is a separate session that wakes up on a schedule and has the full set of tools. It deals with infrastructure trouble such as API errors and failed state recovery, and keeps rechecking temporary outside failures until they clear. It also uses the model to judge whether each Worker is really making progress or drifting from the overall goal. Maintainers can ask it in plain language why something failed, or have it adjust prompts and trigger rules while the system is running.
What the experiments show
The article reports two early experiments and says plainly that they used synthetic workloads and simplified environments, that parts of the setup could be more rigorous, and that the results are only indicative.
The first is an end-to-end comparison. Four designs ran side by side, each fed about 300 group chat and GitHub CI messages per run, of which about 20 were real work requests and the rest small talk, follow-ups, cancellations and CI notices. Coding was simulated by a tool that just takes time, so this compares scheduling and coordination, not how well any one task gets done. Each design ran 5 times.
Super-agent finished tasks in 12.4 minutes at the median and 15.7 minutes at p95. The comparison was a single session with a Subagent tool. With a neutral prompt, the model didn't call the Subagent once in 5 runs; it did everything in the main session, kept getting interrupted by new messages, and p95 stretched to 29.5 minutes. With a prompt telling it to delegate first, it handed work off in 4 of the 5 runs. That was faster, but still slower than Super-agent overall. In the remaining run the model decided the work was "small", did it itself, and produced the long tail. The article's point: whether a single session delegates depends on the prompt and the model's call in the moment, while the two-level design settles it at the system level.
It isn't free. Super-agent keeps several sessions going, so each run reads more cached tokens than the single-session designs; it trades tokens for shorter, steadier completion times. They also tried switching off the per-Thread pass-through described above. Completion times were about the same, but the Router made about 30% more decisions per run, and cache-read tokens went from 23.2M to 31.8M, about 37% more. Pass-through doesn't make tasks faster, but it saves the Router a lot of work.
The second experiment is the Router load test described earlier.
What they haven't worked out
The article ends with an honest list of open problems.
First, scaling. One Router, per-Thread pass-through and Workers that don't talk to each other cover most of their daily work. With bigger, more tangled tasks, nobody yet knows when to split the Router and how finely, or when Workers should talk directly and how. After months of running, long-term memory becomes the biggest bottleneck. Training a model specifically for the Router's job is one direction they think is worth trying.
Second, how people work with an agent that has no sessions. Once the sessions underneath no longer match the conversations on screen, it's still open how tasks should be shown and managed. Their own internal agent works directly in GitHub issues and pull requests, and people should be able to step in or take over halfway through a task.
Third, where context ends. As this grows from individuals and small teams to whole organisations, deciding who shares one agent is really deciding which context is shared and which is kept apart. How separate agents can work together safely and reliably is unsolved.
Fourth, security and privacy. Being event-driven means taking in more untrusted input. If the cloud agent loop is breached or prompt-injected, every machine connected to it could be taken over; and even if the cloud is fine, any credential that ends up in the model's context can leak. The agent has to learn to use credentials without ever seeing them.
What you can borrow now
The article says itself that it offers no new theory; it moves old computer-systems ideas over to agents. That's also why a lot of it doesn't depend on DeepSeek Harness, and teams building agent products can try it today. Here's what we'd pick out.
Keep the session that talks to people from doing the work; hand the work to isolated sessions and let that one session do all the replying, so however busy things get behind the scenes, the user is talking to one agent. Send follow-up messages straight to the session that owns the Thread instead of through a central dispatcher every time. Filter with plain code before asking the model anything, which saves a lot of calls. Split slow tools into start() and stop() and bring results back as new events, so the conversation never stalls. Put a word limit on chat replies; they use 100 words. And run a separate watchdog that checks not just whether the process is alive but whether it's actually getting anywhere.