The distinction between “who is the agent?” and “what is it allowed to do?” is the part I’d underline. Identity solves attribution, but authorization has to be evaluated at the action boundary, otherwise you just end up with a perfectly auditable agent that is still over-privileged.

The “working for a person vs. working for itself” split is also a useful design decision to make before choosing the token flow. In production agentic systems at IT Path Solutions, that distinction affects delegation, scope, expiry, audit trails, and especially how much authority survives a handoff between agents.

The multi-hop section exposes the harder problem: carrying delegation metadata is not the same as being able to trust it. Until every hop can independently reduce authority and the final system can establish who actually approved the consequential action, adding more agents mostly increases the ambiguity in the audit trail.