DeepSeek Splits the Agent into Three Layers—and the Safest Move Is to Leave the Router Unarmed

A couple of days ago, DeepSeek published an exploration of Super-agent design. X user @antiAIvo turned it into an animated diagram.

The core idea in one sentence: the Agent shifts from waiting for instructions to staying online long-term and watching events itself.

The structure has three layers.

1. Events go through two filters first

Group chats, GitHub comments, CI results, and email/calendar events can all trigger it. The first filter uses programmatic rules for fast screening by source, group, and allowlist. The second is handed to an LLM, which decides whether to accept the event according to policy.

One commenter, @jimerrors, said the first programmatic filter is the key to saving effort. @Louis路易斯 added a practical boundary: their message listener only wakes the AI for messages from the boss, private chats, @-mentions of itself, and replies to itself; other messages in the group do not disturb it. Otherwise, a dozen AIs would all be woken by every message, and the quota could not bear it.

2. The Router stays resident and schedules

The Router is the only role that talks to humans. It is responsible for assigning tasks and remembering context across tasks. A lightweight model is enough, and it is not given Bash permissions. Bash permissions can be understood as the hands that can execute commands and touch files.

@jacker0214.eth said this is the most practical point: the only role that talks to humans has no knife in its hand, so even if it is tricked by a single message in a group, it cannot cause major damage. He also warned that as events increase, the token bill for the second LLM filtering pass will probably not be cheap.

The animated diagram also includes an IM reply module: generate a reply of no more than 100 characters within 100 seconds, which the Router forwards to the user. This constraint is very product-minded: first ensure replies are short and fast, and do not let the scheduling layer get dragged into long conversations.

3. Workers work in parallel

Each task gets its own independent session, equipped with a full toolset and a strong model. After taking over a PR, a Worker subscribes to that thread. Subsequent comments and CI results are sent directly to it and no longer pass through the Router.

@linyun believes that proactive event-driven operation is the real qualitative change for Agents, turning from a customer-service bot that passively waits for instructions into a daemon that quietly works in the background. @victor chen asked: if a task has already ended and someone follows up, can it continue running in the original session? This question is not flashy, but it determines whether a Worker can truly stay online long-term.

At the bottom of the animated diagram, one line says: storage, pagination, and execution are in the cloud, while code and toolchains remain on the user's device. This boundary is worth remembering.

Where effort is saved and where things get stuck

@国外VPS测评 laid out the value clearly: separating event-driven operation from task execution—the Router judges, schedules, and maintains global context, while Workers execute and keep following up—avoids reinterpreting the context every time and reduces repeated token consumption. But he also asked how task conflicts, permission isolation, and result aggregation should be handled after Workers run in parallel. When multiple Workers modify the same repository at the same time, explicit locking and approval mechanisms are needed.

@Alphana added the question from the user side: when the system does not pick up something, is it because it did not see it, or because it judged that it did not need to handle it? The system can be quiet, but it is best to leave a place where users can check; otherwise users can only repeatedly ask, 'Did you receive it?'

One commenter said this is like the emperor only talking to the prime minister while everyone below executes. It is blunt, but it captures the relationship between the Router and Workers perfectly. The tool layer is the hands and feet, the panel is the monitor, and the orchestration layer determines how the brain sorts out execution dependencies. The clearer the orchestration layer is, the more important it is to write permissions, locks, approvals, and observability into the design in advance. Otherwise, the more Workers there are, the more it resembles a crowd all modifying the repository at once: lively, but no one knows who will ultimately merge the changes.