RFC: Agent identity / persona layer — generated per-user, not committed?

[msitarzewski]

Opening this to move the discussion from #645 (thanks @Axer-wyh) into the open, where a direction decision belongs.

The proposal (from #645)

An identity layer for the roster: each agent gets a stable display name, a role glyph, a generated 128×128 avatar, and a short fictional persona (background, memory, hobbies, selfIntroduction). #645 implements it as a committed 4,850-line agent-identities/glyph-v3.json covering all 218 agents, plus a dependency-free Node generator for the avatars. The work is genuinely careful — no bulk edits to agent files, no committed image output, uses divisions.json colors.

Why this is a direction question, not a merge

The concept has real appeal for UIs — pickers, sidebars, roster cards. But baking one canonical identity set into the repo runs into a core issue:

Each consumer will want their own version. An installer, the desktop app, a sidebar roster, and someone's internal tool will each want different names, art styles, tones, and persona depth (or none at all). There is no single "Juno Chen is the Anthropologist" that's correct for everyone — that's a branding decision that belongs to whoever is building the surface, not to the shared catalog.

That points away from a committed manifest and toward generation: ship the recipe (a deterministic generator that reads the existing divisions.json + agent frontmatter), and let each consumer generate the identity set they want, the way we already treat integrations/ output as generated-not-committed.

Concretely, a committed manifest also carries costs we've been actively working to remove elsewhere in the repo:

• Drift. A 218-entry parallel roster has to stay in lockstep with the real agents, and nothing enforces the sync — every new agent silently makes it stale. (We just spent effort deleting the last hardcoded copy of the division list for exactly this reason.)
• A new toolchain. The repo is bash + PHP with no build step; a persisted identity system adds a Node surface to maintain.

What I'd love input on

1. Is an identity/persona layer something people actually want from this repo, or is it better left to each downstream consumer?
2. If wanted: generator-only (ship the script + schema, output stays uncommitted/per-user) vs. a committed canonical set?
3. Do the fictional personas (invented names, memories, hobbies) fit the project's positioning, or is the useful part just the deterministic glyph/avatar + display metadata?

My lean: the glyph/avatar + display-metadata idea is worth exploring as a generator that consumers run on demand; the committed fictional personas I'd leave out. But this is exactly the kind of cross-roster call worth deciding together — so, thoughts welcome.

[Axer-wyh]

Thank you for moving this into a discussion, and for such a thoughtful review of the PR. I agree with the central point: a single committed identity set would turn a consumer-facing branding choice into canonical catalog data, while also creating a second roster that could drift from the agents themselves.

Generating identities on demand feels like a much better boundary. It keeps the useful part of the idea -- one agent having a coherent, recognizable identity in a UI -- while letting each installer, app, or team decide what that identity should look and sound like.

Based on your proposal, I could imagine the implementation taking this shape:

1. Use the existing roster as the only source of truth. At generation time, read divisions.json and each agent's frontmatter to derive the stable agent ID, division, role, specialty, and division color. No parallel 218-entry manifest would be maintained by hand.

2. Make generation deterministic but consumer-specific. Accept a consumer-controlled seed together with options such as style, locale, and personaDepth. The same agent source data + seed + generator version should reproduce the same identity; changing the seed should produce a different roster for another product or user.

3. Write only generated output. Produce an identity manifest plus avatar assets in a caller-selected, ignored output/cache directory. The manifest could include the generator version and a digest of the source roster, so consumers can tell when their generated identities are stale and regenerate automatically.

4. Keep rendering replaceable. The current pixel-glyph renderer could be one preset, using division colors and deterministic role glyphs, while consumers could provide another renderer or art style. SVG with crisp pixel geometry could be a lightweight base output, with PNG rendering left to consumers that need it.

5. Treat fictional personas as optional generation, not project canon. I still think background, memory, hobbies, and a short self-introduction can be valuable in agent pickers and profile views, but I agree they should not assert that, for example, one invented person is the official Anthropologist. A none | light | full persona mode could let consumers omit this layer, generate a small deterministic profile offline, or plug in their own richer/LLM-backed provider downstream.

6. Avoid imposing a new required toolchain. If Node is not a good fit for the core repo, the repository-owned surface could be limited to a small versioned schema/recipe and an implementation compatible with the existing tooling. The current Node generator can still serve as a prototype or downstream reference rather than becoming a required build step.

That would make the identity layer closer to a reproducible recipe than a canonical dataset. It also gives new agents a path automatically: once an agent exists in the roster, the next generation run includes it without someone manually updating a second list.

I would be happy to reshape the current generator around this model after the direction is agreed. Thanks again for separating the architectural question from the implementation review -- the on-demand/per-user framing is stronger than the original committed-manifest approach.