Before a release freeze, a coding agent is approved to implement passkey login. It runs for an hour, spawns a test-repair sub-agent, and opens a pull request. Then a reviewer finds a risky migration and freezes the branch. Approval is revoked in the governance system, but the harness only knows that the workspace, task graph, and tokens are still recoverable. The next morning the session resumes, the sub-agent finishes its retry loop, and the agent updates the pull request after approval had been revoked.

A modern agent can resume across machines, restart sub-agents, recover from crashes, refresh tokens, and pick up where it left off. From the outside, that looks like the agent is continuing the mission.

Architecturally, it is only continuing the session.

A session can prove the runtime survived. It cannot prove the mission did.

A session is the checkpoint. A mission is the work order. The checkpoint tells the harness where to resume. The work order tells it whether it is still allowed to.

That distinction matters because long-running agent systems persist for hours or days, run after the user closes the window, delegate to sub-agents, discover tools at runtime, and continue exercising authority across process, device, and trust-boundary changes. In those systems, treating a session as equivalent to a mission is not a UX shortcut. It is a governance failure.

This is the runtime-layer version of the authority gap explored in the Power of Attorney, Mission Shaping, and Mission-Bound OAuth arguments:

The harness that runs the agent is not the layer that owns the mission.

What the Harness Preserves

Agent platforms expose a familiar set of primitives: resumable execution, persistent workspaces, background jobs, task graphs, sub-agents, dynamic tool discovery, memory, retries, and cached tool connections. Those primitives are valuable because they let the harness reconstruct enough state to take the next step. They are also why agent products are starting to look less like chatbots and more like distributed runtimes.

Each primitive solves a real problem. Resumable execution lets a long-running task survive a laptop closing. Persistent workspaces keep work in progress recoverable across restarts. Task graphs let the agent keep coordinating after a step fails. Tool connection caches let the agent skip the discovery and authentication overhead of every external call. Sub-agents let work parallelize. Background jobs let work continue while the user does something else. The user expectation behind all of this is simple. Work in progress should not be lost when infrastructure interrupts it. That expectation is correct, and it is the foundation of usable agent products.

A session, in this post, means an agent harness runtime session: the state that lets execution survive infrastructure churn. It is not the same thing as an IdP session, browser session, OAuth authorization session, or application login session, though those may be adjacent to it.

An agent harness session may include conversation context, task checkpoints, scratchpad memory, workspace state, tool connections, cached credentials, and orchestration state for retries or async work.

All of this is good engineering. None of it explains why the agent is still authorized to keep working.

A Session Answers “Where Can the Agent Continue Working?”

A session is a runtime construct. It preserves continuity across the things that interrupt execution.

Most of what a session does goes unnoticed. A user closes a laptop. The process restarts on a different machine. A token refreshes, a sub-agent retries, a workspace migrates. The session storage still holds the workspace, the task graph, the cached MCP connections, and the conversation context. The harness loads that state, reconnects the tools, and the agent picks up its work.

That is what a session is for. It tells the harness where the agent can continue working.

The harness recovers from each disruption it sees. The mission may be experiencing events the harness will never see.

The left column is visible to the harness. The right column is not. The harness can recover runtime state without learning that the mission has changed or ended.

It is the same shape as a ride-share driver whose app loses signal mid-trip. The route, the GPS, and the vehicle state are on the left. The cancellation the rider sent two minutes ago is on the right. The driver completes the request the rider has already withdrawn.

The session-level question is narrow:

Is enough runtime state still present for the next instruction to execute?

When the answer is yes, the harness resumes. That is the right behavior at the runtime layer. A user closing their laptop should not lose an hour of work to a process restart. A sub-agent failing in a retry loop should not invalidate the parent agent’s progress. A workspace migration should not cause the agent to forget where it was. Sessions are how all of that holds together.

That is the question every useful harness asks. The mission asks a different question.

A Mission Answers “Why Is the Agent Allowed to Keep Working?”

A mission is the approved purpose of an agent’s work. It binds delegated authority to that purpose, to a declared lifecycle, and to an approval context, and it preserves the legitimacy of that work across the things that change after approval.

Intent is not mission. Intent is user desire at a point in time. Mission is the durable governance object derived from intent, with bounded scope, approval context, and lifecycle. Turning intent into a mission is the work the Mission Shaping series covers. Intent supplies the why. Mission gives the architecture something to evaluate against.

The vocabulary matters. The mission is the work the user approved. It carries the record of that approval: who granted it, what it covers, when it ends, how it can be narrowed, and who inherits it. The Mission Authority Service is where the runtime asks whether any of that has changed.

Revoking the mission should stop the work even if the session can still be resumed.

A mission is not workflow state. Workflows track progress. Missions govern legitimacy. A workflow engine can continue after the justification for the work disappears, because its state is about what step comes next, not about whether the work should still be running. A mission-aware system cannot. The mission is the authority record that workflow state references but does not own.

The mission record carries:

• the purpose for which authority was granted
• the evidence behind the approval
• the conditions under which the authority remains valid
• the bounds on delegation
• the lineage of actors that inherited it
• the lifecycle events that end it
• the revocation semantics for stopping it before its natural end

In IAM terms, these are different systems of record. Session state records runtime continuity. Token state records whether a credential is active and usable at a protocol boundary. Policy state records whether a particular request is permitted under current rules. Mission state records whether the delegated mission itself remains legitimate. Collapsing those records into the harness makes runtime recoverability stand in for authorization, revocation, and lineage.

The mission-level questions are different in kind:

• Is the task still authorized?
• Has the risk posture changed since approval?
• Is the user’s current intent still reflected in the execution?
• Has approval been revoked, suspended, or narrowed?
• Did the scope expand without a new approval?
• Can the current actor delegate further, and to whom?
• Should downstream systems still trust an action presented under this authority?

None of those answers are derivable from runtime continuity. A live process tells you the runtime is alive. It does not tell you the mission behind the runtime is still legitimate. That is the distinction the Execution Mandate post draws between identity, access, delegation, and authority.

Sessions cannot answer the authority question because sessions are not the layer that owns it.

A Session Can Be Valid While a Mission Is Invalid

The distinction is easier to feel through examples than through definition. Three scenarios, each from a different domain, each producing the same shape of failure.

Consider an agent working under a manager’s delegation for a project that takes three weeks. The agent has access to the manager’s calendar, communicates on the manager’s behalf with vendors, and drafts approvals that flow through the manager’s name. In week two, the manager leaves the company. HR systems remove the manager’s access. Payroll is closed out. The manager’s email forwards to an interim contact. The agent’s session storage is intact. Workspace, task graph, cached credentials, all recoverable. The delegation that justified the agent’s authority is gone. The runtime is healthy. The mission has no living grantor.

Now consider a security agent granted access to investigate a suspected breach. Logs are pulled, anomaly detection is run, draft incident reports are prepared. At 4pm the breach is resolved by a different team. The incident is closed in the tracking system. The agent’s session continues running through 6pm because the harness queued additional analysis steps when the breach was first declared. Those steps are still in the queue. The harness has every reason to think it can continue. What it cannot see is that the reason for the investigation has ended. The session is doing exactly what sessions are built to do. The investigation does not need it anymore.

And consider a user who approves an agent to draft a financial report. Mid-execution, the user discovers the report was based on stale numbers and revokes the approval. The agent’s runtime is healthy. The next step in the task graph is queued. The tool connections are warm. The credentials are inside their refresh window. Nothing in the session storage knows the user has changed their mind. The harness will keep working on the report until the runtime breaks or the work completes, whichever comes first.

Three different mechanisms produce the same shape. A grantor disappears. A triggering condition ends. An approver changes their mind. In each case the session preserves everything the runtime needs and nothing the governance layer would need to stop. Runtime state is recoverable. Delegated authority is no longer legitimate.

The harness that asks only “can I continue?” continues. The harness that asks “should I continue?” stops. The difference between the two harnesses is whether the architecture has a layer that owns the second question.

The Failure Mode

The three scenarios share a dangerous assumption.

Execution continuity equals authority continuity.

Traditional sessions assume the user is nearby. Agent missions assume the user is absent. The user is asleep, in a different timezone, in another meeting, on another project, or gone from the company entirely. The agent keeps working through all of those states because the work outlives the user’s attention. Session-model assumptions that worked when the user was minutes from the next interaction stop working when the user is hours or days away. Authentication freshness stops implying intent freshness. Interaction continuity stops implying engagement. Human absence is not a corner case for agents. It is the default state.

Human sessions accidentally carried governance assumptions because humans naturally terminate intent. A user logging out, closing a laptop, or walking away ended runtime and authority at the same moment. Sessions never had to distinguish “can continue” from “should continue” because the human supplied the “should” by being present. The IAM stack inherited that conflation as a working assumption. Agents break the inheritance by not terminating their own intent.

Short-lived chat interactions hide the assumption. The user is present, sees the next action, and closes the loop manually. Narrow copilots hide it too. Every meaningful side effect requires fresh confirmation.

It breaks when work runs unattended. It breaks when work crosses domains. It breaks when child agents inherit context. It breaks when the next action changes business state. It breaks when the resource being acted on did not exist when approval was granted.

The breakage has a structural cause.

Sessions model what runtime needs to stay alive across infrastructure churn. The connection. The state. The context. The resume point. The identity check.

They do not model what governance needs. The purpose the work was approved for. The bounds on how delegation narrows. The conditions that have to keep holding. The chain of who passed authority down. The rules for stopping it. The approval still standing in the organization.

What they model is enough to continue. What they leave out is what makes continuing legitimate.

Two forces make the failure mode deepen.

Product pressure pushes sessions toward persistence. Engineers want resumable workflows. Users want work to survive reboots. Vendors want agents to remember more state and run longer tasks. Every incentive points the same way. Sessions get longer, more durable, more recoverable.

Authority should not follow that shape. Authority is bounded by purpose, conditions, and lifecycle, not by infrastructure availability. The point of governing the stay is that authority must be terminable on its own clock, independent of whether the runtime that consumes it is still alive.

The assumption concentrates at resume. Every time a session wakes, whether from a process restart, a device handoff, a token refresh, or a sub-agent retry, the harness has to decide whether to continue. Treating resume as continuation rather than as a question collapses authority into runtime state at exactly the moment the architecture should be holding them apart.

When the runtime owns both execution and legitimacy, the longer-lived artifact wins. The session keeps going after the mission should have ended. That is not a bug. It is what sessions are for.

Why the Harness Collapse Is Worse

The conflation is not lazy. It is rational engineering. Sessions are concrete and shippable. Missions are abstract and governance-heavy. Engineers reach for what they can build, and harness vendors reach for what they can sell. The result is the wrong default, baked in early.

The harness session is a distinct authority-collapse point. Tokens are projections, not missions. Identity, access, and delegation each answer their own question. The harness session is another place where mission state quietly accumulates, and it is a worse place than the token.

The reason is what each artifact is designed to do. Tokens are designed to force re-evaluation. They have explicit expiry, route through issuers on refresh, and require issuer participation for delegation. The narrowness of a token is not just a property. It is enforcement. Every refresh, exchange, or downstream issuance re-engages the authority source, whether or not authority is actually being re-checked.

Sessions are designed to do the opposite. Conversation context, task graph, sub-agent handles, tool connections, cached credentials, workspace state, scratchpad memory, queues, and retries all exist to avoid re-engagement. A session is a structure built to keep work alive across the events that interrupt it.

When a token is conflated with a mission, the substrate pushes back. Tokens expire. Refreshes route through issuers. The token’s design surfaces periodic decision points the conflation cannot fully suppress.

When a session is conflated with a mission, nothing pushes back. The substrate is engineered to suppress exactly the events the mission layer needs to detect.

That asymmetry produces two structurally distinct failures.

Sessions are engineered for survival. Missions are engineered for termination. A revoked mission absorbed into a session has to be cleaned out of the task graph, sub-agent handles, tool connection cache, orchestration queues, workspace, and scratchpad. Each of those is engineered to persist. When the artifact engineered for maximum persistence is the same artifact that carries authority, the artifact wins. The mission inherits the session’s lifetime instead of the other way around.

Authority by ancestry has no token-layer analogue. Token-based delegation requires an explicit issuance step. Session-based delegation can happen simply because a child descends from the parent’s runtime graph. There is no equivalent of issuance. Delegation in sessions is implicit by default. Delegation with tokens is explicit by default. Implicit delegation cannot be attenuated, attributed, or separately revoked. Sub-agent fan-out is the failure mode the token layer does not have. Token delegation requires a signature. Session delegation requires only proximity.

The token-layer collapse is the more familiar IAM failure. The harness-layer collapse is structurally different. It amplifies what the substrate is designed to suppress, and it adds a delegation path with no issuance event.

Beyond Coding Agents

Coding agents make the failure easy to see. The higher-risk versions are enterprise workflows.

An agent is approved to reconcile vendor invoices for an active procurement program. It discovers accounting tools through MCP, pulls invoice data, asks a sub-agent to compare contract terms, and posts reconciliation adjustments directly to the general ledger. Halfway through, the procurement program is suspended because the vendor is under legal review. The runtime session still has its workspace, task graph, cached tool connections, and retry queue. The mission no longer has a legitimate purpose.

If the harness only asks whether execution can resume, the agent may continue reading invoices, posting ledger adjustments, or sending vendor remittance notifications after the business condition that justified the delegation has ended. That is the IAM failure in its enterprise form: valid runtime continuity, stale delegated authority committing irreversible state.

Sub-agents amplify the collapse. The contract-comparison sub-agent inherits enough of the parent’s session to do its job: workspace state, tool connections, cached credentials, ambient access, and a place in the task graph. If the harness treats the session as the mission, the sub-agent inherits authority by ancestry. There is no governed attenuation, no separate approval surface, and no separate revocation handle. The runtime graph keeps executing while children wait on tool calls or spawn their own children.

The questions that matter are mission questions:

• Does the contract-comparison sub-agent need separate approval to access tenant data the parent has not touched before?
• Is the sub-agent still inside the original procurement scope, or has it expanded into a new domain?
• Do ledger adjustments and vendor notifications require fresh consent because they commit irreversible state?
• If the parent mission is revoked, do all children stop, including the ones mid-tool-call?

The runtime graph cannot answer those questions by itself. It only knows what is running and what depends on what. It does not know whether each delegation remains legitimate.

This is the same shape as the client instance attribution problem, seen from another angle. Sub-agents are actors with their own runtime identity. The mission they inherit must be explicit, attenuated, and separately governable, not an ambient property of descending from the same session.

OAuth has pieces for the cross-actor parts. RFC 8693 Token Exchange, Rich Authorization Requests, and identity assertion grants all involve explicit issuer participation. The Actor Profile individual draft proposes an interoperable profile for actor chains. But none of that helps if the harness never asks for an attenuated mission because it believes the parent’s session is sufficient authority for the child.

Attenuation has to be more than a smaller prompt. A child mission should be a strict subset of the parent mission, inherit an expiry no later than the parent, respect delegation-depth limits, carry its own actor identity, and terminate when the parent mission is revoked. Without strict-subset checks and cascade revocation, sub-agent delegation amplifies authority faster than logging can attribute it.

Open-world conditions amplify this further. As Part 1 of the Open-World OAuth series argues, tools are discovered dynamically, resources appear at runtime, and execution crosses trust domains that were not paired in advance. The runtime may still be alive when the mission is no longer legitimate, or when the current work has drifted beyond what was originally approved.

That is the territory Mission Shaping Part 2 covers. The older UCON model made the same continuity point in access-control terms: authorization conditions may need to hold during usage, not only at entry. Open-world execution makes the closed-world assumption visible by breaking it.

The Layered Model

Agent harnesses are distributed execution runtimes. The “chat session” framing is too small for what they do. Their runtime concerns define execution continuity. They do not define mission legitimacy.

The four systems of record introduced earlier are the spine of the architecture. Each owns a different question, and each is authoritative inside its own domain.

The core rule is one line.

Sessions preserve execution. Missions preserve legitimacy.

The control-plane reading is straightforward:

• Session state records runtime continuity. The harness owns it. Workspace, task graph, scratchpad, tool connections, queues, and retries all live here. Session state answers where the agent can continue working.
• Token state records whether a credential is currently usable at a protocol boundary. The authorization layer owns it. Tokens project bounded capabilities, with explicit expiry and forced re-engagement on refresh.
• Policy state records whether a particular request is permitted under current rules. The policy layer owns it. Policy is evaluated per request, not per mission.
• Mission state records whether the delegated mission itself remains legitimate. The Mission Authority Service owns it. It is the only layer that can answer whether the work the agent is doing is still authorized.

On resume, the harness restores the workspace and task graph, then reads the mission handle carried in session state. It asks the Mission Authority Service whether that mission is still active and whether the next planned step is still inside its bounds.

If the answer is yes, token refresh and policy evaluation can proceed. If the answer is no, queued work is canceled, child agents are interrupted, and the session remains recoverable but inert.

The layers compose at runtime. A consequential action has to answer three questions: is this credential currently usable, is this request permitted under current rules, and is the mission this work belongs to still authorized? Three different questions, three different state owners, three different failure modes. Conflating them at any layer means the wrong question is being asked at the wrong time.

The Mission Authority Service is the new layer. The other three already exist in mature IAM stacks. The session lives in the harness. The authorization layer lives in the AS or token issuer. The policy layer lives in the PDP. The Mission Authority Service sits above them as a control-plane object the rest of the stack consumes. It holds mission lifecycle and revocation state. It exposes an evaluable check that other layers call before issuing, before authorizing, before resuming. Write access is narrow, restricted to the principals who approved the mission and the policies that govern it. Read access is wide. Every enforcement point in the stack reads from it.

What the layers fail to do when conflated is specific. Tokens absorbed into mission produce the failure Mission-Bound OAuth Part 4 covers. Durable purpose gets smuggled into transport state. Policy absorbed into mission produces reconstruction-at-decision-time, where each PDP call rebuilds context that should already exist as durable state. Sessions absorbed into mission produce the failure mode this post is about. Each layer is good at its own question. None is good at the question above it.

Once those boundaries are named, the failure mode is specific. The mistake is not “agents need better governance” in the abstract. The mistake is letting one of the first three layers become the system of record for the fourth.

What the Harness Owes the Mission

Separating sessions from missions does not make the harness passive. It gives the harness a clearer job. Session resume must be contingent on mission validity. The mission is consulted on every path forward, not as a fallback when something else fails.

The session-as-mission collapse shows up as ordinary engineering shortcuts. Each one has a governed alternative.

The enforcement points are distributed. The harness checks before resume, retry, delegation, and tool invocation. The authorization server checks before issuing or refreshing tokens. A gateway, sidecar, or resource server checks before protected resource access. The orchestrator checks before queued work drains into external side effects. The Mission Authority Service does not replace those policy enforcement points. It gives each of them a common authority state to consume.

The failure semantics have to be explicit. Action classes should be policy-defined by reversibility, sensitivity, and business consequence. For low-risk reversible work, a harness may use a signed mission artifact or cached validity with a short maximum staleness window. For high-risk, irreversible, or materially consequential work, inability to establish mission validity should halt execution.

Revocation is also not a single event. Stopping new token issuance, revoking already-issued tokens, canceling queued operations, and interrupting in-flight tool calls are separate enforcement problems. A real mission layer has to define which of those happens for each class of action.

Mission state changes more than once. Termination is the simplest case. The harder cases happen mid-mission. Scope narrowing means some in-flight work is still in scope and some is not. Suspension means execution should pause but not roll back. Amendment may invalidate cached decisions while leaving the mission active. Expiry extension and condition tightening look like updates, not endings. Each transition has a different runtime consequence, and the Mission Authority Service has to distinguish them. The harness has to respond differently to each.

The runtime still owns execution. It decides how to checkpoint, retry, resume, schedule, and recover work. What changes is that resuming execution becomes contingent on mission validity. Resume is not evidence of validity.

Two defaults are possible at resume. Session-validated resume asks whether the runtime survived. If yes, work continues. The mission is consulted only on explicit failure. Mission-validated resume asks whether the mission is still valid. If the Mission Authority Service is unreachable or the answer is no, work pauses.

The two failure modes are different in kind. Session-validated resume loses authority quietly. The agent keeps working past mission end and audit logs look clean. Mission-validated resume loses progress noisily. The agent occasionally pauses when it was still authorized.

Visible failure modes can be tuned. Invisible ones cannot. Making session resume contingent on mission validity, not the other way around, is the architectural choice that pays off.

Resume is an execution decision. Reauthorization is a governance decision. Do not let one impersonate the other.

This is not an argument against resumable sessions, cached mission artifacts, or OAuth tokens. It is an argument against treating any of them as evidence that delegated authority still exists.

OAuth Hits the Same Wall

OAuth has a parallel version of this problem. OAuth is good at capability transport: token issuance, token exchange, sender constraining, scoped access, revocation, and introspection. It moves bounded authority across boundaries. It does not define durable mission continuity, runtime mission governance, or authority re-evaluation across sub-agent fan-out.

Tokens are projections of mission authority across a boundary. They are not the mission itself.

OAuth mechanisms provide useful rails around the edges: token revocation (RFC 7009), token introspection (RFC 7662), JWT access tokens (RFC 9068), sender-constraining with DPoP (RFC 9449) or mTLS (RFC 8705), and change-signal work such as Shared Signals Framework and CAEP. They help with credential state, sender binding, and revocation signals. None of them makes the harness session the right place to own mission legitimacy.

The fix is not only at the credential layer. It is in the protocol topology. The question shifts from “does OAuth solve this?” to “what protocol shape would?”

AAuth starts from a different shape. AAuth makes the separation an explicit design commitment in the proposed protocol topology. The agent server runs the work. The Person Server owns mission proposal, approval, lifecycle, governance, and audit. A clear boundary between runtime and mission.

The mechanism that matters is the issuance path. The agent proposes a mission to the PS. The PS approves it and returns an AAuth-Mission header carrying an approver identifier and a hash of the approved mission body. The agent attaches the header to subsequent resource requests. Token issuance routes back through the PS.

That topology is what makes mission-validated resume possible at the protocol level. A long-lived agent runtime cannot accumulate authority on its own. In the intended topology, credential refreshes, new tool capabilities, and cross-domain hops route back through the Person Server. When the mission terminates at the PS, new issuance stops wherever the PS sits on the path, regardless of whether the agent server’s runtime is still alive. The protocol topology forces the runtime to ask the question the architecture wants asked.

AAuth’s mission layer is still narrower than the full mission model. The remaining work is covered in AAuth Now Has a Mission Layer. For this post, AAuth has answered the where. The what is the harder question.

The Missing Layer

Agent systems have sessions, orchestration, memory, tool inventories, and runtime continuity. Resumable, recoverable, multi-agent runtimes are what make agent products useful.

What they lack is a durable governance layer that continuously answers one question:

Should this execution still be allowed to continue?

That layer is not a bigger context window. It is not a richer scratchpad, a longer-lived session, or a better sub-agent router. The runtime can keep improving without becoming the right place to answer that question.

Earlier posts built up that layer. An approved Mission records what was granted. A Mission Authority Service owns the state and evaluates whether the mission still holds. Protocol projection carries reduced views of that state across token and signal surfaces. A sub-agent attenuation model attributes each runtime actor inside the delegation graph. The harness does not need to own any of those layers. It needs to know that it does not own them.

A session that survives a laptop reboot is a useful runtime property. A mission that survives merely because the session survived is a governance bug. Agent platforms need to make session resume contingent on mission validity, not treat resume as evidence of validity.

Overnight, the harness wakes the session and finds the workspace, task graph, and tokens intact. None of that matters. Every path forward routes through the mission layer. The sub-agent’s retry loop wants to refresh its tokens, and the refresh routes through the Mission Authority Service. The service has marked the mission revoked. The next tool call needs an issued capability, and the issuer refuses to issue. The runtime has every piece of state it needs to continue. It does not have the authority to use any of it.

The future problem is not whether agents can continue running. It is whether they should.

Durable execution without durable governance is how autonomous systems silently inherit authority beyond the intent that justified it.

Sessions are not missions.