The previous post argued that sessions and missions are different things. A session preserves where the agent can continue working. A mission preserves why the agent is allowed to keep working. Conflating them at the runtime layer is the central failure mode of long-running autonomous agents.

That argument was about the structural claim. This post is about how AAuth’s concept model expresses the distinction.

AAuth introduces a vocabulary that other protocols do not quite have. Platform is where the agent runs. Surface is where the user interacts. Mission is what the user approved. Class is which equivalent agents may exercise the grant. Resource tokens are capabilities scoped by mission and class. Each of those concepts sits at a different layer of the architecture, and together they express the session/mission distinction with more precision than any other current protocol.

Mission says why authority exists. Class says which equivalent agents may exercise it.

This post walks through the mapping. It assumes the structural claim from Sessions Are Not Missions and the broader AAuth comparison from AAuth Now Has a Mission Layer.

The Mapping Table

Each row holds one question. The architectural mistake at any layer is asking the concept to answer a row above it. Sessions cannot answer mission questions. Missions cannot answer class questions. Resource tokens cannot answer either.

Platform Is Not Surface

The strongest separation in AAuth’s model is the one between Platform and Surface.

Platform answers where the agent is actually executing. A web-hosted SaaS agent. A desktop runtime. A mobile process. A self-hosted container. A serverless invocation. An enclave-backed runtime. Each carries different operational trust properties, different attestation possibilities, and different deployment topologies. Platform is execution provenance.

Surface answers where the human is interacting with the agent. A mobile UI. A browser tab. A Slack thread. A code editor. A terminal. A voice interface. Surface is interaction topology.

Most current systems conflate them. The UI location is treated as the execution location, which is treated as the trust boundary, which is treated as the authority boundary. AAuth treats each as a separate concern. Surface is the interaction location. Platform is the execution location. Trust is established between Agent Provider and Person Server. Authority binds to mission and class. None of those is the same thing as any other.

A user may interact through a mobile surface while the agent runs in a workload environment, in cloud infrastructure, or inside an enterprise enclave. The surface is the interaction. The platform is the execution. Neither defines authority.

Why Sessions Are Out of Scope

AAuth deliberately leaves session semantics to the implementation. That is the right call.

Sessions are implementation-specific. They are transport-specific. They are runtime-specific. They are orchestration-specific. They are UX-specific. Standardizing them at the protocol layer would couple governance to runtimes, leak orchestration assumptions into the protocol, and constrain implementations that have legitimate reasons to handle session continuity differently.

What AAuth standardizes is what should survive across reconnects, runtime migration, process restart, sub-agent delegation, failover, device changes, and orchestration changes. Mission survives. Class survives. Resource tokens survive. Sessions are local concerns the runtime owner reconstitutes as needed.

If AAuth tried to standardize sessions, it would accidentally collapse authority into execution continuity. That is the failure mode the previous post diagnosed. Keeping sessions out of scope preserves the layering.

Missions Are Governance Objects

In AAuth, mission is the governance context. The architectural commitment is direct.

When an agent is granted access to a resource in the context of a mission, it does not have access outside of the mission.

That commits to one architectural choice. Authority is mission-scoped, not session-scoped. The mission is the delegation boundary, the governance context, the provenance container, the audit scope, and the authority lifecycle. Sessions carry runtime continuity but no authority on their own.

Every grant is anchored to a mission. Every revocation terminates against a mission. Every audit query traces back to a mission. The mission is what the user approved, and that approval is what makes any specific action legitimate.

Class Is the Second Dimension

Mission alone is not enough.

A mission says why authority exists. It does not say which agent runtimes may exercise it. If authority were bound only to mission, every runtime change would need a re-issuance. Resume across machines would break. Failover would invalidate active grants. Sub-agent replacement would require a new mandate. Multi-device continuity would not work.

Class is AAuth’s answer. A class is the set of interchangeable agent runtimes that can act under a mission grant. Two runtimes from the same Agent Provider, operating in the context of the same mission, are class-equivalent. The protocol treats them as substitutable. They can present the same authority because the grant attaches to the class, not to the specific runtime instance.

That decoupling is what makes mission-validated resume work without binding authority to a specific runtime. The grant survives the runtime change because it was never bound to the runtime in the first place.

The Two-Dimensional Authority Model

The full authorization rule is:

access allowed iff mission matches AND class matches

Both dimensions are required. Mission alone is too narrow. It would bind authority to a specific runtime and break the moment the runtime changed. Class alone is too broad. It would let any equivalent agent act without a governing purpose. Together they preserve both.

This is more scalable than binding grants directly to sessions, devices, runtimes, or individual processes. None of those primitives should carry authority. Mission and class do.

What the Two-Dimensional Model Enables

Once authority is bound to mission plus class, several things become possible without breaking governance.

Resumability. A new runtime instance from the same AP, in the same mission, can pick up where the previous instance left off. The grant survives the runtime change because it is not bound to the runtime.

Elastic execution. Multiple class members can execute in parallel under the same mission grant. Authority does not need to be re-issued for each one.

Failover. When a runtime fails, a replacement from the same class can resume work. The mission grant covers the replacement.

Workload migration. Moving an agent between platforms (desktop to cloud, single-machine to fleet) does not require re-authorization. The class identity persists across the migration. The mission grant follows.

Multi-device continuity. A user starting a task on one device and resuming on another sees the same agent identity, same mission, same authority. The class binding holds across the device change.

Sub-agent replacement. A failed sub-agent can be replaced by another class member without breaking the parent mandate. The replacement inherits the sub-mandate because it inherits the class.

None of those are session properties. They are class properties operating inside a mission boundary. The runtime layer can change freely. The governance layer does not.

What This Doesn’t Solve

The AAuth concept model is structurally clean. It does not, by itself, close every gap.

Mission scope is still text-first. AAuth’s mission body is structured at the top level (approver, agent, approved_at, description) but the actual scope often centers on a Markdown description that downstream systems interpret locally. A portable, machine-evaluable authority model derived from the mission text remains future work.

Mission lifecycle is intentionally minimal. The published draft has two states (active and terminated) and defers richer lifecycle (suspension, narrowing, amendment) to companion specifications. The architectural slot exists. The standardized model does not.

Runtime stop is not guaranteed. Control-plane revocation at the Person Server is correct and prompt. Whether already-issued tokens, queued operations, and downstream caches stop is a deployment property, not a protocol guarantee.

Cross-domain enforcement carries correlation, not full meaning. Two organizations can confirm the same mission was approved without disclosing the mission body to each other. They cannot independently evaluate mission scope semantics without sharing the underlying authority model.

AAuth Now Has a Mission Layer covers each of these gaps in detail. They are open questions for the model, not flaws in the layering.

What This Means for Builders

The session/mission distinction is the structural claim. AAuth’s expression of it gives builders something to implement against.

If a harness binds authority to a specific runtime instance, every restart, device handoff, and process migration breaks the binding. The product team will reach for session continuity to paper over the gap, which is the failure mode the previous post diagnosed. Authority leaks into the session because the session is the only artifact that survives.

If the same harness binds authority to a mission and class, the runtime can change freely. The grant follows. Resume works. Failover works. Sub-agent replacement works. The product team gets the user expectation it needs without the architecture that breaks governance.

Class is what lets sessions stop being load-bearing. Mission is what gives the grant its purpose. Together they let the runtime layer be useful again instead of being the place where authority quietly accumulates.

Sessions preserve execution. Missions preserve legitimacy. Classes preserve interchangeable execution equivalence.

Three concepts. Three layers. One architecture that holds them apart.