How DeepSeek’s Super-agent works

On 1 November 2026, the DeepSeek Harness team published a long design note titled Exploring Super-agent Design: Towards a More Autonomous Agent System. I read it, then spent about an hour working through it at a whiteboard, with a colleague asking questions along the way. This page is the written version of that session, with the drawings redone so that they can be read on their own.

The note asks a question that anyone who works with coding agents will recognise. Agents now finish single tasks with little help. So why does a day of working with them still feel limited? DeepSeek’s answer is that the limit has moved. It is no longer mainly the model; it is the person who has to open, watch and remember every agent session. The rest of the note is a system design for taking that job away from people, and nearly every piece of it is borrowed from classic computer systems (Table 1).

We follow one small, invented example through every section: a team of six building a mobile app, and seven events that reach their tools between 10:01 and 10:07 one morning. Each idea is shown twice. A drawing explains the mechanism, and a worked example shows what you would actually see: the WhatsApp group, the X post, the pull request, the email, and the text the model receives in its context window. Details from DeepSeek’s note that the story does not need, such as exact quotations and measured numbers, sit in boxes headed In DeepSeek’s note. Short clips from the video show the whiteboard being drawn at four times speed, and each one links to that moment in the video, where you can watch it at normal speed with sound. The page ends with a quiz.

1Where agents are stuck

Open a coding agent today and the unit of work is a session. You click the plus button, a new session starts, and you type a request into it. To work on three things at once, you open three sessions and switch between them. Each session knows only what was said inside it, so you also carry a map in your head: which session read the CI log, which one has the plan we agreed on, which one is waiting for an answer.

DeepSeek puts a number on how far this goes. In their experience a person can follow only 3 to 5 active sessions at once. Their summary of the situation is the sentence the rest of the note is built on: a single task is limited by model capability, but doing many tasks is limited by human attention (Figure 1).

A natural first fix is to connect the agent you already have to more places: give it a CLI for GitHub, an MCP server for the team chat, a connector for email. Now it can receive outside messages. DeepSeek’s point is that the basic limits stay. The agent still runs one synchronous session that blocks during long operations, the contexts of different tasks get mixed together in it, and everything stops when the laptop goes offline. Someone also has to keep the whole arrangement running.

Here is the morning we will follow. None of these people or events is real; they are a small, concrete stand-in for the group chats and GitHub projects DeepSeek describes (Table 2).

With a single-session agent, only event 7 reaches it, because only event 7 mentions it. Nobody tagged it on Priya’s bug report, so it never sees event 2. If someone wants help with the pull request, they open a session, paste in the CI log and the review comment, and then remember that this session is “the #412 one”. That remembering is the work DeepSeek wants to take away.

2What a Super-agent is

DeepSeek’s proposal is to decouple the agent from any single session that a person drives by hand. The agent becomes one continuous entity. It keeps its context across sessions and works on several complex tasks at once without the tasks interfering with each other. They call this kind of agent, and the system around it, a Super-agent.

They ask for four properties (Figure 2). It should be continuous: people talk to it where they already work, in chat or in GitHub comments, and it always feels like one agent. If Arjun asks for plan A in chat and later switches to plan B in a pull-request comment, it understands the change. It should be productive: several tasks in parallel, each to a high standard, and it takes the next instruction before the last one finishes. It should be proactive: it watches events, acts on anything worth handling and stays quiet otherwise. And it should be persistent: always online, connected to real working environments, and able to recover from failures on its own.

Continuity is the easiest property to see on a real screen. Arjun asks for release notes in the team chat, then changes his mind an hour later in a comment on the pull request. One agent sees both, so it knows the second request replaces the first (Example 2).

No single ReAct loop gives all four at once, so they have to come from the system around the model. That is the claim that turns this from a product idea into a systems problem. DeepSeek also expects personal agents and agents for team work, such as software development, to end up with similar designs, because the constraints are the same: always online, and answering many events concurrently.

3The design on one page

Before taking it apart, here is the whole design (Figure 3). Events from the places where work happens become Triggers. A filter removes noise. A long-lived Router talks to people and hands out tasks, and Workers do the tasks, each in its own context. Events on a conversation a Worker already follows skip the Router entirely. Underneath, sessions live in a database, the agent loop runs in the cloud and reaches machines like your laptop through a small daemon, and a Watchdog outside the system checks that everything is alive and moving. The numbered circles are the sections of this page where each piece is explained.

On the whiteboard I drew it in the same order, starting from the event trigger and ending at the session database and the Watchdog.

4Two levels: a Router and Workers

Start with the simplest design that could be continuous: send every event to one session. That session sees everything, so it never loses track of anything. But a ReAct loop works one step at a time, so one session can only do one thing at a time. On our morning, it would be halfway through reading the CI log for #412 when Arjun’s question arrives, and the details of three tasks would pile up in one context, which DeepSeek says makes the results worse.

Now try the opposite: start a new session for every event. All seven events run in parallel. But when tasks are not fully independent, nothing connects the results. Priya’s bug and pull request #412 turn out to be about the same token refresh code, and two separate sessions would never know it. Several sessions would also reply to the team separately, which is confusing. One design gives continuity, the other throughput, and each gives up the other (Figure 4).

The way out is to give the two jobs to two layers. A long-lived Router handles all interaction with people and all global coordination, so it keeps the continuity. Context-isolated Workers do the tasks, so the work runs in parallel. On our morning, the Router starts Worker 1 for pull request #412, Worker 2 for Priya’s login bug and Worker 3 for Arjun’s question.

The Router is the system’s single global point: every cross-task fact and decision passes through it, so it serves as the place where events are put in order, where tasks are coordinated, and where memory lives. To keep one global node from becoming a bottleneck, it is designed not to do tasks itself. It only talks to people and dispatches work, and it can run without a Bash tool at all. Its job turns out to be simpler than you might expect, and DeepSeek finds that a lighter model usually gives both speed and quality there.My colleague asked at the board whether this is just a main agent with subagents. The difference is the same one DeepSeek draws with an Agent Team: a team lead usually breaks one complex task into tightly coupled steps and coordinates the members, which is heavy reasoning. The Router does not break tasks down; it dispatches separate tasks and tracks how they relate.

Workers are the opposite. Each has an isolated context and a full set of execution tools and is given one task, so each needs the most capable model. Workers never talk to people directly; their reasoning and tool calls stay out of the team chat. Each Worker reports to the Router, and the Router writes every reply. A Worker can itself start subagents or be an Agent Team, and the Router does not need to know.

Here is what that looks like from both sides. The team sees one agent answering in the group. Behind it, the Router has started three Workers in five minutes and posted nothing it did not need to (Example 3). Notice the last line of its reply: because the Router saw Priya’s report too, it can connect Arjun’s question to the bug.

The consequence for the person is the point of the whole section. Nobody on the team opened a session this morning. Sessions have become an implementation detail of the system instead of something people manage, which DeepSeek describes as a habit carried over from low-level LLM APIs.

Can one Router keep up?

A single long-lived session sounds like the obvious bottleneck. Suppose events 2 and 3 arrive while the Router is still thinking about event 1. They wait, and in the Router’s next turn both go into the same model call. Because the Router only dispatches, that call has a long input and a short output. The long input is read in the prefill, which processes all its tokens in parallel, so two events cost much less than twice one event. The busier the Router gets, the more events share each call, and the less time each decision costs (Figure 5).

5Triggers, and which ones matter

With the two levels in place, look at what drives the system. A chat model is driven by prompts a person types. A Super-agent is driven by semi-structured events from the environment: chat messages, emails, calendar reminders, review comments, CI results. DeepSeek calls these Triggers. Because the agent listens for them, it no longer waits for a command before each run.

The trouble is volume. Connected to a real group chat and a real repository, the agent sees a noisy stream in which most messages need nothing from it. Asking a large model to judge every one from scratch would be slow and expensive. DeepSeek borrows the fast path and slow path from computer systems: frequent, well-defined judgments become plain code, which is fast and cheap, and only the cases that need understanding go to a model, which is flexible and expensive.

So filtering has two stages. First, code checks deterministic facts: the source, the group, allowlists of users and bots. Each source can be set to “respond only to explicit requests”, “treat as candidate events” or “ignore”. Then a model judges the candidates against policies written as prompts, which people can switch on or off, or add, at any time. Trace the morning through it (Figure 6). The build bot is on the ignore list, so code drops event 4 without calling a model. Event 7 tags the agent, so code admits it directly. Events 1, 2, 3, 5 and 6 come from sources set to “candidate”, so the model reads them; it drops “lunch at 1?” and admits the rest.

On a real screen, every message gets a verdict, and the verdicts come from rules and prompts that the team can read and change (Example 4). Two more events arrive here: Meera’s message about the same login problem, and a customer’s post on X. The model links both to the bug the agent already knows about.

agent config, invented for this example# code rules (fast path): no model is called
build-bot                    → ignore
group "App team"             → candidate
message tags @Agent          → admit
X post mentions us           → candidate

# policies (slow path): prompts a model applies,
# which anyone on the team can edit
1. Ignore social chat: lunch, greetings, thanks.
2. Silently reproduce and fix: when someone reports
   a bug, try to reproduce it in the background.
   Speak only after you have reproduced it and
   found a simple fix.
3. Customer reports on X: link them to an open bug
   Thread if one matches. Never reply in public
   without a person's approval.

6Threads and pass-through

Five events survive the filter. Should all of them go to the Router? Look at events 3, 5 and 6: a pull request opens, its CI fails, and a reviewer comments on it. They are one conversation. If the Router had to read and forward each follow-up, the single global node would do a lot of repetitive work and every reply would be slower.

DeepSeek calls such a stream of related events a Thread: consecutive events on the same pull request, chat topic or email chain. When the Router starts a Worker for the first event of a Thread, that Worker subscribes to the Thread. From then on, code passes the Thread’s follow-up events straight to the subscribed Worker. The Router still sees every event, so it can keep track of the whole picture, but it only evaluates and dispatches events that have no subscriber yet (Figure 7).

The pull request page makes the idea concrete. Everything on that page is one Thread, and the Router’s view of the same minutes shows how few decisions it has to make (Example 5).

Router: what it decides about each event[T5] gh-pr-412  CI failed
     subscribers [W1]       pass through, no decision
[T6] gh-pr-412  review by ankit
     subscribers [W1]       pass through, no decision
[T7] chat       @Agent what changed?
     subscribers none      decide: start W3
[T8] gh-pr-412  comment by W2
     subscribers [W1, W2]   pass through to both
[T9] chat       Meera: anyone else...?
     thread wa-login, subscribers [W2]
                          pass through

Subscriptions are many to many. A Worker can follow several Threads, and a Thread can have several Workers. That matters on our morning. Worker 2, chasing Priya’s login bug, finds that it comes from the same token refresh code that pull request #412 changes, and subscribes to the pull request’s Thread too. Now every new event there reaches both Workers at once, and each can see what the other is doing and avoid a conflict, without the Workers ever messaging each other. If a new event falls outside a Worker’s task, the Worker can unsubscribe or hand the event back to the Router.

7What goes into the context window

An event has now reached the right session. How much of the world should come with it? Here DeepSeek is blunt: wasting the context window is wasting the model’s intelligence. Inject too much and the window fills up and dilutes the model’s attention. Inject too little and the model has to call tools again and again just to read what it needs.

They treat the window as a cache and use two operations from compilers and systems. Inline puts information that is likely to be needed soon directly into the window, saving tool calls. Spill keeps the full information outside the window when it is too long or rarely used, and leaves only a reference or a summary inside, through which the model can read the rest on demand. Combined with locality, this gives three steps. Start minimal: the object’s ID and a summary. Then inline what is near, in space (the message it replies to, the other comments in the same review) and in time (what happened just before). Then cap long content: cut it and leave a pointer to the rest.

Here is what Worker 1 receives when Ankit’s review comment, event 6, arrives (Figure 8).

The easiest way to understand Inline & Spill is to put a real screen next to the text the model receives. Start with Priya’s message. Near it in space are the message it replies to and the one after it; near it in time are the pull request and the CI failure a few minutes later. The screen recording and the 12,481-line CI log are spilled: the model sees that they exist and how to read them, but they do not take up the window (Example 6).

android-tests, run 5521: 12,481 lines...
> Task :app:connectedDebugAndroidTest
TokenRefreshTest > refresh_afterExpiry FAILED
    AssertionError:
      expected:<200> but was:<401>
      at TokenRefresher.kt:88
214 tests completed, 1 failed

Worker 2’s context: one event, injectedEVENT [T2] wa:app-team  Priya  10:02
  "login fails on Android since yesterday's release. iOS is fine..."
  attachment [A7] screen-recording.mp4, 38 s  → read(A7)
NEAR IN SPACE
  replies to [T0] Meera 09:58 "release went out last night btw"
  next [T2b] Arjun 10:03 "same on my Pixel"
NEAR IN TIME
  [T3] gh-pr-412 opened 10:03 "Fix token refresh"
  [T5] gh-pr-412 CI failed 10:05:
     TokenRefreshTest.refresh_afterExpiry
     expected 200, was 401 at TokenRefresher.kt:88
     full log, 12,481 lines → read(T5.log)
THREAD [wa-login]  subscribers [W2]

Now a long comment. Worker 1 receives the first part of Ankit’s review and a pointer. It reads the rest only because the first part is about the same bug it is working on (Example 7).

Worker 1’s contextEVENT [T6] gh-pr-412  review comment  ankit  10:06
  "please add a test for expired tokens, and check the
   Android path where the refresh runs while the app is
   resuming from the backgro... [cut at 160 chars:
   rest → read(T6)]
NEAR  replies to [T3] PR opened by meera
      1 min before: [T5] CI failed, refresh_afterExpiry

# the model decides it needs the rest:
→ read("T6")
  "...und; that is where I saw the 401 last week. Also,
   refreshIfNeeded() is now called from two places, so it
   may run twice and the second call can still send the
   old token. Can we guard it, or move the call into the
   interceptor? Happy to pair on it after lunch."

The same method works outside software. A personal agent that receives the ninth reply in an email thread does not need all nine bodies and two attachments in its window. It needs the new message in full, one line for each earlier message, and anything nearby in time, such as a calendar entry on one of the proposed dates (Example 8).

context: an email Thread of 9 messagesEVENT [M9] email  Neha  08:52  "Re: Team offsite..."
  "Lake View can do 20 to 22 Nov for 14 people. They
   need a deposit by Friday. ... Can you confirm the
   dates work for your team?"
  attachments [F1] contract.pdf, 6 pages  → read(F1)
              [F2] floorplan.png         → read(F2)
EARLIER IN THE THREAD, one line each
  [M1] you      "We need a place for ~14, late Nov"
  [M4] Karan    "Avoid 18 Nov, product review"
  [M7] Farah    "Budget cap is the same as last year"
  ... 5 more → read(thread=offsite)
NEAR IN TIME
  [C4] calendar: 21 Nov 10:00 board call (yours)

Notice that nothing has been thrown away. The full comment and the full CI log still exist; they are just one tool call away instead of filling the window. That is different from summarising old context and discarding the original.On the whiteboard I said that DeepSeek does not compact context at all. The note does not discuss compaction either way; what it describes is Spill, which keeps the full information outside the window behind a pointer. That is the accurate way to put it.

Chain of Recall

The Router has a context problem of its own. Follow-up events pass straight to Workers, and finished tasks pile up over days, so it cannot keep every task’s history in its window. Yet if someone brings up an old task in another channel, it has to recover that task’s context.

Apply Inline & Spill to every kind of object in the system, Triggers, Threads and Worker sessions alike, and give each one an ID. Whenever an object is injected, the IDs of its closest relatives are inlined with it. The IDs link everything into a reference graph, and each object read through a tool call inlines the IDs of the next hop. Starting from the current event, the model can follow these references as far as it needs. DeepSeek calls this Chain of Recall (Figure 9).

Step through the same question as the Router does (Example 9). It never searches everything. It starts from the one line it kept, reads an object by ID, and lets each result tell it where to look next.

A personal agent recalls across apps in the same way. Asked about a dentist appointment, it goes from a chat message, to the email it links to, to the calendar entry that email created (Example 10).

8Acting ahead

Go back to Priya’s message at 10:02. Nobody asked the agent to do anything. A reactive agent would wait to be tagged. DeepSeek borrows one more idea from processors, speculative execution: based on signals in the environment, start work in the background before knowing whether the result will be used. Deliver what turns out to be useful, discard the rest. It spends extra background compute so that people wait less and step in less often.

Their internal user group runs a policy they call “silently reproduce and fix”. When someone reports an issue or discusses a change, the agent first tries in the background to reproduce the issue and find a fix. It speaks only after it has confirmed the issue and found a simple fix; otherwise it stays quiet the whole time. On our morning, that is Worker 2: started by the Router from event 2, it reproduces the Android login failure, traces it to the token refresh change, and only then says something in chat. The same idea works for personal agents. When a meeting invitation arrives, the agent can check the calendar, gather background and draft a reply, so the person only reads and sends.

Example 11 shows both outcomes of acting ahead on the same morning. Priya’s report is confirmed and fixed before anyone asks, and Riya’s vague complaint is checked and dropped without a word in the chat.

9Never blocking, and speaking each channel’s language

Two more problems remain in day-to-day use: how the conversation works while long jobs run, and where and how replies are written.

In a classic ReAct loop, when the model calls a tool with a synchronous run(), the loop waits until the tool returns. Until then the session cannot respond to anything new. Suppose Worker 1 starts a test suite that takes twelve minutes, and at minute 3 Ankit asks it a question. In a turn-based, half-duplex loop, Ankit waits more than nine minutes for an answer to a question that needed a few seconds.

DeepSeek replaces the time-consuming calls with asynchronous start() and stop(). Calling start() returns “Started” at once and the loop carries on. When the tool finishes in the background, its result arrives in the session as a new event message, and the model can call stop() if a command runs too long. The conversation becomes full duplex: new input is handled as soon as the current inference step ends, not when the background tools finish (Figure 10).

On the pull request page the difference is easy to feel. With half duplex, Ankit’s quick question sits unanswered for nine minutes. With full duplex, it is answered at once, and the test result arrives later as its own event (Example 12).

Worker 1’s loopmodel → start("gradlew connectedAndroidTest")
        ← "Started" [J3]          # returns at once
model → reply "Started the full Android suite..."
event   [T14] ankit: "does this change touch iOS?"
model → reply "No. Only android/auth/..."
        ... 9 minutes, nothing to do ...
event   [J3] finished, exit 0, 214 passed
        full output → read(J3.log)
model → reply "Suite finished: 214 passed, 0 failed."
# and if [J3] ran past an hour: model → stop(J3)

The second problem is the channel. People write differently in a group chat, in email and on GitHub, and a reply that suits one is wrong for another. The two-level design already solves part of it, because a Worker’s long reasoning and tool logs never reach a channel. The rest is set with prompts per channel. In chat, keep it light: like a good colleague, interrupt only when a decision or sign-off is needed, ask direct questions and give short conclusions. DeepSeek has verified one simple hard rule: at most 100 words per reply. On GitHub, in email and in documents, be complete and structured: the background, the change, and how it was verified, in the project’s conventions (Figure 11).

One result usually has to go to several places, each in its own form (Example 13). The chat gets a conclusion and one question. GitHub gets the full record. The support lead gets the impact on customers. And a public reply on X waits for a person to approve it, because that is what the team’s policy says.

10Compute, state and environments

Persistence is next. A local agent ties three things to one machine: the compute that runs the agent loop, the session state that has to survive, and the execution environment, meaning the repository, the toolchain and the credentials. When the laptop sleeps, all three stop, and the agent cannot reach anything on other machines. DeepSeek takes them apart in two steps, borrowing compute and storage separation from systems design (Figure 12).

Step one separates compute from state. The agent loop does not need to keep anything, so it runs in stateless, elastic cloud containers that can scale, restart or be replaced, and the sessions live in a database. A laptop going to sleep no longer stops the agent.

Step two is harder. Once the loop is in the cloud, how does it reach the code it needs to work on? One option is to start a cloud sandbox, pull the code and rebuild the environment. But real environments contain uncommitted changes, private credentials, services that are only reachable inside the company network, and particular hardware, so copying them is expensive and easy to get wrong. Another option is to ask people to move their work to the cloud, which is too costly for many of them. DeepSeek’s answer is to leave each environment where it is. Every machine runs a lightweight daemon that keeps no session state and does only one thing: execute commands and return results. The agent reads context from the environment on demand.

They call this BYOM, bring your own machine. It also handles machines that are only sometimes online: when Priya’s laptop, with its Android emulator, reconnects, the cloud agent starts and finishes the tasks that need to run there.

priya-mbp, an illustrative daemon log$ agentd status
connected to the agent loop (cloud), keeps no session state

10:09 run  ./gradlew :app:installDebug           [W2]
10:10 run  adb shell am start -n app/.LoginActivity [W2]
10:16 run  ./gradlew connectedAndroidTest \
           --tests '*TokenRefresh*'               [W2]
10:19 exit 1, 3 tests, 1 failed, 41 KB returned
18:47 laptop asleep, disconnected
09:03 reconnected
09:04 run  ./gradlew connectedAndroidTest         [W2]
09:15 exit 0, 214 passed, 38 KB returned

11The Watchdog

Staying online for weeks takes more than the separation above. A system that runs continuously needs a control loop outside itself. For an agent, the usual process checks are not enough, because many failures are not crashes. The process is running, but the model is stuck in an unproductive loop or has drifted from its goal. So the system has to watch the progress of tasks as well as whether the infrastructure is alive.

DeepSeek’s control loop is a separate Watchdog session, outside the main system and woken by scheduled messages. It handles infrastructure failures such as API errors and failed state recovery, and it uses the model to judge whether each Worker is making real progress or drifting. It fixes what it can and keeps rechecking transient outside failures until they clear (Figure 13). In our example, it notices that Worker 2 has re-run the same flaky test six times and steps in.

Watchdog, woken by its scheduled messageinfrastructure
  model API          ok
  session database   ok
  state recovery     ok (last restart 02:10)
progress
  W1 review #412     moving, 2 commits since 10:05
  W2 login bug       stuck, 6 identical test runs
  W3 release notes   done

Because the Watchdog is itself an agent session with a full set of tools, maintainers can ask it in plain language why something failed, and can have it correct the running system, for example by adding or removing prompts or adjusting trigger rules.

12What the experiments show

DeepSeek ran two early experiments on the scheduling and routing design. The first ran four designs side by side on the same stream of group-chat and GitHub CI messages: about 300 messages per run, of which about 20 were work requests and the rest casual chat, follow-ups, cancellations and CI messages. Coding work was replaced by a tool that simply takes time, so the test measures scheduling and coordination, not how well tasks are done. Each design ran five times (Figure 14).

The Super-agent finished tasks in 12.4 minutes at the median and 15.7 at the 95th percentile. The comparison, a single session with a subagent tool, depended heavily on its prompt. With a neutral prompt (“use a subagent for a piece of work when appropriate”), the model never delegated in any of the five runs; all the work ran in the main session, new messages kept interrupting it, and the 95th percentile reached 29.5 minutes. With a prompt that pushed delegation first, it delegated in four of five runs and finished somewhat faster, though still slower overall than the Super-agent; in the fifth run it judged the work “small”, did it itself, and produced a long tail. A single session has to rely on prompting and the model’s judgment in the moment; the two-level design settles the question in the architecture, because the Router never does work itself.

The Super-agent is not free. Running several independent sessions, it read more cached tokens per run than the single-session designs: it trades tokens for shorter, steadier completion times. Pass-through earned its place in a different way. Without it, tasks finished in about the same time, but the Router made about 30% more decisions and cache-read tokens rose from 23.2 million to 31.8 million per run, about 37% more.

13What this is, and what is still open

It is worth being clear about what DeepSeek published. It is a design note, not a product launch. The note says it discusses architectural ideas, not existing features, and that parts of the design are implemented in a prototype plugin, dsh-superagent-prototype, which is only for validating the approach and is not an official DeepSeek product. The experiments are small and synthetic. The authors also say the system can stay simple partly because they have simplified the engineering and the scenarios they support for now. They name four open problems, and each one is a real limit on using this today.

Scaling the two levels. One Router session, pass-through and no direct talk between Workers cover most of their daily work. For larger, tightly coupled tasks, it is not settled when to shard the Router, how finely, or when Workers should talk to each other. Training a model specifically for the Router’s work, judging events, dispatching in batches and recalling context, is one direction they suggest. Long-term memory is the other limit: Chain of Recall handles recent tasks, but over months, memory becomes the main bottleneck.

Working without sessions. If sessions are hidden, what should people see? DeepSeek suspects the chat window became the centre of interaction partly by path dependence, and that more interaction may move into domain tools, as their instance works inside GitHub issues and pull requests. They also want ways for people to step in partway through a background task without losing its efficiency.

Context boundaries and agent-to-agent work. Deciding which parts of an organisation share one Super-agent is deciding which context is shared and which is isolated. Where instances meet, for example a person’s own agent and the team’s, they need a secure way to work together across permission boundaries.

Security and privacy. This is the one I would read twice. An agent driven by events from many places takes in a lot of untrusted input. The cloud loop and the machines it reaches implicitly trust each other, yet the machines hold private code, sensitive data and credentials. If a server intrusion or a prompt injection compromised the agent loop, every connected machine could be taken over. Credentials can leak even without an attack, whenever they enter the model’s context, so the agent needs a way to use credentials without ever seeing them. Until these are solved, DeepSeek says, a Super-agent can only work within a small, trusted scope.

14Summary

• With agents that finish single tasks well, the limit on getting more done has moved to human attention: a person can follow about 3 to 5 sessions.
• A Super-agent is one continuous, productive, proactive and persistent agent. No single ReAct loop gives all four; they come from the system around it.
• Two levels resolve continuity against throughput: a light Router talks to people and dispatches, and isolated Workers with the strongest model do the tasks. Batching lets one Router keep up.
• Events, not prompts, drive the system. Code filters what code can judge, a model judges the rest, and follow-ups on a Thread pass straight to the Workers that subscribe to it.
• The context window is a cache: inline what is near, spill the rest behind pointers, and recall old work by following IDs.
• An asynchronous loop never blocks on a long tool; replies are short in chat and structured on GitHub.
• The loop runs in the cloud, sessions live in a database, environments stay on their machines behind a daemon, and a Watchdog checks liveness and progress from outside.
• It is a design proposal with early, synthetic results, and its security problems are open.

15Quiz

8 questions on the design. Choose an answer to see whether it is right and why, or show the answer without choosing.

16Who wrote this

This page was written by Dr. Raj Dandekar and the team at Vizuara AI Labs, from a whiteboard session recorded on 2 November 2026. At Vizuara we teach AI from first principles, one worked example at a time, the way this page tries to.

As in the video, we teach with love, care and passion. If you liked the way this page explains things, our live cohort Agentic Systems Engineering goes much further: you build a production AI agent from scratch, from the LLM to retrieval, tools over MCP, the agent harness, workflows and evals, on a real business system.

• If you are an engineer moving into agentic AI roles, the cohort is open to individuals.
• If you lead a team and want your engineers to learn this in depth, the same cohort takes enterprise teams.

The current cohort began in the last week of October 2026, and registrations are still open.