Problem
agmsg identities are keyed by (team, agent name), while project path and agent type are metadata. That makes the agent name operationally important.
In practice, first-run onboarding currently asks the user to choose a team name and an agent name, but it does not show the existing team roster or suggest an unused name. This makes it easy to pick weak names like codex / cc, which only describe the tool type and become ambiguous as soon as multiple Codex or Claude Code sessions exist.
The same issue appears around �ctas and spawn: users need a good, unused role/name, but the tool currently expects them to invent one without seeing what is already occupied.
Proposed UX
Before first join, �ctas creation, or spawn flows, agmsg could provide roster-aware name help:
- Show the current team roster, including name, agent type, and project path.
- Extract already-used names for that team.
- Suggest 3-5 unused names from a bundled name pool.
- Allow the user to accept a suggestion or type a custom name.
- Continue with join, �ctas, or spawn as usual.
Example:
` ext
Current members in mathdesk-desktop:
- tycho codex /c/dev/MathDesk
- hypatia claude-code /c/dev/MathDesk
Suggested available names:
- noether
- lovelace
- ada
- turing
- gauss
`
Naming model
Suggested names should be identity names, not tool labels.
Good:
ext tycho, hypatia, noether, lovelace, ada
Metadata remains separate:
ext type = codex / claude-code / gemini / ... project = /path/to/project role note = reviewer / implementer / planner / observer
Name pool
A static bundled pool would be enough. Even a few hundred to ~1000 names would probably cover normal local-team usage. The pool could include names from mathematics, science, engineering, astronomy, literature, etc., ideally with enough diversity to avoid a narrow cultural bias.
Why this matters
Without this, the user has to design identity hygiene manually at the exact moment they have the least context. Since agmsg supports multiple peer sessions and multiple roles per project, weak names quickly make routing unclear.
Roster-aware suggestions would make the happy path much safer:
- fewer ambiguous identities like codex / cc
- fewer accidental duplicate/near-duplicate roles
- easier multi-agent rooms
- better first-run experience without adding a daemon or changing the storage model
Notes
This request is about onboarding and identity UX only. It should not require changing the underlying (team, name) identity model.
Problem
agmsg identities are keyed by (team, agent name), while project path and agent type are metadata. That makes the agent name operationally important.
In practice, first-run onboarding currently asks the user to choose a team name and an agent name, but it does not show the existing team roster or suggest an unused name. This makes it easy to pick weak names like codex / cc, which only describe the tool type and become ambiguous as soon as multiple Codex or Claude Code sessions exist.
The same issue appears around �ctas and spawn: users need a good, unused role/name, but the tool currently expects them to invent one without seeing what is already occupied.
Proposed UX
Before first join, �ctas creation, or spawn flows, agmsg could provide roster-aware name help:
Example:
` ext
Current members in mathdesk-desktop:
Suggested available names:
`
Naming model
Suggested names should be identity names, not tool labels.
Good:
ext tycho, hypatia, noether, lovelace, adaMetadata remains separate:
ext type = codex / claude-code / gemini / ... project = /path/to/project role note = reviewer / implementer / planner / observerName pool
A static bundled pool would be enough. Even a few hundred to ~1000 names would probably cover normal local-team usage. The pool could include names from mathematics, science, engineering, astronomy, literature, etc., ideally with enough diversity to avoid a narrow cultural bias.
Why this matters
Without this, the user has to design identity hygiene manually at the exact moment they have the least context. Since agmsg supports multiple peer sessions and multiple roles per project, weak names quickly make routing unclear.
Roster-aware suggestions would make the happy path much safer:
Notes
This request is about onboarding and identity UX only. It should not require changing the underlying (team, name) identity model.