Always-On AI Agents: The Router and Worker Architecture Behind Muse, Dots, Duet, and DeepSeek

An always-on AI agent is an agent that runs on its own cloud computer, reacts to events, and works without a prompt. Four large AI companies shipped one in 2026, and DeepSeek published the architecture with open code. The shared design has two levels. A long-lived router talks to people and dispatches work, and isolated workers each own one task.

What the Four Products Have in Common

The products target different buyers, but the design choices are almost the same.

• Google Gemini Spark was announced at I/O on May 19, 2026, as a 24/7 personal agent on Google Cloud virtual machines, according to GIGAZINE.
• Meta Muse launched on September 8. Meta says it runs on a dedicated virtual machine that holds the agent and the user's data, and it asks for approval before sensitive actions.
• OpenAI Dots launched at DevDay on September 29. Each Dot has its own cloud computer. Users reach it in ChatGPT, Slack, or Teams. A monitoring system can pause or stop a Dot over a safety concern, SiliconANGLE reports.
• Anthropic Claude Duet entered preview on October 21 for professionals and small business owners. It has its own virtual machine and gets approval before it sends a message, pays, signs, or deletes, MacRumors reports.
• DeepSeek shipped no product. It published a design paper, the MIT-licensed DeepSeek Harness runtime, and a Super-agent prototype.

The closed products show the behavior from the outside. The DeepSeek code shows the inside. The rest of this article uses that code as the case study.

Why One Chat Session Is Not Enough

The DeepSeek paper starts from a limit on people, not on models. A person can follow about 3 to 5 active agent sessions at once. Single tasks are limited by the model, but parallel work is limited by human attention.

An always-on agent receives a stream of events. An event, which DeepSeek calls a trigger, is a chat message, a code review comment, a CI result, or an email. One session that sees every event keeps full context. However, it works one step at a time, and new events interrupt it. One new session per event gives speed, but the results are disconnected and many sessions reply to people.

The paper's answer has two levels:

1. A router is one long-lived session. It receives every event, talks to people, keeps the global memory, and dispatches tasks. It does not do the tasks.
2. A worker is one session per task, with its own context and a full tool set. Workers report to the router. Only the router replies to people.

Anthropic's Managed Agents design makes a related split. The harness stays outside the container, and session state is stored outside the harness. DeepSeek cites it and adds one difference. DeepSeek also wants to reach personal machines that hold uncommitted code and local credentials.

What the Experiments Show

The paper's tests use synthetic workloads, and the authors call the results indicative. Two results are useful for any team that builds agents.

A prompt does not make a session delegate. DeepSeek gave one main session a subagent tool. With a neutral prompt, it did not delegate in any of 5 runs. It did all work itself, new messages interrupted it, and p95 task time reached 29.5 minutes. With a prompt that pushed delegation, it delegated in 4 of 5 runs. In the fifth run it judged the work "small" and did it itself, which caused the long tail.

The two-level design costs more tokens because it runs more sessions. Pass-through means that the code sends follow-up events on a thread straight to the worker that owns it. Without pass-through, the router made about 30% more decisions.

The token increase without pass-through is 31.8 / 23.2 = 1.37, or about 37% more. Pass-through did not make tasks faster in this test. It made the router cheaper.

One router can handle more load than expected. Events that arrive during one model call wait and go into the next call together. Router calls have long inputs and short outputs, and the model reads a long input in parallel. So a larger batch adds little time.

When the event rate rose from about 1 to about 40 per minute, the time per request rose from 2.5 to 3.9 seconds. The time per decision fell from 6.4 to 1.6 seconds. A busy router becomes more efficient per decision, up to the limit of its context and accuracy.

What the Open Code Actually Does

The prototype has about 12,400 lines of TypeScript in src/ and 60 test files with about 920 test cases. It is a plugin bundle for DeepSeek Harness 0.2.1-alpha. The harness has about one million lines of TypeScript in 58 package groups. Every part of it is a plugin on Cordis, a framework that DeepSeek and Peking University researchers describe in a paper on composable software. A plugin can be added or removed while the system runs. This review reads the code at commit 6337fc8. It does not run it. The README states that some designs in the paper are future work.

Parts that match the paper

• The router and worker split is enforced by tools. The main session gets routing tools, such as orchestrator_route and orchestrator_reply. Each task gets its own worker session and directory, with report tools only. Workers cannot reply to people.
• The domain model is small. Triggers arrive from sources, such as GitHub and Feishu. Triggers land on threads. An accepted request becomes a ticket, with a mandate that records why it was allowed. Workers subscribe to threads, and later triggers on a thread go to its subscribers.
• The engine is strict. The core does no input or output. One Engine class is the only writer of tickets and threads. Each command runs in one SQLite transaction. Side effects, such as launching a worker or sending a reply, go into a durable queue and run only after the commit. A rolled-back decision cannot send a message (see FIG 02).
• Batching is in the engine. The evaluateDue pass starts one evaluation per thread and adds every trigger that arrived in the meantime.
• Filtering has two stages. A fast table in src/admission.ts sorts each message by sender (listed or not) and address (the agent is mentioned or not). A prompt and team-written rules then judge the remaining candidates.
• Long content is cut, not dropped. An assessment window holds the first 5 thread messages and 5 on each side of the trigger. Long messages are cut and labeled with their full length. The model reads the rest by ID when it needs it.
• Background work uses a short timeout. The paper describes asynchronous start and stop tools. In the prototype, both session presets move any shell command to a background job after 5 seconds. The job's end wakes the session with its result.

Parts that are not in the prototype yet

• There is no Watchdog. The paper's Watchdog is a separate agent that checks whether workers make progress or drift from the goal. The prototype tracks health and retry counts, which is liveness, not progress.
• It is one process. State is one SQLite file, and the runtime locks its directory. The paper describes stateless cloud containers.
• There is no remote machine daemon. Workers run on the host of the plugin. The harness has SSH file and process packages, which can support remote work later.
• GitHub is polled. The GitHub source polls notifications, at least 60 seconds apart.
• The router has a shell. The paper says the router can run without Bash. The router preset in the prototype includes a shell with the 5-second limit and file reads. A prompt forbids it to use the shell to bypass its tools. The paper's own test shows the risk of rules that only a prompt enforces.
• Proactive work starts off. Work that nobody requested needs the auto mode. The default is observe, which only records what the agent would have done.

The Hard Problem Is When Not to Act

The prototype's philosophy document sets one rule for the whole project. The agent must use as little human attention as possible and give as much value as possible. The agent acts only when asked or when a written team rule allows it. It confirms once, stays quiet while it works, and writes again only with a result, a question, or a failure. Chat replies have a hard word limit.

The prompts total about 5,000 words. The largest file, the admission prompt at about 1,250 words, is mostly about when not to act. It gives worked cases:

1. "This button label is odd," followed by "just 'Save' would do," is a request with a settled target. The agent accepts it.
2. "Maybe our app should show unread counts like theirs" is a preference. The agent ignores it.
3. "This banner looks different from the other cards" is a design opinion. It does not allow a restyle.

Each acceptance must record three facts with quotes from the source. The discussion is about this project, someone wants a specific change, and the direction is settled. If intent is not clear, the agent stays quiet and waits for more messages.

The closed products face the same problem. Dots, Muse, and Duet all decide what deserves action from a noisy stream of messages. DeepSeek spent more prompt text on that decision than on any other part.

Security Controls in the Prototype

The paper states the open problem directly. Untrusted events now drive the agent, so a prompt injection can reach machines and credentials. The prototype does not solve this, but its controls are careful. See the OpenNash guide to prompt injection in AI agents for the general threat model.

The harness is clear about one limit. The README of its local credential store says the store cannot isolate secrets from the agent, because tools run as the same OS user. An agent that uses a credential without seeing it is still an open problem for every vendor. The OpenNash guide to the agent kill switch covers containment when an agent goes wrong.

The Harness Is Separating From the Model

DeepSeek Harness includes packages that run Claude Code and Codex as workers. The Claude Code subagent package runs each delegated task as a fresh, unattended Claude Code session. Only the final answer returns to the parent.

The router and worker split makes this mix easy. The paper says a lighter model is often enough for the router, and workers need the most capable models. Nothing requires both models to come from one vendor. Muse, Dots, Duet, and Spark each combine one vendor's model, computer, and app. DeepSeek bets on an open harness where the worker is the best model for the task. The OpenNash post on the bitter lesson for AI agents discusses which harness parts last when models improve.

How One Event Moves Through the System

This example follows one message through the prototype design. It is a hypothetical case.

1. A listed engineer writes in a team chat thread that a settings page label should read "Save."
2. The fast table classifies the message. The sender is listed, and the agent is not mentioned, so it becomes an inferred candidate.
3. The router reads the thread window and checks the enabled rules. It records the three facts with quotes.
4. If the mode is observe, the router records "would accept" and does nothing else.
5. If the mode is auto, the engine creates a ticket, a mandate, and a worker in one transaction. The acknowledgement goes into the outbox.
6. The worker subscribes to the chat thread, edits the code, and opens a pull request. The ticket now follows the pull request too.
7. A reviewer comments on the pull request. The comment goes straight to the worker, not through the router.
8. The worker reports ready. The router posts a short result in the chat thread. The ticket ends when the pull request merges or closes.

When This Architecture Is the Wrong Choice

The two-level design adds sessions, tokens, and moving parts. It is the wrong choice in these cases:

• One person runs one task at a time. A single session with full context is simpler and uses fewer tokens.
• The tasks are tightly coupled. One feature split into steps needs a planner that understands the task deeply. That is an agent team, not a router.
• The events are rare and always explicit. If every request is a direct command, the filtering layer gives little value.
• There is no tolerance for unrequested action. Keep the agent in a record-only mode, or do not connect it to shared channels.

What to Copy Into Your Own Agent System

These steps apply to any always-on agent, built in-house or on a platform.

1. Remove execution tools from the coordinator. Do not depend on a prompt to stop it from doing the work.
2. Write the "when not to act" policy first. Include worked examples from your domain, and require quoted evidence for each proactive decision.
3. Start every proactive behavior in a record-only mode. Review the "would have done" log before you enable action.
4. Put a hard limit on human attention. Set a word limit per channel, ask one question at a time, and stay quiet while working.
5. Send agent side effects through a transactional outbox, so a rolled-back decision cannot send a message.
6. Keep one coordinator until measurements show a limit. Batching makes it cheaper per decision as load rises.
7. Add a supervisor that checks progress, not only process health. The OpenNash guide to durable agents covers checkpoints and recovery for long tasks.

Bring an Always-On Agent Into Your Operations With OpenNash

An always-on agent saves time only when it acts on the right events and stays quiet on the rest. OpenNash puts forward-deployed engineers on your team and works with Fortune 2000 companies to build agents like this one.

1. Map your event sources (chat, email, tickets, code review) and define which events can start work.
2. Write the admission rules and the "when not to act" examples with your domain experts.
3. Build the router, the workers, and the outbox, with evals for each routing decision.
4. Run the agent in record-only mode, measure its judgments, and then enable action one rule at a time.
5. Add progress supervision, cost controls, and audit logs before you widen access.

At the end, you own the code, the prompts, the evals, and the policy rules.

Book a call with an OpenNash forward-deployed engineer or email us at hello@opennash.com. The first session finds the workflows where an always-on agent returns the most hours for each dollar of model cost.