The short answer
The Agent Definition Registry separates a stable agent identity from immutable content-addressed revisions. A Room execution session accepts an eligible published revision matching its assigned participant and runtime profile, then retains the revision and digest for replay.
A stable name is not an execution definition
A team may keep calling an agent “Researcher” while changing its instructions, runtime profile or available knowledge. The display name remains useful, but it cannot explain which definition produced yesterday's result.
The registry lifecycle documentation distinguishes stable identity from immutable content-addressed revisions. This lets the application preserve the definition used by a run while continuing to evolve the agent for future work.
Publication is a lifecycle transition
Agent revisions move through draft, published and deprecated states using compare-and-set updates. Publication is therefore more than editing a label in the user interface.
For an illustrative research agent update, create the successor definition, review it under your application process and publish the intended revision. Do not rewrite the old revision to make historical results appear to have used the new instructions. Preserve the old reference so a reviewer can explain what changed between outputs.
Execution must match the assigned participant
A session requires a published revision whose identity and runtime profile match the assigned Room participant. Participant membership can also constrain allowed revisions and routing eligibility.
The session reference records the exact agent revision alongside authority and role revisions. Your interface can use those separate coordinates to distinguish a definition change from a change in permission. Publishing a definition should not be interpreted as granting every participant permission to execute it.
Preserve revisions through delegation and recovery
Typed Handoffs bind source and target revisions. A transfer to a specialist should identify the definition accepted for that work rather than resolving an unspecified “latest” revision later.
Likewise, a recovery investigation should show the predecessor run and the revision involved in the successor. If an operator wants to change the task or definition, make that decision explicit through the supported lifecycle rather than hiding it inside retry code.
Expose enough identity for a meaningful review
- Show the stable agent identity for navigation.
- Retain the exact revision and digest in execution evidence.
- Display whether a candidate revision is published and eligible.
- Handle stale publication transitions as conflicts.
- Keep historical artifacts linked to their original run.
The optional registry API supplies revision and lifecycle routes when configured. Test your host against those exact contracts; a visually updated agent profile is not evidence that every active or future execution has adopted the new definition.
Sources and further reading
Documentation reviewed . Consult the linked documentation for current implementation details.