---
title: "Sessions Are Not Missions"
date: "2026-05-07T10:00:00-07:00"
lastmod: "2026-05-07T10:00:00-07:00"
description: "Resumable agent sessions preserve execution continuity. They do not preserve authority. Long-running agents need a mission layer that can decide whether execution should still be allowed to continue."
summary: "Modern agent harnesses make work durable across restarts, devices, background jobs, and sub-agents. That durability is a runtime property, not a governance property. A session answers where the agent can continue working. A mission answers why the agent is allowed to keep working. Conflating them is a central failure mode of long-running autonomous agent systems."
slug: "sessions-are-not-missions"
tags:
  - "Agentic Identity"
  - "Delegated Authority"
  - "IAM"
  - "OAuth"
  - "Authorization"
  - "Security Architecture"
  - "Sessions"
  - "MCP"
---


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 mandate 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](/series/you-dont-give-agents-credentials-you-grant-them-power-of-attorney/), [Mission Shaping](/series/mission-shaping/), and [Mission-Bound OAuth](/series/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.

| Session preserves | What that means in practice |
| --- | --- |
| Interaction state | Conversation context the model needs to keep reasoning |
| Execution checkpoints | Where the task graph paused |
| Scratchpad memory | What the agent learned during this run |
| Workspace state | Files, repos, branches, and generated artifacts |
| Tool context | MCP servers, APIs, connectors, and discovered tools |
| Cached credentials | Tokens still inside their usable window |
| Orchestration state | Queues, retries, async jobs, and sub-agent handles |

A well-built session survives a long list of disruptions. The harness sees them and recovers. What it does not see is that the mission may be experiencing a different set of events at the same time.

| Session-layer event | Mission-layer event |
| --- | --- |
| Process restart | Approval revoked |
| Token refresh | Release branch frozen |
| Device handoff | Scope narrowed by reviewer |
| Model upgrade | New risk signal raised |
| Workspace recovery | Budget exceeded |
| Sub-agent retry | User intent changed |

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.

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 a necessary question for any useful agent harness. It is not the governance question.

# A Mission Answers "Why Is the Agent Allowed to Keep Working?"

A mission is a governance construct. It preserves the legitimacy of delegated work across the things that change after approval.

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

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

A mandate 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, and 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. Mandate 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 mandate behind the runtime is still legitimate. That is the distinction the [Execution Mandate post](/notes/from-passports-to-power-of-attorney/) draws between identity, access, delegation, and authority.

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

# The Failure Mode

The dangerous assumption under many agent harnesses is simple:

> Execution continuity equals authority continuity.

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.

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](/notes/governing-the-stay-not-just-the-entry/) 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.

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 mandate 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](/notes/client-instances-are-actors-not-new-clients/), 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](https://datatracker.ietf.org/doc/html/rfc8693), [Rich Authorization Requests](https://datatracker.ietf.org/doc/html/rfc9396), and [identity assertion grants](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/) all involve explicit issuer participation. The [Actor Profile individual draft](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-profile/) proposes an interoperable profile for actor chains. But none of that helps if the harness never asks for an attenuated mandate because it believes the parent's session is sufficient authority for the child.

Attenuation has to be more than a smaller prompt. A child mandate should be a strict subset of the parent mandate, inherit an expiry no later than the parent, respect delegation-depth limits, carry its own actor identity, and terminate when the parent mandate 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](/notes/oauth-for-open-world-ecosystems/) 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 mandate is no longer legitimate, or when the current work has drifted beyond what was originally approved.

That is the territory [Mission Shaping Part 2](/notes/mission-shaping-is-not-enough/) covers. The older [UCON model](https://dl.acm.org/doi/10.1145/984334.984339) 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.
- **Mandate state** records whether the delegated mission itself remains legitimate. The mandate 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 mandate handle carried in session state. It asks the mandate service whether that mandate 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 mandate 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 mandate 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](/notes/why-mission-bound-oauth-might-be-the-wrong-answer/) 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 mandate 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.

| Anti-pattern | Governed alternative |
| --- | --- |
| Using the session ID as the mission ID | Carry a mandate handle in session state. Never treat its presence as proof of validity. |
| Treating token refresh as continuing consent | Re-check mandate state on every issuance and refresh, including background-job refreshes. |
| Letting sub-agents inherit parent sessions wholesale | Issue an attenuated child mandate before spawning any sub-agent with new tools, resources, or side effects. |
| Revoking only the visible UI session | Cascade revocation to child agents, queued work, and in-flight tool calls. |
| Checking approval only at task start | Check mandate state before any irreversible action, privilege change, cross-domain call, or token refresh. |
| Logging tool calls without mission lineage | Tag every session event with the mission identifier so audit links runtime behavior to approved authority. |
| Continuing on cached mandate state when the mandate service is unreachable | Fail closed for high-risk actions when validity cannot be confirmed. |

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 mandate 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 mandate artifact or cached validity with a short maximum staleness window. For high-risk, irreversible, or materially consequential work, inability to establish mandate 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 mandate 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 mandate is consulted only on explicit failure. Mission-validated resume asks whether the mission is still valid. If the mandate 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 mandate 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](https://datatracker.ietf.org/doc/html/rfc7009)), token introspection ([RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662)), JWT access tokens ([RFC 9068](https://datatracker.ietf.org/doc/html/rfc9068)), sender-constraining with DPoP ([RFC 9449](https://datatracker.ietf.org/doc/html/rfc9449)) or mTLS ([RFC 8705](https://datatracker.ietf.org/doc/html/rfc8705)), and change-signal work such as [Shared Signals Framework](https://openid.net/specs/openid-sharedsignals-framework-1_0.html) and [CAEP](https://openid.net/specs/openid-caep-specification-1_0.html). 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](https://datatracker.ietf.org/doc/draft-hardt-oauth-aauth-protocol/) 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 narrower than the full mission model. Mission scope is text-first. Lifecycle is minimal. Runtime stop across already-issued tokens, queued operations, and downstream caches is not guaranteed. Cross-domain enforcement carries correlation, not full meaning.

These gaps are easier to see because AAuth already separates the runtime owner from the mission owner. The earlier post [AAuth Now Has a Mission Layer](/notes/aauth-now-has-a-mission-layer/) covers the full comparison. The remaining work is what the mission object means and how strongly its state propagates. 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](/notes/the-mission-shaping-problem/) records what was granted. A [mandate service](/notes/governing-the-stay-not-just-the-entry/) owns the state and evaluates whether the mission still holds. [Protocol projection](/series/mission-bound-oauth/) carries reduced views of that state across token and signal surfaces. A [sub-agent attenuation model](/notes/client-instances-are-actors-not-new-clients/) 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 mandate 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.

Sessions are not missions.