DeepSeek Harness Super-agent: An Always-On AI Agent Design

Picture a bug report landing in a team's group chat. Nobody answers it and nobody opens a ticket. Later, a message shows up: the problem is reproduced, and here's a simple fix. That's roughly how the team behind DeepSeek Harness says its own internal agent already works, and it's the idea behind its new Super-agent design essay.

The essay, shared on X and written in Chinese, proposes a "Super-agent": one AI agent that never logs off, follows chats, emails, GitHub comments and CI results, and keeps many tasks moving at once. Harness is DeepSeek's open-source agent framework, and by the team's account an internal version of the Super-agent already helps it reproduce bugs, answer code reviews and even build Harness itself.

One warning before the details: this is a proposal, not a launch. The post stresses that it doesn't describe current Harness features, and that the open-source plugin released with it, dsh-superagent-prototype, is an experiment and not an official DeepSeek product.

The DeepSeek Harness post that links to the design essay (@DeepSeekHarness)

View on X

A young framework with big rivals

Harness is young. DeepSeek released v0.1 on Aug. 13 as an open-source runtime for building coding agents, alongside the general release of its V4-Pro model, RuntimeWire reported, citing VentureBeat. The same report places Harness against Anthropic's Claude Code and OpenAI's Codex, and notes that higher V4-Pro prices take effect Aug. 16. HPCwire described the launch as a developer preview.

So the team is already sketching what comes after a framework that has only been public for a few months. It also fits a wider push across the industry. Anthropic's engineering team published Scaling Managed Agents in April, describing a stateless harness kept separate from the sandboxes where tools run. Different goals, same direction: pull the agent loop away from any single machine or session.

The bottleneck is you

Today's coding agents can chew through long jobs with little supervision. The team's complaint is what happens around them. In its experience, a person can follow three to five agent sessions at once, and every session is a separate island: you hop between them, remembering what each was doing.

Bolting on command-line tools or MCP servers doesn't fix it, the post argues. A single session still freezes on slow operations, blends unrelated tasks together and goes dark when your laptop sleeps. So the proposal pulls the agent out of the session entirely.

One switchboard, many workers

The design has two layers. On top sits a Router, a long-lived session that handles every conversation with humans. It doesn't do the work itself. It's closer to a switchboard with a memory, and per the essay a lighter, cheaper model can usually run it. Underneath, Workers take the actual tasks, each in its own isolated session with a full toolset and the strongest model available. They never speak to people. They report to the Router, and the Router writes every reply.

That's different from the "agent team" pattern, where a lead agent chops one big task into tightly linked subtasks. Here the Router just hands out separate jobs and keeps track of how they relate. In the team's own deployment, the Router is a single LLM session that stays alive.

Most messages don't deserve a model

The agent doesn't wait for prompts. It watches a stream of events: group chat messages, emails, calendar reminders, review comments, CI results. Chats and code platforms are noisy, so ordinary code makes a cheap first pass, and only the likely candidates reach a language model, which applies rules written in plain language that people can rewrite whenever they like.

Once a Worker owns a thread, say a pull request, later events on it go straight to that Worker without another Router call. And to stop context from ballooning, the system treats the model's memory like a cache: it keeps the likely-needed details in view and stores references it can follow back to older tasks. The team calls that Chain of Recall.

Two smaller choices stand out. Long tool calls run in the background and return "Started" immediately, so the agent keeps answering while work continues. (Harness already supports this, the team says, but leaves it off by default.) And the agent loop runs in stateless cloud containers while repositories and credentials stay on the user's own machine.

Faster, but it costs tokens

The test numbers come with a big asterisk, which the team itself puts up front: synthetic workloads, simplified setups, five runs per design. Each design handled about 300 group chat and GitHub CI messages, roughly 20 of them real requests, with coding work simulated by a tool that just burns time.

On that test, the Super-agent's median task took 12.4 minutes, with the slowest cases at 15.7. A single session with a subagent tool took 20.4 minutes (29.5 at the tail) under a neutral prompt, and 13.8 (29.0) when told to delegate first. With the neutral prompt, the model never delegated in any of five runs. With the delegation prompt it did so in four, and in the fifth it judged the job small and did it itself, which stretched the tail.

The speed has a price. The Super-agent burned 23.2 million cache-read tokens per run, against 6.1 million and 10.8 million for the single-session setups. Switching off the direct hand-off to Workers left completion times alone, but pushed Router decisions up about 30% and tokens up roughly 37%, to 31.8 million. In a separate stress test with mock Workers, time per request grew only from 2.5 to 3.9 seconds while events needing a decision climbed from about 1 to about 40 a minute, so the team concludes one Router session is enough at its current size.

Where it could break

The post is candid about what it hasn't solved. Nobody knows yet when the Router should be split up, or when Workers should talk to each other. Long-term memory over months of use is the biggest bottleneck. Showing tasks to users is an open question once sessions are hidden, and the team suspects more of the interaction will move into tools like GitHub issues and pull requests. It also admits there's no settled way for agents with different permissions to collaborate safely.

Security gets the sharpest warning. An agent wired into chats and inboxes sees far more untrusted input than one waiting for a prompt, and a compromised loop, through intrusion or prompt injection, could expose every device it's connected to. Any credential that can reach the model's context can also leak.

Our take

Our reading: a promising design with a modest first proof. It is not evidence that always-on agents beat a well-prompted single session.

None of the pieces are new, and the team doesn't claim they are. A dispatcher in front of isolated workers, a quick filter before a slow one, a cache for memory: those are old systems ideas, which the essay says it borrowed. What's new is pointing them at the messy places where people actually work, and keeping one memory across all of them.

The numbers say less than the headline suggests. Give the single-session setup a delegate-first prompt and the median gap shrinks from 8 minutes to about 1.4. What's left is mostly consistency: the slowest runs took 29 minutes against 15.7. And since the coding work was simulated with a tool that just waits, the test shows how well the system schedules, not how good the results are.

Cost is the part we'd watch. The Super-agent used 23.2 million cache-read tokens per run, roughly twice the delegate-first setup and nearly four times the neutral one. Harness is built for long, cache-heavy workflows, per RuntimeWire, and DeepSeek just raised V4-Pro prices. That's our inference, not something the essay claims, but an always-on agent that keeps several sessions warm gets expensive in a hurry.

For anyone running agents today, the takeaway is smaller and cheaper: in this data, how plainly you tell an agent to delegate mattered a lot. For always-on agents, the harder hurdle probably isn't speed. It's trust. Handing an agent your chats, your inbox and your credentials is a bigger decision than any benchmark. The things to watch are whether anyone outside DeepSeek reproduces these results, and whether the idea ever shows up as a real Harness feature.

Source: DeepSeek Harness team on X

deepseek ai agents deepseek harness agent architecture

AI

About the author

AI Briefing Daily Editorial. The editorial desk of AI Briefing Daily, an independent publication covering artificial intelligence. Every story is researched against primary sources, checked by hand and reviewed by a person before publication.