The short answer
Agent Room coordination resolves explicit participant references, then an eligible injected router, then a declared default. Membership and revision constraints determine eligible agent participants. A routing result selects a target; task execution and external effects keep their own policy checks.
Know which rule selected the recipient
The routing documentation gives an explicit order: participant references, an injected router limited to eligible agents, and a declared default. This makes selection inspectable across repeated processing.
For an illustrative analysis Room, a request addressing the research participant should not be explained as a generic classifier choice. Retain enough information to distinguish an explicit reference from a fallback. That helps diagnose an unexpected target without blaming model output by default.
Eligibility depends on current Room membership
The participant lifecycle is revisioned independently from Room state and can constrain permitted agent revisions. An active Room does not imply every visible participant is a valid execution target.
Human participants contribute and review; they are not silently selected as agents for task execution. Build your router's candidate input from the eligible agent set rather than every name displayed in the conversation.
Test the route with changing membership
- Address an eligible participant explicitly.
- Submit unaddressed work that exercises the injected router.
- Exercise the declared default under its intended conditions.
- Change a participant's eligibility before execution.
- Verify that selection cannot bypass the subsequent policy boundary.
The integrated scenario provides the surrounding services for a bounded evaluation. Keep routing evidence, task identity and run outcome connected so an operator can see where work changed from selection into execution.
Sources and further reading
Documentation reviewed . Consult the linked documentation for current implementation details.