I run a handful of AI assistants: one per client website, plus a set of routines that fire on a schedule. It works, until I try to remember which assistant knows what. On November 1, DeepSeek Harness published an X article called “Super-agent” (about 2.2 million views so far) that puts a name on exactly that problem and sketches a way out. I read the whole thing. Here’s what it says and what I take from it as someone who builds and maintains websites for small businesses.
The problem: your attention is the bottleneck
The article’s opening claim is blunt. Models are getting better at working through hard tasks with less hand-holding, but agents still treat a single session as the basic unit of work, and those sessions are isolated from each other. If you run several tasks at once, you switch between sessions by hand and remember what each one contains. In the team’s experience, a person can usually follow only 3 to 5 active sessions at once. That matches my week: one assistant per client site plus routines, and I’m the one remembering who knows what.
What a Super-agent is
DeepSeek’s answer is one continuous, always-on agent instead of a pile of sessions. They give it four traits:
- Continuous: you talk to it where you already work, and it always feels like one agent. Ask for Plan A in chat, switch to Plan B in a pull request comment, and it understands the change.
- Productive: it handles several complex tasks in parallel and can take your next instruction before the last one finishes.
- Proactive: it watches for events and acts on anything worth handling. Otherwise it stays quiet.
- Persistent: it stays online and recovers on its own when something goes wrong.
The article argues that no single agent loop gives you all four, so they have to come from the architecture around the model.
The Router and the Workers
The core design has two layers. A lightweight Router handles all human interaction and dispatches tasks. It doesn’t run the tasks itself. Context-isolated Workers each take one task, run in parallel, and report back to the Router, which handles every reply to you. Workers never talk to people directly, so you don’t get several sessions answering you at once.
For a web pro, I read that as a clean division of labor: one front desk and a bench of specialists. A client’s content update, a plugin review, and a broken-form investigation each get their own clean context. Nothing bleeds between them, and I only talk to one thing.
Events, not prompts
The second idea is that the agent is driven by events from the environment rather than by prompts you type. The article lists chat messages, email, calendar reminders, code review comments, and CI results as examples. Most of that traffic needs no action, so the system filters first and only escalates what’s worth handling. The article’s own example: its internal instance watches feedback in public group chats and, even when nobody mentions it, finds root causes and opens pull requests.
That’s the shift I care about for small businesses. A site owner doesn’t want to open a chat window and ask. They want the form failure, the expiring renewal, or the unanswered customer email noticed for them.
The numbers, with the caveats
The team ran an experiment with about 300 messages per run, roughly 20 of which were real work requests, and 5 runs per design. The typical (p50) completion time was:
- Super-agent: 12.4 minutes
- Single session with a subagent tool and a neutral prompt: 20.4 minutes
The speed isn’t free. The Super-agent used more cached tokens, 23.2M versus 6.1M, because it keeps several independent sessions alive. The article describes this as trading tokens for shorter, more stable completion times. If you pay per token, that trade matters.
The authors are upfront about the limits. The workload was synthetic, the coding work was simulated by a tool that just consumes time, and they call the results indicative only. In the single-session runs with the neutral prompt, the model never called a subagent at all, so everything ran in one session and new messages kept interrupting it.
What I’d take from it today
I’m not rebuilding my setup around a prototype. But a few ideas apply right now, whatever tool you use:
- Stop making yourself the router. If you’re the one remembering which assistant has which context, that’s the cost the article is describing.
- Keep context isolated per task. One client or one job per worker keeps results clean.
- Let events do the prompting. Email, calendar, and review comments are better triggers than remembering to ask.
- Budget for the tokens. More parallel sessions means more usage.
Security is still open
The article doesn’t pretend this is solved. An agent driven by events takes in more untrusted input, and if the cloud-side agent is compromised, the devices connected to it could be too. The authors also flag that credentials need to be usable without the model ever seeing them. For anyone letting an assistant near client sites, logins, and inboxes, that’s the section to read twice.
My take
The idea that sessions should be an implementation detail, not something you manage, is the one I’m keeping. The team says the bottleneck to further productivity gains is shifting to human attention, and I agree. If you’re a small business owner or a web pro stacking up AI assistants, the question to ask isn’t which model is smartest. It’s who is doing the routing, you or the system.
The prototype the article references is not an official DeepSeek product, but it’s public if you want to dig in.
Sources
- DeepSeek Harness, “Super-agent” (X article, Nov 1, 2026): https://x.com/DeepSeekHarness/status/2116857257245987236
- Prototype repo: https://github.com/deepseek-ai/dsh-superagent-prototype