# DeepSeek's super agent is built for the real AI bottleneck: your attention > DeepSeek's new super agent design runs many tasks in the background and talks to you in one place. It is a research prototype, but it shows where agents are going. - Edition: Daily Issue #8 - Published: 2026-11-02T15:06:13.012Z - Canonical URL: https://genailingo.com/newsletter/deepseek-super-agent-always-on-coding-agent/ ## Key Takeaways - DeepSeek's Harness team published a design for an always on super agent on October 31 and released an MIT licensed research prototype on GitHub. - One long running router talks to people and hands out work, while isolated workers run tasks in parallel. DeepSeek's own test shows faster, steadier task times at about four times the tokens. - The prototype covers one GitHub repository, acts only on allowed requests and runs commands without approval, so DeepSeek recommends a dedicated system account. Security is still an open problem. ## Article The short answer What is DeepSeek's super agent? It is a design for an AI agent that stays online all the time, listens to the places a team already works (chat groups and GitHub), and runs many tasks at once in separate worker sessions while one long running "router" session handles every conversation with people. DeepSeek's Harness team described it in a long technical article on Saturday, October 31, and published a research prototype on GitHub under the MIT license the same day. DeepSeek says the prototype is reference code, not an official product. My view: this matters less as a DeepSeek product and more as a clear statement of where agents are heading. Models can already finish single tasks. The thing that now limits us is how many tasks a person can keep track of, and DeepSeek designed the whole system around that. The problem DeepSeek is trying to solve Most coding agents today work one chat session at a time. If you run five tasks, you have five sessions, and you have to remember which one knows what. DeepSeek's article puts a number on this: in its experience, a person can usually follow only 3 to 5 active sessions at once. Its summary is blunt: a single task is now limited by what the model can do, but running many tasks at once is limited by human attention. I agree with that diagnosis, and I think it is the most useful idea in the piece. Anyone who has run several agents in parallel knows the feeling. The agents are fast. You are the slow part, switching tabs, rereading context and answering the same question twice. DeepSeek's answer is what it calls a super agent, which it defines by four traits: - Continuous, meaning it feels like one agent wherever you talk to it. Ask for Plan A in a chat group, switch to Plan B in a pull request comment, and it follows the change. - Productive, meaning it runs several complex tasks in parallel and takes new instructions before the last one finishes. - Proactive, meaning it watches events around it, acts when something is worth handling and otherwise stays quiet. - Persistent, meaning it is always online and recovers from failures on its own. How it works: one router, many workers The core idea is a split into two layers. A single long lived Router session receives every message from people, keeps the shared memory and hands out work. It does not do the work itself. DeepSeek says it can run without a shell tool at all, and that a lighter model is usually enough for this job. The Worker layer does the actual tasks. Each worker gets its own isolated context and a full set of tools, focuses on one task and never talks to people directly. It reports back to the router, which writes the replies. A few other choices stood out to me: - Cheap rules run before the model does. Most messages in a real chat group need no action. Simple code rules (who sent it, which group, which allowed list) drop most of them before any model is called. Only the remaining candidates go to the model. - Follow up messages skip the router. Once a worker owns a pull request or a chat thread, new messages on it go straight to that worker. DeepSeek calls this subscription and pass through. - Long commands start in the background and report back as a new event, so the agent can keep answering people while they run. DeepSeek notes this is already in DeepSeek Harness but not on by default. - Each channel gets its own style. Chat replies stay short. DeepSeek says one rule it has verified is a cap of 100 words per reply. GitHub and email get full, structured write ups. - A separate watchdog session checks on a schedule whether workers are making real progress or are stuck in a loop, and fixes problems. DeepSeek also runs the agent loop in the cloud while leaving the actual work environments, such as a developer's own machine, where they are, with a small helper program on each one. It openly points to Anthropic's "Decoupling the brain from the hands" article as taking the same approach. When two leading labs arrive at the same architecture, I take that as a sign the design is sound rather than a coincidence. What DeepSeek's own tests show DeepSeek ran a small experiment. Four designs each handled a stream of about 300 chat and CI messages, of which about 20 were real work requests, and each design ran 5 times. The coding work itself was simulated, so the test measures coordination, not coding skill. DeepSeek calls the results indicative only. - The super agent finished tasks in 12.4 minutes at the median and 15.7 minutes at the 95th percentile. - A single session agent with a neutral prompt took 20.4 and 29.5 minutes. It never handed work to a subagent in any of its 5 runs. - A single session told to prefer delegation took 13.8 and 29.0 minutes. It delegated in 4 of 5 runs, and in the fifth it judged the work "small" and did it itself. The part I like most is that DeepSeek also shows the cost. The super agent used 23.2 million cache read tokens per run, against 6.1 million for the neutral single session. So it buys speed and predictability with roughly four times the tokens. Pass through helped on that front: without it, the router made about 30% more decisions and token use rose by about 37%. The lesson I draw is about reliability, not raw speed. DeepSeek says the single session agents were slow mainly because whether they delegated depended on a prompt and the model's judgment in the moment. DeepSeek moved that decision out of the prompt and into the structure of the system. That is a pattern worth copying even if you never touch DeepSeek's code. What the prototype actually does The code you can download today is much smaller in scope. The prototype is a coding agent for one GitHub repository, with Feishu chat as an optional second input. When an allowed person asks for something, it opens a work item, does the work in its own session and folder, and replies where the request was made, for example with a pull request. DeepSeek says much of its engineering was done by coding agents, that it may contain bugs, and that some designs in the article are not implemented in it. Its guiding rule is written right in the README: "take as little human attention as possible, and give as much value as possible." The docs back that up with sensible defaults. The agent acts only when an allowed person asks it directly or a written team rule allows it, and work nobody asked for starts in a mode that only records what the agent would have done. DeepSeek also tells operators to start with a short allowed list and not to use the agent "to produce volume." There is a catch for anyone who wants to try it. The deployment guide says workers run commands without approval as the operator's own system user and can read that user's home folder. DeepSeek recommends a dedicated system account that holds only the agent's credentials. I would not run it any other way. The unsolved part is security DeepSeek is candid that security and privacy remain open problems. An agent driven by outside events takes in far more untrusted input than one that only reads your prompts. The article spells out the risk: if a server intrusion or a prompt injection compromises the cloud agent loop, "every endpoint device connected to it could be taken over." It adds that the agent needs a way to use credentials without ever seeing them. This is the right worry. An always on agent that reads every message in a busy group chat is, by design, listening to strangers. Until that problem has a real answer, I think these systems belong in small, trusted spaces with tightly limited permissions, which is roughly what DeepSeek recommends too. Why this matters beyond DeepSeek Last week's AI news was full of agents reaching places nobody approved, as I covered in Saturday's roundup. DeepSeek's design is interesting partly because it treats restraint as a feature. The agent is meant to speak only when someone must act or can use a result, and to stay quiet otherwise. I also think the article says something about product design. DeepSeek argues that making users manage sessions by hand is a habit carried over from low level model APIs, and that sessions should be an internal detail. If that holds, the chat window stops being the center of AI products. Work moves into the tools people already use, like issue trackers and pull requests, and the agent shows up there as a colleague. My takeaway DeepSeek has not shipped a product here. It has shipped an argument, with a working prototype and honest numbers behind it. The argument is that the next big gain from AI will come less from smarter models and more from systems that protect human attention: one place to talk, many workers in the background, strict rules about when to interrupt, and a watchdog for when things go wrong. You pay for that in tokens and in a larger security surface. For teams already juggling several agents, I think it is a trade worth studying now, because I expect this is how the next generation of coding and personal agents will be built. ## Quick Signal - **[Product] ChatGPT and Codex will share one usage allowance:** OpenAI's Help Center says that starting in December, Plus, Pro and Business plans will share one allowance across ChatGPT and Codex, measured in tokens, as it brings the agent features of Work into the main ChatGPT app. Larger models and harder tasks will use more of it, and Instant chat will not count. OpenAI says it expects most users won't hit a reset more often than they do now, but it has not published token amounts. - **[Research] An AI agent ran a gene therapy injection in a mouse:** Gabriel Ocana-Santero, chief executive of the biotech Exin Therapeutics, said on X and in an interview with WIRED that an AI agent chose a gene therapy, planned the target and drove the needle to inject a mouse with epilepsy, while a veterinary surgeon approved each irreversible step. He said Claude Opus 5.5 planned the work but refused to guide the needle, so the team switched to Claude Sonnet 5. The work has not been peer reviewed. ## Frequently Asked Questions ### What is DeepSeek's super agent? It is an agent design from DeepSeek's Harness team, published on October 31, 2026. The agent stays online all the time, listens to chat and GitHub, and uses one long running router session to talk with people while separate worker sessions carry out tasks in parallel. ### Is DeepSeek's super agent open source? DeepSeek released a research prototype on GitHub under the MIT license. It says the prototype is reference code, not an official DeepSeek product, and that it does not include every design described in the article. ### What can the DeepSeek super agent prototype do? It is a coding agent for one GitHub repository, with Feishu chat as an optional input. When an allowed person asks for work, it handles the task in its own session and folder and replies in the original conversation, for example with a pull request. ### Is the super agent faster than a single session agent? In DeepSeek's own small experiment with simulated coding work, it finished tasks in 12.4 minutes at the median versus 20.4 minutes for a single session agent with a neutral prompt. It used about four times as many cache read tokens. DeepSeek calls the results indicative only. ### Is it safe to run? DeepSeek says its workers run commands without approval as the operator's system user and recommends a dedicated system account with only the agent's credentials. The article also lists security and privacy, including prompt injection, as open problems.