FACTUAL ACTIVITY RECORD · An activity record based on work that took place
Centralizing AI-talent display identity in definitions
Mapping changing runtime names to stable agent keys and rendering official profiles through one source
Purpose
Restarting the same AI talent could append a sequence to its runtime nickname, changing the displayed name and introduction even though it was the same identity. Conversation grouping used definitions, but known-profile detection in the interface still depended on matching hardcoded names.
The goal was to retain runtime nicknames as execution history while aligning the official displayed name, role, and description with a stable agent key and database definition, so multiple executions appear as one AI talent.
Implementation
AI-talent identity manifest defines the official nickname, role, and description for ten talents including Mako. The Connector combines this manifest with executable agent configuration into codex_agent_definitions, which the interface reads as the display source of truth.
- The main agent uses
agent_key = "main"and follows the same retrieval path as custom agents. - Runtime nicknames such as
ritsu the 2ndare normalized to their original stable definition. - The official displayed name comes from the definition nickname, with presentation capitalization applied by the interface.
3D-state mapper matches execution data in threads to agent definitions and unifies multiple sessions with the same agent key under one display identity. The special hardcoded-profile path for Mako was removed.
3D application presentation and 3D scene presentation now display the official name, role, and description from the snapshot profile. Remaining hardcoded role and description copy was removed from the UI, while portrait, 3D model, height, and idle message remain application-side visual metadata.
- A defined AI talent appears as the same person even when its runtime nickname changes.
- Only undefined dynamic agents receive fallback profiles from execution-time information.
- Runtime names retained in conversation history are not rewritten, keeping execution evidence separate from display identity.
Portrait and office-mapping tests were expanded for multiple sessions of one AI talent, the main agent, all ten definitions, undefined agents, and numbered nicknames. Live data was also inspected to confirm that multiple sessions appeared as one talent in the interface.
Display identity moved from runtime nicknames to a profile manifest keyed by stable agent keys. Runtime history names remain available while UI presentation resolves through definitions.
Rendering diagram…
What was confirmed
Verification results
Twenty-five tests, TypeScript type checking, ESLint, and the production build passed.
Ten definitions including Mako were retrieved from the database and reflected in official names, roles, and descriptions.
Across 18 child tasks in live data, two Ritsu sessions containing seven messages were unified into one displayed Ritsu.
Numbered runtime names no longer appeared in the interface, while fallback for undefined agents remained available.
At the cutoff, definition-driven display identity had been applied to the target. Moving portrait and 3D-model visual metadata into the database was outside this scope.
Basis for completion
The work was complete when profiles for all ten talents, normalization to stable keys, database-derived display, and dynamic fallback were present, multiple-session tests and live-data checks passed, and the result was applied to the target.