DeepSeek Says AI Work Should Stop Being a Session. Here's What That Changes for Your Marketing Stack

Every Monday I open the same four things: a Reddit buying-intent monitor, a keyword tracker, a competitor ad-library watch, an internal-link audit. Each is a separate chat with a separate agent, in a separate tab, and each exists only for as long as I remember to open it. On the weeks I forget the Reddit one, a week of buying-intent threads scrolls past untouched. That is the real state of "AI-powered marketing": not one agent that works, but four timers I have to babysit.

On October 31, 2026, DeepSeek's Harness team published an argument that lands uncomfortably close to that gap, plus an MIT-licensed prototype to go with it: the session should not be the unit of agent work. Not the model, not the prompt — the session. Their design puts one always-on agent in charge of everything, fans work out into parallel isolated workers, and has the agent speak only when a person actually has to decide something.

What DeepSeek actually published

Two artifacts, same day. A design article — "Exploring Super-agent Design: Towards a More Autonomous Agent System," written by Yujia Qiao on the team's WeChat account — and the MIT-licensed dsh-superagent-prototype repository on GitHub.

The README calls it "a proactive coding agent for one GitHub repository, packaged as a bundle for DeepSeek Harness. It listens to GitHub and, optionally, Feishu. When someone allowed asks for work, it opens a work item, works on it in its own agent session and directory, and answers in the original conversation — for example with a pull request. A web panel shows what needs a person."

Two sentences in that README matter more than anything else here: "Research prototype for reference only, not an official DeepSeek product," and "some designs discussed in the article are directions for future development and are not implemented in this prototype." Research code, adapted for publication, and the team calls its own benchmark results "preliminary reference."

The topology: a router that cannot do the work

Two layers, and the upper one is deliberately hollow.

The Router is a persistent session that owns every human entry point — chat, GitHub comments, CI results — and decides which request goes where. It does not do the work; the design article goes as far as saying it may not even have a Bash tool. Routing is cheap enough for a lighter model.

The Workers are isolated sessions with the full tool set, one per unit of work, running in parallel in their own directories. They never talk to a human directly — they report to the Router, which replies on their behalf, so you never get four agents answering you at once. Work arrives as events, not prompts, filtered by code before a model sees it, and each Worker subscribes to the threads it cares about, so a follow-up on a pull request reaches it without passing the Router.

That is the design in miniature. A "lead agent with subagents" topology leaves the lead decomposing the task, so the lead becomes the bottleneck. DeepSeek's Router never breaks a task into steps, and a thin layer never becomes the ceiling.

What their own tests showed

Four setups against a synthetic stream of group chat and GitHub CI messages — about 300 messages per run, roughly 20 of them real work requests, five runs each. Coding was replaced with a time-consuming tool, so this measures scheduling, not output quality.

Setup	Result
Super-agent	p50 12.4 min, p95 15.7 min
Single session with a subagent tool, neutral prompt	Never delegated in 5 runs; p95 29.5 min
Single session, prompt written to prefer delegating	Delegated in 4 of 5 runs; still slower
Super-agent without follow-ups routed straight to Workers	Same completion time; ~30% more Router decisions; cached tokens read rose from 23.23M to 31.77M
Router at ~1 trigger/minute	6.4 s of inference per decision
Router at ~40 triggers/minute	1.6 s per decision, average batch 2.8

Read the second row twice. With a neutral prompt the model did every piece of work itself and kept getting interrupted; asking it to delegate helped in four runs, and in the fifth it judged the work too small to hand off, which produced the long tail. The Super-agent removes that judgment call from the prompt — the Router simply cannot do the work. The last two rows explain why one Router scales: batching amortises routing cost as volume rises, so the router gets cheaper per decision exactly when it gets busier.

The part worth stealing: attention as the budget

The philosophy document opens with the most quotable line in the release: take as little human attention as possible, and give as much value as possible. Every part of the project is judged by the attention it costs — a message, a notification, a question, a panel element, a paragraph of documentation. Each has to give back more than it takes, or it gets removed.

The rules are short enough to steal wholesale: act only when asked or when a written rule allows it, and work nobody asked for starts by only recording what it would have done; speak only when a person must act or can use a result; ask one concrete question at a time; stop by impact, not by effort; report honestly. The panel shows only what needs a person. And for whoever operates it: "Do not use it to produce volume."

The authorization document turns that into mechanics you can adopt without running the project. Accept mode has three states: off, observe (the default), and auto. In observe mode a candidate the model judges worth accepting is recorded as "would accept" and nothing is accepted, while explicit requests still work in every mode. Rules, accept mode and each source's policy hash into a policy version every work item records, so weakening a rule cannot kill running work outright, but it can revoke a Mandate on revalidation. Bots cannot make explicit requests at all.

If you already run agents on a schedule — my daily Reddit monitoring agent is the one I would point this at — observe mode is your Monday task: run the proactive path in record-only for a week, read what it would have done, then widen it.

What a marketer would actually build with this

The prototype is developer-leaning and scoped to one GitHub repository. But the topology ports, and it forces you to answer the right questions.

One persistent router, N parallel workers. The router watches the sources — Reddit, a forum, a Slack channel, a cron — and dispatches; it cannot do the work, so it never gets tempted to half-finish a job to save a round trip. The workers are one isolated session per job: the daily buying-intent sweep, a 200-keyword SEO brief batch, a competitor ad-library digest, a 1,000-URL internal-link audit.

Two things change. First, routing is cheap, so only the workers need a strong model and you can pick those per job — DeepSeek's own answer would be V4.1 Flash, because the workers are exactly the shape of job it was priced for: high volume, bounded output, cache-heavy context. The project is model-agnostic in principle, so that call is yours.

Second, and more important, you get a licence to run quiet automation that most teams never get approved for, because the failure mode people actually fear is not a wrong answer — it is forty notifications a day. "It speaks only when a person must act or can use a result" is what makes an always-on marketing agent approvable by someone who does not want to become a monitoring dashboard. It is also the clearest architectural answer I have seen to the always-on-agent products already sold to marketers — ChatGPT Work, Lindy AI — because DeepSeek published the shape rather than another subscribe button.

The strongest counter-argument

The permission model that makes it quiet is the same one that gives workers a shell.

The execution document says worker sessions run commands without approval, as the operator's OS user, and that the blocked-command list and directory wrappers "establish defaults, not a security boundary. A worker can still execute a program by absolute path." Auto-merge is off by default for the agent account, and default instructions only allow it for a pull request under 200 changed lines with approvals covering the head commit. Reasonable defaults — but not a sandbox.

The design article is blunter about the rest: unless those problems are addressed, a super-agent can operate only inside a small trusted scope, and a cloud loop fed external events and connected to devices holding credentials is exposed to prompt injection. Consider what a worker reads — issue bodies, PR comments, READMEs, chat messages. All text somebody else wrote, and all of it able to carry an instruction.

Then the benchmark: synthetic, self-reported, measuring scheduling rather than output quality. Faster routing to a wrong artifact is not a win, and as of early November nobody outside DeepSeek had reported running the prototype on a real repository — the repo passed 4,300 GitHub stars by November 1, but its Hacker News submission had nine points and no comments.

And the marketing-specific objection: everything here is a repository, a shell and a git identity. Marketers do not have pull requests. The translation to a marketing stack is not a port — it is a redesign, and the redesign is on you.

Where I land

Read the design. Do not install it yet.

That is the README's own posture, and for a marketer it is the honest one. But read it, because the real contribution is not the router-and-workers split — router plus workers, event queues and ticketed work are familiar pieces, and you can find the same shape in most multi-agent frameworks. The new part is that silence is a first-class outcome: a panel showing only what needs a person, an agent quiet while it works, an observe mode that records what it would have done instead of doing it. That is a policy layer, and policy layers are the one part of an agent stack you cannot bolt on afterwards.

The design also argues, sideways, that most of our marketing agent stacks have been shaped wrong. We built around chats because chats are what the tools handed us. A router, a fleet of workers and a strict interruption policy is what an always-on marketing agent should have looked like from the start — and the moment you sketch that shape is the moment you stop asking which tool to subscribe to next.