The symptom
In the August 2026 office hours, "AAuth still works without a person server — agent token only" had to be said out loud as a clarification, to an audience already deep in the material.
That is a bad sign. It means the site is landing AAuth as one thing you either adopt whole or not at all, when it is a ladder you can stop climbing at any rung. Anyone who concludes "I need to run a person server to use this" is going to close the tab.
What the ladder actually is
The protocol defines five resource access modes, ordered by what the resource ends up knowing and which party established it:
- Agent identity (
agent-token) — the agent signs with its agent token. The resource knows which agent. No person server anywhere.
- Resource-managed (
session-token) — the agent completes the resource's own consent flow and gets a session token back. The resource keeps its existing authorization; AAuth is doing key-bound authentication.
- Person identity (
person-token) — the resource learns which person, PS-asserted, and applies its own access control. Federated login for agents. The PS is not in the per-call path.
- PS authorization (
auth-token, three-party) — the person server decides.
- Federated authorization (four-party) — the resource's own access server decides, with the PS in the loop.
A resource can also apply different modes to different endpoints, which is the shape most real deployments will want: most calls on identity, a few sensitive ones on an authorization decision.
What to add
A page that answers "what do I actually have to run?" — organized by what the reader already has, not by what the protocol offers:
- I have an API and I want to stop issuing API keys. Rung 1. What changes: verify HTTP Message Signatures, publish one well-known document. What you get: a key-bound caller identity that cannot be replayed, stolen from a log, or pasted into a config file.
- I have an API with existing login and authorization. Rung 2. Keep your authorization; AAuth replaces the credential.
- I want to know which person, without building agent login. Rung 3.
- I want someone else to make the authorization decision. Rungs 4 and 5.
For each: what you implement, what you do not implement, and what you can defer. The "do not implement" column is the one that will change minds.
Then say the thing directly: you do not need a person server to adopt AAuth, and a person server is not something most resources will ever run. It is the agent's side of the relationship, not the resource's.
Related: #9 (agent protocol positioning) and #8 (OIDC bridge) are the other two "where do I fit" gaps from the same session.
The symptom
In the August 2026 office hours, "AAuth still works without a person server — agent token only" had to be said out loud as a clarification, to an audience already deep in the material.
That is a bad sign. It means the site is landing AAuth as one thing you either adopt whole or not at all, when it is a ladder you can stop climbing at any rung. Anyone who concludes "I need to run a person server to use this" is going to close the tab.
What the ladder actually is
The protocol defines five resource access modes, ordered by what the resource ends up knowing and which party established it:
agent-token) — the agent signs with its agent token. The resource knows which agent. No person server anywhere.session-token) — the agent completes the resource's own consent flow and gets a session token back. The resource keeps its existing authorization; AAuth is doing key-bound authentication.person-token) — the resource learns which person, PS-asserted, and applies its own access control. Federated login for agents. The PS is not in the per-call path.auth-token, three-party) — the person server decides.A resource can also apply different modes to different endpoints, which is the shape most real deployments will want: most calls on identity, a few sensitive ones on an authorization decision.
What to add
A page that answers "what do I actually have to run?" — organized by what the reader already has, not by what the protocol offers:
For each: what you implement, what you do not implement, and what you can defer. The "do not implement" column is the one that will change minds.
Then say the thing directly: you do not need a person server to adopt AAuth, and a person server is not something most resources will ever run. It is the agent's side of the relationship, not the resource's.
Related: #9 (agent protocol positioning) and #8 (OIDC bridge) are the other two "where do I fit" gaps from the same session.