The super-agent architecture: what DeepSeek's blueprint means for your business

Last updated: 2 November 2026

Key takeaways

• The bottleneck in agent systems has moved from model capability to human attention. One person can supervise roughly three to five active sessions before context leaks and work stalls.
• DeepSeek's answer is to stop treating the session as the unit of work: a long-lived router holds global context and dispatches to isolated workers that run in parallel.
• Four properties define the target: continuous, productive, proactive and persistent. None of them come from a better prompt. They come from the system around the model.
• The published experiments are preliminary and measure scheduling, not task quality. The prototype is research code, not a product.
• The unsolved part is security. A cloud loop wired to endpoint devices holding credentials concentrates privilege, and the essay says so plainly.
• For businesses, the practical move is to copy the pattern, not the code: separate the decider from the doers, make state durable, and supervise progress rather than uptime.

On 1 November 2026, the DeepSeek Harness team published an architecture essay called Exploring Super-agent Design: Towards a More Autonomous Agent System. It reached 2.08 million views in twenty-four hours. That is not normal traffic for a design document, and the reason is simple: it named a problem most agent teams feel but few have articulated.

The human has become the scheduler.

Over the past two years, single-task agents went from demos to something close to reliable. Coding agents in particular proved that a model with tools can hold a task for minutes or hours with decreasing supervision. As that happened, the constraint shifted. It is no longer whether the model can do the next step. It is how many tasks a person can keep in their head at once.

Most products did not adapt. They still present a list of sessions, each with its own context, and expect the user to remember which session knows what. Add a CLI, an MCP server or a chat connector and the agent can receive outside messages, but the underlying shape does not change: one synchronous loop, blocking on long operations, mixing contexts, stopping when the device goes offline.

The business consequence hides in the workflow rather than the invoice. A team running ten agents but supervising three is paying for ten and getting three. The unused capacity does not show up as a failed task. It shows up as work that never gets delegated, context that gets re-pasted, and a senior person spending their day as a human message bus.

What a super-agent actually is

The essay is unusually disciplined about definitions. A super-agent is not an agent that does more. It is a system that satisfies four properties at once, and each one has a different architectural cost.

Continuous. The user interacts with it where they already work, in chat and in code review comments, and it feels like one agent. They never have to wonder whether session X contains information Y. If a plan is agreed in chat and then changed in a pull request comment, the agent understands the change and adjusts.

Productive. It responds quickly and completes several complex tasks in parallel, each to a high standard. It can accept the next instruction before the previous command has finished.

Proactive. It monitors events in its environment, acts on what is worth handling, and stays quiet otherwise. The second half is the hard part. An agent that can act for a whole team can also waste a whole team's attention.

Persistent. It is always online, connected to real working environments, and recovers from anomalies during long-running operation.

No single reasoning loop delivers all four. They have to come from the system around the loop. That is the whole argument, and everything else in the essay is a consequence of it.

The core move: two levels, one continuous identity

If you route every event into one session you get continuity but no throughput. If you give every event its own session you get throughput but no continuity. The design splits the difference by splitting the responsibilities.

The router layer is a long-lived session that handles all human interaction and global coordination. It maintains the shared picture of what is happening, decides what each event means, and dispatches work. Critically, it does not execute. The worker layer is a set of context-isolated sessions that run tasks concurrently, each seeing only the threads it subscribes to.

That single rule, the router never does the work, is what makes the system predictable. In a single-session design, whether work gets delegated depends on the model's on-the-spot judgement and on how the prompt is worded. In a two-level design it depends on the topology. The router has no choice but to dispatch, because execution is not available to it.

The obvious objection is that a single router becomes a bottleneck. The essay's answer is batching. Because the router's job is judgement and dispatch rather than execution, its calls are short and can be merged. Under load, several pending events are handled in one inference pass. The stress test raised decision-triggering events from about 1 to about 40 per minute; average batch size rose from 1.0 to 2.8 while time per request grew only from 2.5 to 3.9 seconds. Amortised time per decision fell from 6.4 to 1.6 seconds.

That is the economic argument for keeping one router: a single global context is worth more than the throughput you would gain by sharding it, at least at team scale. The essay is explicit that this is provisional. Once tasks grow more coupled than one router can hold, the right sharding structure is an open question.

Event-driven: from "ask me" to "notice this"

Proactivity is not a personality trait you add with a prompt. It is a pipeline: ingest, filter, route, organise context, and decide whether to act before being asked.

The system listens to sources such as group chats, GitHub issues, pull requests and CI results. Each event passes through a gate. Cheap deterministic rules handle the obvious cases: is this message addressed to the agent, is it in a watched channel, does it match a trigger pattern. Anything ambiguous goes to the router for a model judgement. The router then either ignores it, records it, or opens work.

A thread is the shared context for a unit of work. Workers subscribe to the threads relevant to their task. This replaces direct worker-to-worker messaging, which is hard to audit and easy to make inconsistent. The router can also pass through context: relevant facts from elsewhere in the system are injected into a worker's thread so it does not have to rediscover them.

Pass-through is the most commercially interesting mechanism in the essay, because it is a pure cost play. Removing it did not make tasks slower in the experiment, but it increased router decisions by about 30% and raised cache-read tokens from 23.2M to 31.8M per run, a 37% increase. In plain terms: shared context is cheaper than repeated rediscovery.

The most aggressive version of proactivity is acting before a request exists. In the essay's internal deployment, the agent monitors public group chats and, even when nobody mentions it, traces a reported problem to its cause and opens a pull request. That is powerful and dangerous in equal measure. It only works because the team has written rules about what it may act on, and because every action lands somewhere reviewable, like a PR, rather than directly in production.

Full-duplex: stop making the user wait

Half-duplex interaction is the default in almost every agent product: the user sends, the agent works, the user waits. The essay treats that as a design flaw, not a technical limit.

In a half-duplex system, a long-running task blocks the conversation. New information arrives but cannot be incorporated until the current run ends. The user either waits, or starts a second session and creates the context fragmentation the architecture is trying to avoid.

Full-duplex means the agent can accept new input while work is in progress, acknowledge it, and fold it into the running task. Combined with multiple channels, it means the same agent can be mid-task in GitHub and still answer a question in chat, without either interaction corrupting the other.

The test is simple. Start a long task, then change a requirement while it runs. If the agent cannot incorporate the change without restarting, you have half-duplex with better typing indicators.

Separating compute, state and environment

This is the least glamorous part of the essay and the one most likely to determine whether your agent survives contact with real work.

A local agent ties three things to one device: the compute that runs the loop, the state that must persist, and the environment the work happens in. That coupling is why agents stop when a laptop sleeps, and why they cannot reach a repository on another machine.

The design decouples them in two steps. First, run the loop in stateless, elastic containers and keep session state in a database. The containers can restart or be replaced; the log preserves continuity. Second, keep state-heavy execution environments where they are, and connect them through a lightweight endpoint daemon that holds no session state and does nothing but execute commands and return results.

DeepSeek's variant supports "bring your own machine": the user's own development machine connects to the cloud agent. That is a deliberate bet that real environments contain uncommitted changes, private credentials, intranet dependencies and specific toolchains that are expensive to replicate in a cloud sandbox. Anthropic's managed version makes the opposite bet for many customers, provisioning sandboxes on demand and reaching resources inside a customer VPC.

Neither is universally right. If your work depends on a specialised local toolchain or sensitive data that cannot move, BYOM is the pragmatic option. If your work is greenfield and cloud-native, provisioned sandboxes are simpler to govern.

The watchdog: monitoring progress, not just uptime

A persistently online system will not stay reliable on its internal logic alone. It needs an independent control loop outside the main system.

Traditional monitoring answers "is the process alive". Agent systems need a second question: "is the work actually progressing". Many failures are not crashes. The process is running, the model is looping, the goal has drifted, and nothing alerts because every health check passes.

The watchdog is itself an agent session, driven by scheduled messages, running outside the main system. It handles infrastructure failures such as API errors and failed state recovery. It also uses a model to judge whether each worker is making substantive progress or drifting from the goal. Because it has a full toolset, maintainers can ask it in natural language why something failed, and it can adjust the running system, for example by changing trigger rules or prompts.

What the experiments actually show

The numbers are useful precisely because the authors are candid about their limits. Four designs ran against the same synthetic stream of group chat and CI messages: about 300 messages per run, of which roughly 20 were genuine work requests. Coding work was simulated by a tool that consumes time. Each design ran five times. The measure was time from work request to result message.

Design	p50	p95	Note
Super-agent	12.4 min	15.7 min	Stable across runs
Single session, neutral prompt	long	29.5 min	Model never delegated in five runs
Single session, delegation-first	better	long tail	Delegated in four of five runs

The lesson is not that two-level is always faster. It is that two-level is predictable. The single-session design's performance is a function of prompt engineering and the model's momentary judgement. The two-level design's performance is a function of topology.

Batching produced the second result. Raising decision-triggering events from 1 to 40 per minute increased average batch size from 1.0 to 2.8. Time per request rose only from 2.5 to 3.9 seconds, so amortised inference time per decision fell from 6.4 to 1.6 seconds. That is a four-fold improvement in decision throughput without adding hardware, achieved by letting the router merge events that arrived together.

What is not measured: code quality, false-positive proactivity, recovery from real failures, security incidents, and behaviour beyond a few hundred messages. The essay says parts of the setup could be more rigorous. Do not present these numbers to a board as proof of production readiness.

The unsolved part: security and privacy

The essay is refreshingly blunt here. The architecture that makes the agent persistent also makes it a high-value target.

The design runs the loop in the cloud and installs daemons on execution devices. It implicitly assumes cloud and endpoints trust each other. But the cloud loop keeps taking in external events, while endpoints hold private code, sensitive data and local credentials. If a server-side intrusion or a prompt injection compromises the loop, every connected endpoint can be taken over.

Credentials can leak even without a breach. As long as a credential on an endpoint can enter the model's context, normal execution can expose it. The agent needs a way to use credentials without ever seeing them.

The controls that are not optional:

• Credential vault and proxy. The agent calls a broker that injects the secret at the network boundary. The model never receives the value.
• Per-endpoint scoping. A worker should only reach the endpoints its task needs, not every machine the user has connected.
• Egress control. Outbound network access from an endpoint daemon should be allowlisted, or an injection becomes an exfiltration channel.
• Human approval for irreversible actions. Merges, deploys, payments, deletions and external emails need a gate that is not a prompt instruction.
• Full action logs. Every tool call, with inputs and outputs, attributable to a task and a user.

A super-agent concentrates privilege. It has access to many environments, runs unattended, and takes instructions from untrusted channels. That combination is only acceptable if the credential layer is stronger than the model layer. Build the vault before you build the autonomy.

Build or buy: the 2026 landscape

Every major platform now offers some version of the same shape. The differences that matter are custody of state, maturity, and how much of the scheduler you have to assemble yourself.

Shortest path to long-horizon agents: a hosted managed service. You trade portability for operational simplicity, and you should insist on stable interfaces so the harness can change underneath you.

Control over state, retries and approval flow: a low-level framework such as LangGraph or Microsoft's Agent Framework, which reached 1.0 in April 2026. Expect to assemble the event bus, the router policy and the watchdog yourself.

Cross-vendor interoperability: the A2A protocol, donated to the Linux Foundation in 2025. It solves discovery and messaging, not scheduling. You still need a runtime underneath it.

Learning the pattern: the DeepSeek prototype is the most explicit reference implementation available. Read it, do not ship it.

Because the primitives are stabilising, invest in the parts that are portable: the event schema, the thread model, the credential broker and the evaluation harness. Those survive a change of vendor. The specific orchestration API probably will not.

What this means for your business

Do not copy the architecture wholesale. Copy the pattern that matches your scope, and only add the modules you actually need.

Pattern A, the personal agent. One person, many tasks across chat, email, calendar and code. One router, a handful of workers, BYOM endpoints on the user's own devices. Value: the user stops being the scheduler. Risk: credential sprawl across personal devices. First build: router, event gate, session log. Skip sharding and A2A entirely.

Pattern B, the team agent. One team sharing a project context, typically engineering. One router with a shared thread per work item, workers subscribing to threads, events from chat and code review. Value: continuity across channels and a single place to ask what is happening. Risk: noise, so proactivity must be gated by team-written rules. First build: thread model, subscription routing, pass-through, one review surface such as pull requests.

Pattern C, the organisation of agents. Multiple teams with different permission boundaries. Several isolated instances, each with its own context, collaborating through explicit A2A messages. Value: local autonomy without global data leakage. Risk: this is the least solved area in the essay. First build: the boundary policy, not the protocol.

Before you start, score yourself from 0 to 2 on each line below. Below 8, you are not ready for a proactive team agent.

• Durable session log, where every action is replayable and attributable: 2
• Credential isolation, where the model never sees secrets: 2
• Event ingestion and filtering, deterministic rules first: 2
• Approval gates for irreversible actions, enforced outside the prompt: 2
• Progress monitoring, a watchdog that judges task advance: 1
• Evaluation harness, repeatable tasks run on every change: 1

Metrics, costs and a 90-day sequence

The essay's cost story is counterintuitive: the better architecture uses more tokens. That only makes sense if you change the unit you measure.

Super-agent runs consumed 23.2M cache-read tokens in the experiment, rising to 31.8M without pass-through. A single-session design consumes fewer tokens because it keeps one context alive. If you optimise cost per token, you will rationally choose the slower, less predictable design. If you optimise cost per completed and accepted task, the trade looks different: paying more tokens for a 2x improvement in p95 completion time is usually a bargain.

The six metrics that matter: time to first token at p50 and p95, task completion time at p50 and p95, human interventions per task, cost per accepted outcome, false proactive actions, and recovery time from failure.

The 90-day sequence:

• Days 1 to 30, foundations. Stand up a durable session log and a stateless loop. Move credentials into a broker. Define the event schema and the thread model. Do not add autonomy yet.
• Days 31 to 60, the router. Add a router that owns global context and dispatches to isolated workers. Enforce the rule that the router cannot execute. Instrument time to first token and completion time.
• Days 61 to 80, proactivity. Connect one event source, start with deterministic gates, and require human approval for anything irreversible. Measure false positives before widening the rules.
• Days 81 to 90, persistence. Add the watchdog, run failure injection, and publish the escalation path. Only now consider batching and pass-through optimisation.

Anti-patterns to avoid: prompt-engineered delegation, one mega-session with a bigger context window, migrating every environment to the cloud before proving value, autonomy without a credential vault, and a watchdog that only checks whether the process is alive.

How Flowtivity can help

Most teams do not need a new framework. They need someone to make the architectural calls before the code hardens around the wrong shape.

• Agent architecture design. We map your tasks, choose the deployment pattern, and specify the router, thread model and approval gates before a line of production code is written.
• Credential and security review. A broker, endpoint scoping, egress rules and approval gates that satisfy your risk team, not just your demo.
• Migration and consolidation. If you already run agents in separate sessions and tools, we consolidate them behind one router without losing the context your team depends on.
• Agent ops. Watchdogs, evaluation harnesses and cost dashboards so the system stays reliable after launch.

The verdict

This is the most useful agent architecture document of the year, and it is not a product recommendation. Its value is that it names the right problem. The agent industry has spent two years optimising the loop and almost no time optimising the system around the loop.

Its weakness is that the hard parts are declared open. Security across endpoints, credential handling without exposure, scaling the router, defining context boundaries between organisations, and collaborating across permission boundaries are all unresolved. The experiments are preliminary and measure scheduling rather than task quality. The prototype is research code.

What to do on Monday: audit your session model, find your scheduler, move secrets out of context, pick one event source and one review surface, and change the metric to cost per accepted outcome.

The super-agent is not a new model capability. It is an operating system pattern for agents: separate the decider from the doers, make state durable, treat environments as devices, and supervise progress rather than uptime. Businesses that internalise that pattern will get more useful work out of the same models. Businesses that keep treating the session as the unit of work will keep hitting the same ceiling, and they will keep blaming the model for it.

Frequently asked questions

What is a super-agent?

A super-agent is an always-online agent system that stays continuous across channels, runs several tasks in parallel, acts on events without being asked, and survives device failures. It is defined by those four properties rather than by the size of the underlying model.

Is DeepSeek's super-agent a product I can buy?

No. The architecture is described in a research essay, and the accompanying dsh-superagent-prototype is explicitly research code under an MIT licence, not an official DeepSeek product. Several designs in the essay are future direction rather than shipped features.

Do I need a bigger model to get these benefits?

No. The essay's argument is that continuity, concurrency, proactivity and persistence come from the system around the model. A better model improves each task; the architecture improves how many tasks a person can supervise.

What should a business build first?

A durable session log, a credential broker and an event gate. Autonomy without those three is a liability. The router and the watchdog come next, and batching comes last.

How much does this cost to run?

More tokens than a single-session design, because several contexts stay alive at once. In the published experiment the super-agent used 23.2M cache-read tokens per run, and 31.8M without pass-through. Measure cost per accepted outcome rather than cost per token.