This document proposes a new agent-system architecture called the Super-agent and explains how to overcome existing limitations to build autonomous systems that operate continuously without human intervention. In particular, it presents a two-tier architecture, event-driven design, asynchronous multichannel interaction, compute-storage separation, and an external watchdog. Together, these let agents handle multiple tasks concurrently, respond proactively to environmental changes, and remain continuously online, allowing humans to focus on high-level decisions and approvals rather than low-level execution.

1. Limitations of Current Agent Systems

Recent single-task agents, such as coding agents, have demonstrated models' ability to use tools to solve complex problems, reducing the need for constant human monitoring and step-by-step intervention. Models have also become better at coordinating multiple agents, making it practical to organize and schedule work across sessions. People's roles are gradually shifting from low-level execution toward high-level decisions and approvals. 🚀

"People's roles are gradually shifting from low-level execution toward high-level decisions and approvals."

However, mainstream agent designs struggle to support this way of working across multiple tasks or an entire team. They still use the single session as the basic unit of work, and sessions remain isolated. When users run several tasks at once, they have to switch between sessions manually and remember the contents of each. In our experience, one person can usually track only three to five active sessions simultaneously. In other words, model capability limits an individual task, but human attention limits multitasking. 🤯

Adding a CLI or external connectors to a local, single-session agent so it can receive outside messages does not remove this fundamental limitation. It still runs as a single synchronous session, blocks on long tasks, mixes contexts from different tasks, and stops entirely when the local device goes offline. Keeping such a system running requires substantial manual effort.

2. The Super-Agent Concept and Its Characteristics

Overcoming these limits requires decoupling the agent from a manually controlled single session. Instead, it should be a continuous entity that preserves context across sessions and handles multiple complex tasks concurrently without interference. We call this kind of agent and its system architecture a Super-agent. ✨

For example, our internal Super-agent instance running on DeepSeek Harness can continue the same development task across IM and GitHub. It also monitors feedback in public group chats, identifies root causes on its own, and opens pull requests to fix them even when nobody mentions it. Remarkable, isn't it? 😮

"Our internal Super-agent instance can continue the same development task across IM and GitHub." "Even when nobody mentions it, it can identify the root cause on its own and open a pull request to fix it."

The same task continues across an IM group chat and a GitHub pull-request review.

The agent monitors a public group chat and opens a pull request to find and fix a bug without being mentioned.

We believe a Super-agent has four fundamental characteristics:

• Continuous: Users interact with it where they already work, such as IM chats or GitHub comments, and it always feels like one agent. They do not have to wonder whether information Y is in session X. If a user requests plan A in IM and later switches to plan B in a GitHub pull-request comment, the agent understands the change and adjusts.
• Productive: It responds quickly and completes multiple complex tasks concurrently to a high standard. It can receive the next instruction before the previous command or task finishes.
• Proactive: It does not wait for step-by-step instructions. It monitors environmental events, acts on anything worth addressing, and otherwise stays quiet.
• Persistent: It remains online, connects directly to the user's real working environment, and automatically recovers from anomalies during long-running operation.

A single ReAct—reasoning and acting—loop cannot deliver all four, so these characteristics must come from the system architecture. Similar design constraints tend to produce similar architectures. When the goal is an always-online system responding concurrently to environmental events, we expect personal agents and agents for commercial work such as software development to converge on similar designs. Building these systems resembles many long-studied problems in computer systems, so many classic design ideas from that field apply.

Implementations will vary, but we see a basic framework of five modules supporting these four characteristics.

Overall Super-agent architecture.

• Two-tier architecture (Section 2): Provides both continuous interaction and productive concurrency.
• Event-driven design (Section 3): Makes the agent proactive.
• Full-duplex, multichannel interaction (Section 4): Keeps each user interaction continuous and productive.
• Separation of compute, state, and environment (Section 5): Keeps the agent persistently online across devices.
• Watchdog (Section 6): Helps it recover automatically from anomalies.

3. Two-Tier Architecture: Router and Worker Layers

Supporting continuous interaction across channels and productive concurrency across tasks requires addressing a fundamental tradeoff between continuity and throughput in how the system organizes sessions.

Routing all events to one session gives the most continuous context because that session sees everything. But a ReAct loop executes one step at a time, limiting how quickly one session can work, lengthening tasks, and reducing throughput. Intermediate details from different tasks can also mix within one context and lower output quality. 😥

Giving every event a fresh session reverses the tradeoff. It maximizes concurrent throughput, but when tasks are not fully independent, a lack of shared global context can produce disconnected results. Multiple sessions replying separately to the user can also make interaction confusing.

To obtain both continuity and throughput, we can divide work into two layers. A long-running router layer handles all human interaction and global coordination, preserving global continuity, while a context-isolated worker layer executes tasks with high concurrency.

Two-tier architecture: the router layer handles all routing and external interaction, while multiple isolated worker sessions execute tasks concurrently.

With this architecture, the system handles context management and concurrent execution. Users can always work with the same Super-agent while barely thinking about sessions. Making users manage sessions themselves is largely a design habit inherited from low-level LLM APIs. Sessions should be implementation details, not mental burdens for users. 👍

In traditional designs, sessions serve two purposes: managing model context and acting as the user's project-management unit. Once the product is decoupled from the underlying sessions, project management no longer has to follow session boundaries. What interaction and task-management experience to offer becomes a separate product question, which we revisit later.

These tiers are logical divisions of responsibility. Neither layer must be implemented as a single session; each can have its own internal structure. The next two subsections describe them in turn.

3.1. Router Layer

The router layer is a long-running global routing layer that receives human interaction from every entry point. All cross-task information and decisions converge here, making it the system's global sequencing point, coordination point, and memory. To prevent this single global node from becoming a performance bottleneck, it is not designed to execute tasks itself. It only interacts with humans and dispatches work, and can run without a Bash tool.

This arrangement of one central node dispatching work to several execution nodes resembles a conventional agent team, but their focus differs. Agent teams usually break a complex task into stages and coordinate the roles responsible for them. Because those stages are tightly coupled, a team leader often needs deep understanding to plan subtasks and frequently coordinate members, creating considerable reasoning overhead. In a Super-agent, the router simply dispatches tasks and tracks their relationships at a high level. It does not decompose individual tasks.

Conversely, an agent team can operate as a two-tier architecture if its prompts prevent the main session from doing work itself and restrict it to external interaction and dispatching to members that independently handle individual tasks. In our experience, routing is simpler than expected, and a lighter model can provide both speed and quality.

Internally, the router layer need not be a single session, and some logic may not need an LLM at all. We chose the most direct design—a single long-running LLM session—and found it less likely to become a throughput bottleneck than expected. Environmental events, or the triggers in Section 3, arriving during one reasoning turn queue up and are processed together in the next: batching. Handling events together adds little overhead.

• When external events arrive at a steady rate, triggers reach the router session individually and responses return quickly.
• When events arrive in bursts and queue up, triggers accumulated during the preceding turn are automatically merged and injected together into the next LLM call. Because the router performs only lightweight interaction and dispatching, each step generally has a long input and short output. Triggers merged into one LLM API call are computed in parallel during prefill, so time per request grows much more slowly than batch size. Up to a point, a larger backlog therefore lowers amortized inference time per decision. That limit depends on context length and how many triggers the model can correctly handle in one turn.

Section 7.2 quantifies this batching effect experimentally. Combined with subscription and pass-through (Section 3.2) and Chain of Recall (Section 3.3), a single long-running router session preserves continuous context and already suffices for our current team size.

If the system grows beyond what one session can handle, the router layer could use internal multistage filtering or horizontal sharding across sessions. Its internal design would then face the same continuity-throughput tradeoff. Finer sharding increases concurrent throughput but reduces shared memory and context between shards. This tradeoff will remain until the global-memory problem is solved.

3.2. Worker Layer

The worker layer consists of sessions that execute tasks. Each worker has an isolated context, all execution tools, and responsibility for one task. Because workers directly determine output and code quality, they generally need the most capable model.

Workers do not interact directly with humans. Their reasoning and tool calls stay out of external channels. Instead, each reports its status to the router, which handles all user-facing replies. This preserves concurrency and output quality without the confusion of multiple sessions replying separately.

When tasks run concurrently, each worker does its own work, and peers usually need not communicate directly. Conflicts tend to arise in a shared working environment, such as the same pull request. As long as the relevant workers subscribe to that environment's thread, they receive the same event notifications (Section 3.2) and can detect and resolve conflicts themselves. The router mediates the few cases requiring cross-task coordination.

Like the router layer, a worker need not internally be one session. For complex work, it can spawn subagents or itself be an agent team, transparently to the upper router layer. The same structure supports code collaboration: independent work such as issue reproduction, PR review, and feature development can proceed concurrently without interference. It also suits personal agents. Even if the personal agent offers just one chat page, users can discuss several topics there while the page maintains conversational continuity. Meanwhile, the backend dispatches separate workers for each topic to do the work and draft answers in parallel.

4. Event-Driven Design: Making the Agent Proactive

To make a Super-agent proactive, we must first change what drives the system. Its primary inputs are no longer prompts typed one by one into a session, but semistructured events from the environment. In a Super-agent, we call group-chat messages, emails, calendar notifications, code-review comments, CI results, and similar events triggers. Because the agent listens and responds to triggers, it need not wait for a human command before every execution, as a single-session agent does. 🙌

The following subsections divide the journey from an event's arrival to its handling into four stages.

4.1. Two-Stage Filtering: Removing Noise

Once connected to real group chats or code platforms, the system sees a noisy event stream with a low actionable-trigger rate. Most everyday messages require no agent action. Asking a large model to judge every event from scratch would add excessive latency and consume too much compute. 😥 Borrowing the computer-systems idea of a fast path and slow path, we treat large-model inference as a flexible but expensive slow path. Frequent, well-defined, stable decisions can instead become deterministic code, providing a low-latency, low-cost fast path.

The system therefore filters all incoming events first. Deterministic policies remove noise before calling a large model, and only candidate events requiring semantic understanding reach the model. We use two-stage filtering combining programmatic policies and a large model.

• Programmatic policies (fast path): Code performs quick admission checks against deterministic conditions such as event source, group, and user or bot allowlists. Each source might be configured to "respond only to explicit requests," "treat as candidate events," or "ignore." These checks eliminate most irrelevant messages before model invocation.
• Semantic policies (slow path): Candidates passing the programmatic checks go to an LLM, which decides whether to act based on context and policies expressed in prompts. This stage also acts as a natural-language extension point, letting humans enable, disable, or add policies through prompts at any time.

Two-stage filtering: programmatic policies first remove most irrelevant messages; semantic policies judge the remainder.

4.2. Subscription and Pass-Through

The global router layer in Section 2 preserves interaction continuity across channels. But routing every follow-up event for an assigned task through it could overload this single global node and slow responses. The fast/slow-path split therefore also applies to routing filtered events. The router handles only cold starts for new tasks and cross-task coordination, while code passes follow-up events directly to the owning worker session.

In real workflows, successive events on the same GitHub pull request, IM topic, or email chain form an event stream called a thread.

Thread examples: successive triggers under the same IM topic or GitHub pull request form a thread.

When the router creates a worker for a thread's first event, the worker directly subscribes to that thread. Subsequent routing follows one of two paths:

• Subscribed (fast path): Code delivers subsequent events directly to subscribed workers, so the router no longer needs another tool call to forward them. If an event falls outside the current task, the worker unsubscribes or sends it back to the router for redispatch.
• Unsubscribed (slow path): The router still sees all events and can track global state, but evaluates and dispatches only new events that have no subscriber yet.

Subscription and pass-through: the initial event goes through the router to create a subscribed worker; subsequent events in the same thread go directly to it.

Subscriptions between threads and workers are many-to-many. A worker can subscribe to several related threads, and a thread can have several subscribed workers. When workers overlap in an environment or discussion, every new event in the shared thread is delivered directly to all subscribers simultaneously. Workers can then see what others are doing and resolve conflicts themselves without direct communication. On the output side, workers still report key conclusions to the router, which handles every user-facing reply and synchronizes global memory.

4.3. Inline & Spill and Chain of Recall

Once an event has been filtered and routed to a target session, the next question is how much information to put into the model's context window. Inputs are no longer a limited set of human prompts but a continuous flow of semistructured environmental events, making tool-call and event-injection design more important. Inject too much and the window fills, distracting the model. Inject too little and the model must repeatedly call tools for context, adding execution steps. Wasting the context window means wasting model intelligence. 😥

We can therefore treat the limited context window as a cache. Using terms borrowed from compiler optimization and computer systems, context injection comes down to two basic operations:

• Inline: Put information likely to be needed soon directly into the current context window, reducing extra tool-call round trips.
• Spill: Keep the full information outside the window if it exceeds the budget or is rarely used. Leave only a reference or summary inside, so the model can retrieve the full content on demand.

Combined with the classic systems concept of locality, Inline & Spill can improve event injection and tool calls step by step.

1. Start with minimal information: Initially give the model only the current object's ID and a summary of its contents.
2. Gradually inline related information through locality: Inline what the model is likely to need soon, starting with IDs of closely related objects, then adding spatially or temporally adjacent content. Examples include the first 50 characters, surrounding IM messages and the message being replied to, or neighboring comments in the same code-review discussion.
3. Spill content beyond the limit: Set a small length limit for content too long to inline in full, and spill the excess outside the window. One simple approach is to truncate it and leave a pointer where it continues, allowing the model to call a tool to read the rest if needed.

The router has a context problem of its own. Many follow-up events pass straight to workers, while past work accumulates during long-running operation, so the router cannot keep the complete history of every task in its window. Yet if a user mentions an old task in another channel, it must recover that context. Applying Inline & Spill consistently to all kinds of system objects provides Chain of Recall, an on-demand, multistep retrieval mechanism that reduces how much earlier information the router loses over time.

Chain of Recall: each retrieved object inlines IDs of next-step objects, allowing context to expand step by step along references.

The system assigns unique IDs to objects such as triggers, threads, and worker sessions. When injecting an object, it inlines IDs of closely related objects, connecting them into a reference graph. Objects retrieved through tools also follow Inline & Spill, so their results inline summaries and IDs of next-step objects. Starting from the current event, the model follows these references to retrieve as much context as necessary, one step at a time.

For example, it may begin with the current message's thread, follow an inlined ID to a related worker session, and then find another code-review thread linked to that worker.

4.4. Speculative Execution

We also borrow speculative execution from computer systems. Based on environmental signals, the agent starts work in the background before knowing whether the result will be used. Extra background compute reduces people's waiting time and the number of interventions required. Useful results are delivered; the rest are discarded. 🗑️

For a personal agent, an incoming meeting invitation or to-do message could prompt background checks for calendar conflicts, collection of relevant information, and drafting a response. The user then only has to review and send it. The same approach applies to R&D collaboration. In our internal DeepSeek Harness user group, for example, we configured a "quietly reproduce and fix" policy. When someone reports a problem or discusses a proposed change, the agent first tries to reproduce the issue and find a fix in the background. It delivers results only after confirming the problem and finding a straightforward fix. Otherwise, it remains quiet throughout. 🤫

"While the group was discussing solutions, the Super-agent had already opened a pull request with a fix in the background."

Speculative execution example: while the group discusses solutions, the Super-agent has already opened a pull request containing a fix in the background.

5. Full-Duplex, Multichannel Interaction

The two-tier architecture in Section 2 preserves context continuity across channels. But making everyday interaction continuous and productive requires addressing two more questions: how interaction happens and where it happens. First, time-consuming background work must not obstruct foreground conversation. An asynchronous ReAct loop lets a session receive new instructions at any time without waiting for earlier commands or tasks to finish (Section 4.1). Second, responses must adapt their content and detail to each communication channel and how people communicate there (Section 4.2).

5.1. Asynchronous ReAct Loops

In a classic ReAct loop, a synchronous run() tool call blocks the loop until the tool finishes and returns its final result. Until then, the session cannot respond to anything new from the user. Removing this blocking requires moving conversation from turn-based, half-duplex operation to full-duplex operation.

Classic versus asynchronous ReAct loops: an asynchronous call immediately acknowledges that it has started, while the session can respond to new messages as the tool runs in the background.

We replace time-consuming command and tool calls with asynchronous start() and stop() calls, producing an asynchronous ReAct loop. A start() call immediately returns "started," so the loop does not wait for the tool. When the background tool finishes, the system delivers its final result to the session as a new event message. Depending on the context, the model may also call stop() to terminate a command that has run too long.

With foreground conversation decoupled from background work, the agent can respond to people while time-consuming tasks continue. New input is handled as soon as the current reasoning step ends, rather than after a background tool finishes.

DeepSeek Harness already implements this asynchronous mechanism, though it is not enabled by default yet.

5.2. Adapting to Multiple Channels

People communicate differently in group chats, email, and GitHub discussions. An agent must adapt both its level of detail and response style to each channel. Detailed reasoning and tool-call logs may suit a single-user terminal, but posting them unchanged in a group chat can overwhelm participants. 🤯

The Super-agent's two-tier architecture already addresses part of this: detailed task reasoning and frequent tool calls remain within worker sessions instead of flowing directly into external channels, and the router handles all external interaction. In addition, the system must connect to users' everyday work environments and use prompts to define each channel's communication norms.

• IM and other instant-messaging channels: Keep communication lightweight and interrupt people as little as possible. Like a human colleague, notify people only when a decision or approval is needed, ask direct questions, and provide brief conclusions. One simple rule we found effective is a limit of 100 words per response.
• Asynchronous channels such as GitHub, email, and documents: Provide structured, information-dense output. When creating or updating a pull request, for example, include the full problem background, change description, and validation results according to the project's conventions. In personal-agent scenarios, directly draft structured emails and document summaries.

6. Separating Compute, Storage, and Execution Environments

A local agent normally bundles three things on one device: the compute running the agent loop, the session state that must persist, and the execution environment, such as code repositories and local toolchains. If the device sleeps or goes offline, the agent stops, and it cannot access environments on other devices. To keep a Super-agent persistently online and connected to the real environments its tasks require, we borrow compute-storage separation and decouple these three things in two stages.

6.1. Separating Compute from Session State

First, separating compute from session state frees the agent from a single machine's lifecycle and lets it remain persistently online in the cloud (Section 5.1). The compute running the loop can be stateless; only session state needs to persist. This first level therefore runs compute in stateless, elastic cloud containers, while keeping sessions and other persistent state in a database. Containers can scale, restart, or be replaced, while persistent storage preserves task and session continuity. A local device sleeping or going offline no longer interrupts the agent, which remains online in the cloud. ☁️

6.2. Separating the Cloud Agent Loop from Execution Environments

With the loop and session state in the cloud, the next question is how the agent reaches the execution environments its work requires. Much of the model's working context comes from tool calls into repositories, local files, dependent services, and other environments. Broadly defined, context includes the execution environment itself.

There are two common approaches. One starts a cloud sandbox, fetches code, and rebuilds and synchronizes the environment. But real working environments often contain uncommitted local changes, private credentials, intranet-service dependencies, and specific hardware or toolchains. Synchronizing all of that is expensive and easy to get wrong. The other asks users to abandon their local environment and move their work to the cloud—a migration too costly for many. 🙅‍♀️

The environment is precisely the part that is difficult to copy and synchronize, so it need not move to the cloud with the agent loop. The second level of separation keeps the loop in the cloud and leaves the state-heavy execution environment in place. Each endpoint needs only a lightweight daemon that maintains no session state and simply executes commands and returns results. The environment stays outside the cloud; the agent reads context from it as needed.

Anthropic's research takes the same approach: the harness remains stateless, session logs are stored externally, and execution environments are attached on demand through a unified interface. The difference lies in the target scenarios. Anthropic's document describes a managed service, primarily discussing on-demand sandboxes and resources inside customer VPCs. We first need to connect people's everyday personal devices, which retain uncommitted changes and local credentials and may be online only intermittently. Our design therefore supports BYOM—Bring Your Own Machine—connecting users' development devices or personal computers to cloud agents. It also supports cloud-hosted machines and compute environments created on demand.

The agent is consequently no longer bound to one machine. It can switch execution devices, running commands and reading context wherever the task requires. It can even work with intermittently connected devices. When a user's personal device reconnects, the cloud agent automatically starts and completes tasks that need to run there. The diagram below shows the resulting two-stage separation of compute, persistent state, and execution environments.

Compute-storage separation and decoupled execution environments: in the cloud, the agent loop is separate from persistent state and accesses different execution environments through endpoint daemons as needed.

7. Watchdog: Maintaining Persistent Online Operation

The compute-storage separation in Section 5 is not enough to remain persistently online. The system must automatically recover from anomalies during long-running operation. An always-online distributed system is unlikely to remain stable for long if it relies solely on its own internal logic. It needs an independent control loop outside the main system.

Agent systems also need more than conventional process-liveness probes or monitoring scripts. Many anomalies are not crashes: the process may still be running while the model is trapped in an unproductive loop or has drifted from its goal. Long-running agent systems must therefore monitor task progress, not just infrastructure liveness.

Our external control loop is an independent watchdog session, running outside the main system and driven by scheduled messages. It handles infrastructure failures such as API errors and failed state recovery. It also uses a model to judge whether each worker is making meaningful progress or drifting from the overall goal. It corrects anomalies promptly and keeps checking until temporary external failures are resolved.

Because the watchdog is itself an agent session with a complete toolset, administrators can ask in natural language why a problem occurred. They can also have it modify the main system's behavior while it runs—for example, adding or removing prompts or adjusting trigger rules. 🐕‍🦺

8. Experimental Results

We conducted preliminary experiments on the core scheduling and routing design at two levels: the whole system and the router layer alone. The end-to-end experiment compares the two-tier architecture with a single-session design and measures subscription and pass-through (Section 7.1). The second tests router-layer batching (Section 7.2). These use synthetic workloads and simplified environments, and parts of the setup could be more rigorous, so the results below are only indicative.

8.1. End-to-End Performance Comparison

Four end-to-end designs ran concurrently, driven by group-chat and GitHub CI message streams. Each run contained about 300 messages, roughly 20 of which were task requests. The rest were casual chat, follow-ups, cancellations, and CI messages. Coding tasks were simulated by tools that merely consumed time, so the experiment measures scheduling and coordination, not the system's ability to execute individual tasks. Each design ran five times.

The four designs were:

• Super-agent
• Super-agent without pass-through
• A single session with a subagent tool, using two different prompts:
  • Neutral prompt: "Use subagents when appropriate..."
  • Delegation-first prompt: "Every message in the chat reaches you, so work you execute yourself is continually interrupted by new messages. Prefer delegating each task to its own subagent, and do only small things yourself..."

Cumulative task-request arrivals and completions for the four designs, averaged over five runs. Message intervals and task durations were scaled down to one quarter; model-call durations were not scaled.

Note: Each design ran five times. Completion time is measured from task request to result message.

Super-agent completed tasks in 12.4 minutes at p50 and 15.7 minutes at p95, substantially faster than the single session with a subagent tool. In this experiment, the single-session design slows down because it depends heavily on its prompt. The main session often chooses to do work itself, producing long, unstable completion times. With the neutral prompt, the model never called a subagent across the five runs. Every task ran in the main session, repeatedly interrupted by new messages, bringing p95 to 29.5 minutes. With the delegation-first prompt, the model delegated in four of five runs. Completion times improved somewhat but remained longer overall than Super-agent's. In the remaining run, the model judged the work "small" and did it itself, producing the purple long tail in the figure. A single session relies on prompt engineering and the model's immediate judgment to decide whether to delegate. The two-tier architecture mitigates this at the system level. The router never executes tasks itself, and each worker receives messages only from subscribed threads.

Maintaining several independent sessions means Super-agent uses more cache-read tokens per run than a single-session design: a tradeoff of tokens for shorter, more stable completion times. Super-agent without pass-through finished in nearly the same time, but the router made about 30% more decisions per run and total cache-read tokens increased by roughly 37%, from 23.2M to 31.8M. Thus, for this workload, pass-through did not complete tasks faster or better, but substantially reduced router-session token usage and reasoning overhead.

8.2. Router-Layer Batching

To determine how much load one long-running router session can handle through the batching described in Section 2.1, we stress-tested the router layer alone. The router called a real model while workers used mock models. We progressively increased the arrival rate of decision-requiring triggers from roughly one to about 40 per minute. At each rate, we measured average batch size, time per request, and amortized inference time per decision. A decision may span several LLM requests because the router can reason across multiple steps or retrieve context through tools before dispatching. Time per decision can therefore exceed time per request.

Router-session batch size, time per request, and amortized inference time per decision as a function of trigger arrival rate.

As the figure shows, when decision-requiring triggers increased from roughly one to 40 per minute, average batch size rose from 1.0 to 2.8. Time per request increased only from 2.5 to 3.9 seconds, more slowly than batch size, so amortized inference time per decision fell from 6.4 to 1.6 seconds. When external events arrive in bursts, the router automatically merges queued events and increases effective throughput. Batching also explains the results in Section 7.1: removing pass-through increased peak router load, but the single router still did not reach its throughput limit. At our current team size, there is therefore no need to shard the router prematurely at the expense of global context continuity.

9. Future Work

Sections 2 through 6 describe the five modules comprising Super-agent's basic architecture. The experiments in Section 7 show that its core scheduling and routing mechanisms work when many tasks run concurrently. The system remains relatively simple because, at this stage, we have simplified both engineering design and supported scenarios. Beyond these simplifications, open questions remain in four areas.

9.1. Scaling the Two-Tier Architecture

So far, a simple combination of one long-running router session, subscription and pass-through, and no direct worker-to-worker communication has handled most everyday work at low engineering cost. The right structure for each layer remains unsettled when tasks become too large and tightly coupled for one router session. More scenarios need testing to determine when and how finely to shard the router, and when peer workers should communicate directly and through what collaboration topology. 🧪 Co-designing systems and models is another promising direction. Training models specifically for router tasks such as event judgment, batch dispatch, and context retrieval could further improve throughput and decision quality.

Memory also limits scaling. A long-running router with Chain of Recall primarily handles on-demand retrieval of recent tasks and session histories. Once the system runs for months or longer, long-term memory will become a major bottleneck.

9.2. Sessionless Agent Work

The two-tier architecture hides multisession management from users, so sessions cease to be the central concern of product design. But when underlying execution sessions no longer map directly to conversations in the interface, new questions emerge: how should work be presented, and what forms of interaction and project management feel natural? We believe chat windows became central partly through path dependence. More interaction could move into domain-specific interfaces, as with our Super-agent instance working directly in GitHub issues and pull requests. Sessions may remain in interfaces because users are familiar with them, but one visible conversation need not correspond to one underlying session.

Earlier sections focused mainly on human interaction at task initiation and approval. Yet during this transition, with models improving rapidly, many tasks still require human intervention midway through. It is worth exploring designs that let users intervene step by step in key details without losing the efficiency of autonomous background work. For example, users could intervene, take over, or work with an agent live at any point during background execution. 🤝

Overall, project-management and interaction needs vary greatly by domain and personal style, so final designs will likely be highly customized. DeepSeek Harness's open architecture makes such customization easier.

9.3. Context Boundaries and Agent-to-Agent Communication

So far, we have discussed a single Super-agent instance, assuming all information within its scope gathers into one global context. As use expands from individuals and small teams to large organizations, provisioning Super-agents becomes a question of which contexts to share and which to isolate. Organizational units needing shared context share one instance; each unit requiring isolation gets its own.

Once isolated instances exist within or across organizations, collaboration across boundaries becomes agent-to-agent, or A2A, communication—for example, between each member's personal agent and a team's shared Super-agent. Here, A2A means agent-to-agent communication in general, not a specific protocol. We still need to solve how agents with no shared underlying context and different permission boundaries can communicate and collaborate safely and reliably.

9.4. Security and Privacy

The event-driven design in Section 3 allows a broader environment to drive the agent, but also exposes it to more untrusted inputs. Without adequate security and privacy, a Super-agent can operate only within a very small, trusted scope. 🔒

For example, the design in Section 5 puts the agent loop in the cloud and a lightweight daemon on execution devices, implicitly assuming mutual trust between cloud and endpoint. Yet the cloud-hosted loop continually receives external events, while endpoints hold private code, sensitive data, and local credentials. Connecting them creates substantial security and privacy risks. If a server intrusion or prompt injection compromises the loop, every connected endpoint device could be taken over. 🚨

Credentials can leak even without a compromised cloud. As long as endpoint credentials can enter the model's context, they may be exposed during normal execution. Agents therefore need ways to use credentials without seeing them. Wider adoption of this architecture requires solving these security and privacy issues while preserving the ability to retrieve context from diverse environments.

Conclusion

Rather than proposing a new theory, this design applies classic computer-systems engineering ideas to agent systems. Specific implementations will change as technology advances, but we believe the underlying design ideas will remain useful longer. Our internal Super-agent, built on these ideas and DeepSeek Harness, already runs continuously. Every day, it helps reproduce and fix issues, respond to code reviews, and develop DeepSeek Harness itself. 😊

As noted at the beginning, large models need progressively less human intervention on individual tasks, shifting the bottleneck for further productivity gains toward human attention. The two-tier architecture, event-driven design, asynchronous multichannel interaction, compute-storage separation, and external watchdog work together to let the system handle tedious tasks such as session management and context synchronization. People can then move away from execution details toward higher-level decisions and approvals.

An agent built this way is no longer a chat window waiting for instructions. It becomes an autonomous collaborator that stays online in the digital environments people use. For individuals, it can be a personal agent helping with everyday tasks across devices. For teams, it can become part of the R&D workflow, taking ownership of tasks and moving them forward. As models and system architectures develop together, we believe this more autonomous way of working can become the standard for human-agent collaboration. 🚀