DeepSeek's Harness team published an architecture document for something it calls a Super-agent on 31 October, and dropped a working prototype on GitHub the same day. The repository passed 5,000 stars and 480 forks within hours. It is also not a product, which is the part worth understanding.
Read the repository's own warning first: "Research prototype for reference only, not an official DeepSeek product." The code grew out of the team's internal development work, with much of the engineering done by coding agents. Treat it as research code, not production-ready software. The README also notes that some designs in the article are directions for future development and are not implemented in the prototype. One commit, MIT licence, no issues open.
The actual idea
The problem DeepSeek describes is not a model problem. Models are good enough that the bottleneck has moved to human attention. Existing agent designs treat a single session as the unit of work, so people juggling four projects are manually switching contexts between four sessions. The team's observation is that a person can realistically follow only three to five active sessions at a time.
The proposed answer splits into two layers. A Router handles human interaction, holds the global context and dispatches work. Workers execute inside isolated sessions in parallel and never reply to the user directly. They report status and results back to the Router, which owns the outward conversation.
Three mechanisms do the real work:
Event-driven triggering. Group chat messages, emails, calendar reminders, code review comments and CI results are called Triggers. Program rules filter events first, then the model decides whether to act. A Worker subscribed to a Thread receives follow-up events directly, bypassing the Router and cutting routing load.
Inline and spill. Information likely to be needed goes straight into the context window. Everything else stays outside it and is read on demand. Chain of Recall lets the model walk back through Trigger, Thread and Worker session references to recover earlier task history.
Speculative execution. The agent starts background work on environmental signals before you ask. Meeting invite arrives, so it checks your calendar, gathers background and drafts a reply. In a dev team, it tries to reproduce a bug while the group chat is still discussing it.
The numbers they published
DeepSeek ran roughly 300 messages per test with about 20 work requests, five runs per configuration. Super-agent task completion came in at p50 12.4 minutes and p95 15.7 minutes. A single-session-plus-subagent setup with neutral prompts had a p95 of 29.5 minutes. The team is explicit that this measures scheduling and collaboration, not the quality of any single task, and that it ran on synthetic loads in a simplified environment.
The Router stress test is the more interesting number. Push trigger arrival from about 1 per minute to about 40 per minute and the average batch size climbs from 1.0 to 2.8. Per-request latency rises from 2.5 seconds to 3.9 seconds, but inference time amortised per decision falls from 6.4 seconds to 1.6 seconds. Batching events is what buys the throughput, not faster inference.
What is real right now
Several pieces are shipping rather than proposed. DeepSeek Harness is in public preview worldwide and open source, built on Cordis with an everything-is-a-plugin architecture, with desktop builds for macOS on Apple silicon and Windows. The prototype itself listens to GitHub and optionally Feishu, opens a work item when someone allowed asks for work, executes it in its own session and directory, and answers in the original conversation with a pull request. A web panel shows what still needs a person.
The team also runs an internal Super-agent instance continuously, working on bug reproduction, code review responses and Harness' own iteration.
And there is a catch that DeepSeek flags itself. The asynchronous ReAct loop, which turns long tool calls into background start() and stop() jobs so the agent can return "Started" immediately, is implemented in Harness but not enabled by default.
The open problems the team lists are worth reading as a to-do list for anyone planning to copy this: how the Router scales with task volume, long-horizon memory across months, human-agent collaboration after a session ends, agent-to-agent communication between instances, and security once a cloud agent touches a local device. Prompt injection, on-device credential leakage and cross-device permission spread are all named.
The verdict
This is a blueprint and a 5,000-star prototype, not something you can install tonight and have clean your inbox. But it is a serious piece of engineering design published under an open licence with the benchmarks and the limitations attached, which is more than most agent architecture gets. The parts worth stealing immediately: the Router/Worker split so context lives in one place, and the event-trigger model so work starts on a signal rather than a prompt. The part to watch is the Router under load, because the whole thing's throughput depends on batching decisions that one model session has to make correctly.