Durability Is a Decision, Not an Architecture: Let the Agent Own the Lifetime
Contact Me
- Blog: https://cugtyt.github.io/blog/llm-application/index
- Email: cugtyt@qq.com
- GitHub: Cugtyt@GitHub
DeepSeek recently open-sourced a Super-agent prototype: a long-running Router session that receives events from GitHub or chat, and isolated Worker sessions that each own one unit of work. It is easy to read this as a new architecture that competes with programmatic tool calling (PTC), dynamic workflows, or Claude Code agent teams.
I think the topology is the less important part. The consequential questions are who owns a worker’s lifetime and who can send the worker its next input. Once we separate those two questions, a further step comes into view: an always-on main agent that writes, starts, feeds, supervises, and ends its own workers. How long a worker lives becomes a decision the main agent makes per task, rather than a property fixed by the system.
The Question Isn’t Router vs Worker
When we say a task is “long” we usually mean elapsed time. That is not the useful distinction here. A better measure is lifetime relative to the main agent that started the work.
Most delegation today lives inside the main agent’s runtime. A tool call, a PTC script, a dynamic workflow, or a one-shot subagent is spawned during a turn and returns before the turn ends. Even a multi-turn session held by an in-process SDK handle belongs to the process that owns it: it can continue several times, but it disappears when that process exits. The work can take an hour and still be bounded by its caller.
DeepSeek’s workers are different. A Ticket gets its own Executor Session and directory. When its turn ends without an open question it becomes idle, and a later event on a subscribed thread can continue it. Sessions, directories, subscriptions, and pending messages survive a host restart. Even an ended Ticket can resume when a person comments on it later (execution doc). The worker’s logical lifetime is no longer bounded by the turn that created it.
So the dividing line is not router versus worker, and not short versus long. It is whether the worker can outlive the runtime that started it.
Two Axes: Who Owns the Lifetime, Who Sends the Input
A second question is often mixed into the first: who can send a worker input? Peer messaging is the obvious example, and it is tempting to treat agent teams and super-agents as the same idea. They are not.
Claude Code agent teams give each agent a mailbox, and teammates can message
each other by name. But the team belongs to one session: a session has exactly
one team, a teammate’s background work cannot outlive the lead’s process, and
/resume does not restore in-process teammates
(agent teams docs). Teams are
addressable, but they are bound to their caller.
DeepSeek’s workers are the opposite. They outlive the router’s turn, but they are given no tools for starting or messaging other sessions (architecture doc). When several workers touch the same thread, they all receive its new events and can notice each other’s actions without point-to-point communication.
The two properties vary independently, and peer messaging turns out not to be essential. Anthropic’s guidance on multi-agent systems recommends splitting work by context rather than by problem type: sequential phases of the same work, tightly coupled components, and work requiring shared state should stay together, while independent research paths and separate components can run in parallel (When to use multi-agent systems). If two agents need to talk constantly, they probably belong in one context. If they do not, parallel workers with isolated contexts are enough.
What Changes When Work Outlives the Main Agent
When a worker lives inside its caller, the caller provides three things for free. It owns the worker. Its return marks the end of the work. Its shutdown cleans everything up. Once the worker can outlive the caller, all three have to become explicit:
- An owner. Someone must remain responsible for the worker after dispatch.
- End rules. Something must decide what counts as completion, cancellation, or legitimate waiting.
- Health checks. Something must notice when a worker has failed, stalled, or drifted.
Without them, the system accumulates three different kinds of “zombie” that are worth keeping apart:
- Leaked child. A worker that was supposed to end with its caller, but cleanup failed. Claude Code’s documentation, for example, mentions tmux sessions that persist after the main session ends. This is a cleanup bug in a caller-bound design, not evidence of independent lifetime.
- Stalled or drifting worker. A worker that is alive but making no progress, looping, or moving away from its goal.
- Retained state. Work that finished correctly, but whose records and sessions nobody discarded.
DeepSeek answers these questions mostly in system code. A Ticket ends on a
ready report, when its pull requests close, or when its worker reports
dropped. Background jobs get at most 30 minutes after a turn. Subscriptions
route follow-ups to the owning worker, and handback rules return out-of-scope
messages to the router. On restart, interrupted assignments start again with a
recovery note. Beyond the prototype, DeepSeek’s design essay describes an
external Watchdog session that handles infrastructure faults and asks a model
whether each worker is making substantive progress or drifting from the overall
goal (essay summary).
These are reasonable answers for today’s models. The question is whether they must stay fixed in the system as models become more capable.
The Main Agent as Host
Here is the next step. Treat the always-on main agent as a host, in the sense of an operating system. The PTC programs and workflows it writes are its applications. The host decides what to start, what each program listens to, how long it lives, and when to stop it.
The host can create four kinds of program from the same primitive:
- One-shot worker. Runs, returns a result, and is discarded. This is the right choice for most bounded computation.
- Durable, host-fed worker. Keeps its session after a turn. The host sends each later input, for example after reading a review or a CI result itself.
- Durable, subscribed worker. Created with its own event subscription, so it reacts to the environment directly. A worker following a pull request can receive its review comments and CI results without the host forwarding each one, including while it is in the middle of a turn.
- Supervisor. A small program that watches other workers for crashes, exits, or long silence, and applies a policy: restart, escalate to the host, or stop.
Discarding versus keeping is therefore not an architectural rule. Anthropic recommends parallel subagents whose fresh context can be discarded after completion (fold subagents into your main agent loop). That remains good advice for pure computation. Work that waits on the outside world, such as a pull request under review, benefits from a worker that keeps its context. The host chooses per task.
The “who sends the input” axis also becomes a choice. The host can feed a worker directly, or it can give the worker a subscription and step back. Either way, the condition that keeps the design coherent is the same: the host must be able to observe the worker’s failures. As long as crashes, exits, and stalls reach the host, the host can decide what to do about them, or write a supervisor that decides for it.
This is close to supervision trees in Erlang/OTP: workers run independently, and a supervisor watches for exits and applies a restart policy. The difference is that the restart policy is not configured by hand. It is code the main agent writes, and can rewrite.
Recovery also becomes simple. The host is always on, but if its process crashes, it restarts, reads its registry of programs, and continues. Every program has exactly one owner, so after recovery there is no question of who is responsible for what.
What Stays in the Runtime
None of this means the system disappears. It means the system shrinks to mechanisms, while the host provides policy, as in the classic operating-system split. A useful test for where a responsibility belongs:
If code enforces it more reliably than a model, it belongs in the runtime. If it is a judgment, it belongs to the host.
By that test, the fixed runtime layer is small:
- Registry and saved state. Programs, their sessions, and their owners, written atomically so the host can recover from them.
- Runtime-produced failure signals. Exit codes, heartbeats, and “no activity for N minutes.” A crashed or hung worker cannot report its own failure, so these signals must come from the runtime, not from the worker’s goodwill.
- Kill and timeouts. A hard way to stop any program, regardless of what its model is doing.
- Event subscriptions. The plumbing that delivers events to the program that asked for them.
- Permission scope per program. A subscribed worker acts on the environment directly, so its authority must be enforced by the runtime. The host chooses the scope when it starts the worker. DeepSeek’s immutable Mandate per Ticket plays the same role.
- Restart of the host process. A plain process supervisor, with no model involved.
Health checks split along the same line. Whether a worker is alive is mechanical, so a supervisor program built on runtime signals handles it. Whether a worker is making real progress or drifting is a judgment, so the host makes it. What remains of DeepSeek’s Watchdog is a process restart for the host itself.
Why This Scales With Models
The value of this arrangement is where it puts the decisions.
- Lifetime is a per-task decision. One primitive covers one-shot, host-fed, and subscribed workers. Choosing between them requires judgment about the work, not a different system.
- The event fast path is code the host writes. DeepSeek’s essay makes a good point: stable, high-frequency decisions should become deterministic code instead of repeated model calls, a fast path beside the model’s slow path. The host model agrees, but the host writes that code itself, as a subscription or a small routing program. It can specialize, change, or delete the fast path as it learns, instead of living with routing rules fixed in the system.
- Supervision is code the host writes. Restart on crash, escalate after repeated failure, stop after a period of silence: these are generated programs, so they can be tuned per task and revised when they prove wrong.
- Context stays where the work happens. Each program keeps its own heavy context. The host receives summaries, requested events, and failure signals. Deciding what it needs to know is part of the host’s job, and it is a skill that improves with the model rather than a fixed limit of the design.
- One owner per program. Recovery is reading the registry. A leaked worker is a decision the host has not made yet, not a gap in the system.
The common thread is that decomposition, routing, lifetime, and supervision live in model output: skills, prompts, and generated code. That is exactly the surface a self-improving harness can revise (Towards Harness RSI). A fixed router with fixed subscription rules improves only when its authors change it. A host that writes its own routing improves whenever the model, or the harness around it, does.
Comparison
| DeepSeek Super-agent | Claude Code agent teams | Main agent as host | |
|---|---|---|---|
| Who owns a worker’s lifetime | System rules: ready report, pull requests closed, dropped | The lead’s session | The host, per task |
| How input reaches a worker | Router dispatch, plus fixed subscriptions that route thread events to the owner | Peer mailboxes | Host-fed, or subscriptions the host creates |
| Peer messaging | Not allowed | Built in | Not needed; split by context |
| Health checks | Fixed limits, plus an external Watchdog session in the essay | Mostly the user and the lead | Supervisor programs the host writes, plus the host’s own judgment of progress |
| What improves with the model | Decisions inside a fixed structure | Coordination within one session | Decisions and the structure itself |
The designs are closer than the table suggests. DeepSeek also puts semantic decisions in the model: filtering policies are written as prompts, and the Watchdog can edit prompts and trigger rules while the system runs. The real difference is the structure. DeepSeek fixes the roles, the routing, and the end-of-work rules in code. The host model lets the model write the structure too, and keeps only mechanisms in code.
So the host model is not a competitor to the Super-agent but a continuation of it. Fixing the structure in code is a sensible choice while models still delegate unreliably. As they improve, the router, the subscriptions, and the watchdog can each become a program the host writes for itself, and the fixed system shrinks toward the runtime layer.
Limits
This design moves complexity into the host, so it depends on the host doing that work well.
- The host must delegate. In DeepSeek’s reported experiment, a single session with subagents available under a neutral prompt called a subagent in 0 of 5 runs, and its p95 completion time was about twice the Super-agent’s (MarkTechPost summary). Models do not yet decompose and delegate reliably without guidance. The host model is a bet that they will, and the bet should be stated as one.
- Delegation costs tokens. Anthropic reports that multi-agent implementations typically use 3 to 10 times more tokens than a single agent for equivalent tasks. Durable workers are worth it when they protect context, run independent work in parallel, or wait on the outside world, not by default.
- Subscribed workers act on their own. A worker reacting to events without the host in the loop needs a permission scope that the runtime enforces, not just instructions.
- The host is only as good as its signals. If failure signals are missing or untrustworthy, the host makes lifetime decisions blind. Runtime-produced heartbeats and exit signals are not optional.
Conclusion
The DeepSeek release is a useful prompt to separate two things that are often mixed together. Router and worker roles are one way to organize work. The deeper change is letting delegated work outlive the turn that created it, which moves lifetime ownership out of the caller.
DeepSeek moves that ownership into a system with fixed structure and a model inside it. The further step is to move it into the main agent: keep it always on, let it write the programs that do the work, decide what each listens to and how long it lives, and supervise them with code it also writes. The runtime keeps only what code does better than a model: state, signals, kill, subscriptions, and scopes.
Durability is then a decision, not an architecture. And because the decision belongs to the agent, it gets better as the agent does.