Super-Agents Need Missions

The DeepSeek Harness team published Exploring Super-agent Design on November 1. It is the clearest description yet of where agent runtimes are heading: always on, event-driven, many tasks in flight, humans reduced to decisions and sign-off. It also goes further on authority than most agent designs. The prototype it links to, a research version that differs from the system the paper describes, defines a Ticket as “a unit of authorized work” and records with each one what it calls a Mandate: the policy version, the scope, the matched rules, and the sender’s identity. Wider scope means a new Ticket, a person’s stop withdraws the Mandate, and the host revalidates it before ended work resumes.

That record stops at the scheduler. The host checks it when work starts and when it resumes, while the credentials and execution environments a Worker reaches still answer to the whole agent. The paper’s section on open problems lists permission boundaries and security among the problems still to solve. My argument here is simple. Once work outlives the session and starts from events, its approval has to reach the credentials and execution environments the work touches, and the scheduler can’t carry it there alone. The Mission is the record each credential and enforcement point refers back to. Without that, a Super-agent is a very productive ambient-authority machine.

The Session Was Never the Unit

The paper’s central claim is that the session shouldn’t be the basic unit of work. Today a session does two jobs: it manages the model’s context, and it is the user’s unit of project management. DeepSeek pulls those apart. A long-lived Router layer handles every human interaction and dispatches work, and context-isolated Workers each own one task. Sessions become an implementation detail, and the authors argue that making users manage them was a habit inherited from low-level LLM APIs. This is the scheduler-side version of the argument I made in Sessions Are Not Missions, that a resumable session preserves execution continuity, not authority.

The proposed Mission-Bound Authorization drafts make the parallel separation for authority. OAuth has authorization grants and access tokens, and Rich Authorization Requests can describe a single transaction. What it lacks is a common record of the approved work that governs every token later issued under it, says which approved task a token serves, and says whether that task is still approved. In the drafts, that record is a Mission. A client proposes a Mission Intent describing the task. The Mission Issuer, usually the authorization server, acts as the control point: it derives the Authority Set the task needs, records the approver’s consent to both, and gates every later token on the Mission’s current state. The gap shows once one agent holds delegated authority for hours, across many resources, on many tasks at once.

Authority Stops at the Scheduler

The prototype’s authorization rules are explicit about where the Mandate applies. “The host enforces allowed lists, rules and Mandates,” and messages, comments, and quoted documents “cannot change those permissions.” That governs whether work starts, continues, or resumes. It doesn’t govern what a running Worker can do. Executor Sessions, the prototype’s Workers, “run commands without approval as the operator’s OS user,” and every Ticket reaches GitHub through the same agent account. The wrappers and per-Ticket directories “establish defaults, not a security boundary,” since a worker “can still execute a program by absolute path.” Merge conditions are instructions in a prompt, and the host “has no merge-specific decision logic.” The docs say so plainly and point to the resource for enforcement: “To enforce approvals, require them in branch protection.”

The paper’s discussion of context boundaries shows where this leads. As use grows from a small team to an organization, deciding how to provision Super-agents becomes deciding which context is shared and which is isolated, and isolated instances sit on separate permission boundaries. For what a Worker can actually reach, context isolation and authority isolation are one knob, and the knob is instance provisioning. Missions separate the two. One instance can share context across many tasks while each task runs under its own approved Authority Set, enforced where the work happens. You shard for confidentiality when you need to, not because authority has nowhere else to live.

DeepSeek could extend its Mandate instead, and on a single host a daemon that checked each command against the Ticket’s Mandate might be enough. The Mandate is an internal scheduler record, though, and the work doesn’t stay on one host. It reaches GitHub, other vendors’ services, and authorization servers that can’t read DeepSeek’s records and have no reason to trust the Router’s reading of them. A Mission gives independently operated systems a common authority contract: they can derive credentials from it, refuse actions against it, and withdraw authority through it, without inheriting the scheduler’s trust. A resource server that understands Missions evaluates the authority it receives, and a service that doesn’t, such as GitHub, needs an enforcement point that mediates the action or a safe projection onto its own scopes.

One Bug Report, End to End

The paper’s own example of proactive work shows where the boundary has to move. In DeepSeek’s internal user group, a “silently reproduce and fix” policy lets the agent notice a reported bug, reproduce it in the background, and, once it has confirmed the bug and found a simple fix, open a pull request before anyone asks. What follows traces one such bug through the paper’s architecture, using the prototype’s rules where it has them.

A Trigger Is Not an Approval

A teammate mentions the bug in the team chat without addressing the agent. The message is a Trigger, one of the environmental events (group chat messages, emails, review comments, CI results) that replace the human prompt as the agent’s main input. A Trigger tells the agent that something happened. It does not tell the agent that anyone approved it doing something about it, and the paper acknowledges that event-driven design exposes the agent to more untrusted input.

The prototype handles this step carefully. A deterministic gate checks the sender against the policy before any model assesses the message, an unaddressed message can become at most an “inferred” candidate, and a proactive accept needs a matching rule. The paper’s second filter stage then has a model judge candidates against policies written as prompts. Whether the agent should care about an event can be a prompt. Whether it may act is a Mission.

The Router also batches Triggers that arrive during a model call into its next call, so one call can propose work for several people at once. The Router sees every event, untrusted input included, which makes it an excellent proposer and the worst possible authorizer. It can propose which work a Trigger belongs to, and the host has to validate that association against what it recorded. The model can advise, but it never authorizes.

In authorization terms, the policy is a standing approval with a ceiling: reproduce in a checkout, run tests, open pull requests on these repositories, never merge, never touch deployment secrets. The experimental Mission Template is built for that. A person consents once to the ceiling and a dispatch policy. A Trigger that clears DeepSeek’s filters is only a candidate. The Mission Issuer adjudicates each dispatch against the approved template and creates a Mission at machine speed only if the dispatcher, the ceiling, the template’s bounds, and its prohibited classes all check out. The template also pauses once its last approval is older than its review cadence, until a person approves it again. The prototype’s rule decides whether the work starts, and the Template also bounds what the work may do once it has. In the OAuth binding, every access token issued under that Mission carries the mission claim naming it.

The Worker Prepares a Patch

The Router cold-starts a Worker, which reproduces the bug and writes a fix in its own checkout. This is the paper’s speculative execution, work started before anyone knows it will be wanted. The patch can be thrown away, so the work runs under the Template’s ceiling with no human in the loop, though running its tests is safe only inside the confinement described below. When the Worker spins up subagents, as the paper allows, a subagent working inline uses delegated tokens under the same Mission, and one whose work outlives the Worker’s flow, such as a queued job, runs under a narrower Child Mission with its own durable handle. The Worker’s own work continues across pauses under the same Mission through Continuation. In the prototype, subagents run “with the worker’s permissions.”

The test run is where execution enforcement matters. In the paper’s design, the agent loop runs in stateless cloud containers and reaches the developer’s machine, with its uncommitted changes and local credentials, through a lightweight daemon that “keeps no session state and does nothing but execute commands.” The paper is candid that this assumes the cloud and the endpoints trust each other, so a compromised loop could take over every connected endpoint. That daemon is the natural enforcement point, and it is already on their diagram. To trust a Mission instead of the loop, it has to enforce the Mission itself: the operations a command may perform, custody of the credentials the command uses, the files and network the command can reach, and the Mission’s current state, checked through the runtime contract or an AuthZEN decision.

The check is only as strong as the confinement around it. The test command runs code from the repository, and that code can read local credentials or call another service. So the daemon has to run governed work in an environment whose only route to a consequential resource passes through the check, with no debug shell, direct socket, or side connector around it. Keeping credentials out of the model’s context, which the paper lists as an open problem, closes one route. A subprocess can still read a secret it finds on disk, and an agent can misuse a credential without ever learning its value.

The Pull Request Opens

With the fix ready, the Worker wants to open a pull request. The Template draft holds some classes back even inside the ceiling. Irreversible actions, external commitments, and communication that leaves the deployment’s trust boundary need a person at the moment of decision. Posting to a hosted service outside that boundary counts as external communication, so this step depends on where the repository is hosted, not who owns it.

A repository on a service inside the deployment’s trust boundary, such as a self-hosted GitHub Enterprise Server, can be covered by the standing Template, and the pull request opens unattended. A repository on GitHub.com sits on an external service even when the organization owns it, so under the current Template rules this step needs a person. That strictness blocks exactly the unattended SaaS workflow DeepSeek is after, a trade-off the experimental Template hasn’t settled. Where a person is needed, the Worker asks for a human-approved Mission Expansion of its instance, which leaves the template behind and creates a successor Mission with the external-communication authority. Deferred Approval lets that approval arrive hours later, and the sign-off the paper names as the human’s role becomes a recorded approval event. Once it lands, the Worker opens the pull request under the successor Mission.

A Comment Asks for a Merge

Once the pull request exists, the Worker subscribes to it, and follow-up comments go straight to the Worker, and the Router sees them without deciding on them. In the paper’s ablation, the Router makes about 30% more decisions without pass-through, with completion time about the same. Pass-through also makes the pull request a live instruction channel into a running task. In the prototype, a person’s message on a Ticket’s own Thread resumes it “regardless of who sent it,” and the Executor decides whether the request fits the scope.

A reviewer comments, “Looks good, merge it.” Under the prototype, whether the agent merges depends on its delivery instructions and on GitHub’s branch protection. With a Mission, three checks come first. The first is who sent the comment, as GitHub itself authenticates it. The prototype never maps one person’s identities on different sources to each other, so the host treats the teammate who reported the bug in chat and the commenter as unrelated. The second is whether that sender may direct this work, which identity alone doesn’t settle, since being the person the Mission acts for doesn’t authorize every change to it. The third is whether the request fits both the approved purpose and the Authority Set. The Mission supplies the boundary for that third check. Recognizing the sender and deciding who may direct the work are the deployment’s identity and policy, which a Mission doesn’t provide.

Merging is outside the ceiling, so the third check fails however the first two come out. The work has a valid credential for the repository, held at the enforcement point, and the enforcement point still refuses the merge before it runs. GitHub honors whatever a credential permits, so the decision has to happen before the request reaches it, and branch protection stays as the resource’s own backstop. Merging would take another Expansion and a fresh approval.

A harder comment asks the Worker to relax the token check while it’s in there. That can use the same repository and the same permitted write operations as the approved fix while changing what the work is for. The Mission records the approved purpose, a fix for this bug, but resource and action checks alone can’t show that a change still serves it. An Authority Set can constrain paths or operations where the difference can be written down. Where it can’t, telling the two apart takes a person or an independent review, and a change of purpose should be a new proposal. The paper’s own definition of continuity, a user who asks for Plan A in chat and switches to Plan B in a pull request comment, is the benign version of the same case.

The Rule Is Withdrawn

Midway through, the team decides proactive fixes were a mistake and withdraws the rule. The developer’s laptop, where the Worker’s next test run is waiting, is offline. The paper supports machines like this, and when a device reconnects, the cloud agent picks up the work that was waiting for it.

In the prototype, a policy change “does not immediately revoke live Tickets’ Mandates.” It notifies the affected Tickets and revalidates their Mandates when ended work resumes, by design, because “a cancelled change leaves half-finished work.” A person can stop a Ticket from the panel, which ends its Assignment and kills its shell jobs, but the agent account’s credential stays on the machine and keeps working.

With Missions, the withdrawal has a target outside the scheduler. Deferred work needs authority that outlives any token without becoming a long-lived bearer secret, and the Mission is that durable record. Revoking the template stops further dispatch, but it doesn’t end the Missions already dispatched, so those have to be suspended too. Suspending the live Missions stops new issuance for each of them and their children, and Signals push the change to enforcement points. When the laptop reconnects, the Worker can pick its work back up, but Continuation refuses it new authority for a Mission that is no longer active. A token already issued can still be honored on a stateless enforcement path until it expires, so how fast authority actually stops depends on token lifetimes and on whether enforcement points check current state.

The paper’s Watchdog, a separate session that judges whether each Worker has drifted from the overall goal, can pull the same levers. The Watchdog advises, and the control point acts. The paper also lets maintainers change trigger rules by asking the Watchdog in plain language, and that plane has to stay separate from the authority of the Workers it configures, because whatever can rewrite the trigger rules can decide what the agent works on next.

What Missions Don’t Fix

Two limits are worth stating plainly, because the Super-agent design exercises both.

The first is information flow. The Router’s value is its global context. It sees every task, and Chain of Recall lets it pull any old task back into view, so data gathered under one Mission can shape how the Router dispatches another and end up in the next Worker’s prompt. Missions bound what each task may do, not what one task learns and passes to another. The draft family doesn’t define an information-flow layer for that, and the harness draft’s taint tracking and egress controls are coarse controls, not that layer. A Super-agent serving people with different need-to-know needs an answer that authorization alone won’t supply.

The second is prompt injection. Missions do not prevent it. They constrain it. Intent text is inert once approved, and the Authority Set is fixed at the control point, so a hijacked Worker can misuse only the authority its Mission already holds, provided its environment offers no route around enforcement. For an always-on agent reading public group chats, that is the difference between a bad pull request and a compromised fleet. It is not the same as safe.

Architecture, Not Prompts

The most instructive result in the paper isn’t about Super-agents. It’s about the baseline. In a synthetic test of five runs, with coding simulated by a tool that just consumes time, a single session with a subagent tool was asked to delegate work. With a neutral prompt, it never delegated, and its slowest tasks took nearly twice as long as the Super-agent’s. With a prompt urging delegation, it delegated in four runs and did the work itself in the fifth because it judged the job small. DeepSeek calls the results indicative only, and they measure scheduling rather than execution. Its fix was structural. The Router is designed not to execute work and can run without a shell tool at all, so the question never comes up.

Authority works the same way. An agent told by prompt to stay within scope will usually stay within scope, until the run where it judges otherwise. DeepSeek moved delegation from prompts into architecture, and its prototype has made the same move for admission. The rest of the boundary still runs on prompts and shared credentials:

Three questions this walk-through raises still need work: how a deployment decides who may direct an existing Mission, how it tells a change of plan from a change of approved purpose, and how a shared agent session ties each action to the right Mission. The drafts define the authority boundaries, and agent runtimes still have to connect work to them correctly. The drafts are on GitHub, and the Mission Handbook tells the story in prose. If you’re building a Super-agent, I’d like to hear where this breaks.