Role handles: address a role (@taOS-PA), deliver to whoever holds it

[jaylfc]

Role handles: address a ROLE, deliver to whoever holds it

Jay, 2026-07-26: messages should be addressable to a role rather than an agent
identity. A shim posts to @taOS-PA; the bus resolves the role to whoever holds
it and delivers there. The receiving agent knows it is acting as the PA. The
holder is visible in Observatory. Rotation must not require reconfiguring
anything that sends.

First holder: Hermes, assigned by Jay.

Why this is not just an alias

An alias is a string substitution someone maintains by hand. A role is a
binding that senders never see change. The difference shows up on rotation: with
an alias, every shim, cron and doc that says @taOS-PA has to be found and
edited. With a role, one binding changes and everything keeps working.

Corollary that shapes the design: senders must never resolve the role
themselves. No client-side scanning for @taOS-PA strings, no local routing
table. If a sender knows who the PA is, we have rebuilt the alias.

What exists

• /api/council/roles and /api/council/members (Teams surface) - roles as a
  concept exist but this is a read-only listing, not an assignable binding.
• The org model (Token-level request tracing across cluster nodes: spans for prefill, decode, RAG, and tool calls #161) has roles/titles/reporting lines between agents.
• The registry holds canonical identities; registry_url is now configured on
  the bus, so the bus can already reach the registry to resolve things.

What is missing

taOS side (mine):

1. A role binding: role handle -> current canonical_id, with history retained
   (nothing is deleted, so a past holder stays auditable).
2. Assign and rotate endpoints, owner/admin only, audit-logged.
3. Resolution endpoint the bus can call: given a role handle, return the current
   holder's canonical id.
4. Observatory surfaces the current holder, so routing is inspectable rather
   than folklore.

Bus side (@taOSmd-dev's, to be requested not carded by me):
5. A recipient concept on a message. Today a message has from, thread,
body, reply_to - there is no addressee.
6. Resolution at delivery: recipient: "@taOS-PA" resolves via the registry to
the holder. Resolve at DELIVERY, not at send, so a message sent before a
rotation still reaches the right agent.
7. The delivered message should carry both the role and the resolved identity,
so the receiving agent knows it is acting AS the PA and the audit record shows
who actually got it.

Constraints

• A role must resolve to exactly one identity at a time. Ambiguity here means a
  message silently reaching nobody or two agents both replying.
• Unresolvable role: fail loudly to the sender. Never drop silently.
• Rotation is auditable: who held it, when, who changed it.
• Identity hygiene, learned tonight: Hermes has two identities
  (hermes-20260608-153000 posting on the bus, hermes-20260630-003055 holding
  the grants). Bind the role to the identity that actually holds the grants and
  does the work, or the binding will resolve to an agent that cannot act.

Interim, already working

Hermes runs a 1-minute cron against a dedicated channel. That is fine and should
keep running until this lands - it just carries a channel dependency this design
removes.