[Naveen Chatlapalli (1aifanatic)]

Motivation & Context

Two examples in agent_framework_orchestrations/_group_chat.py fail when copied.

GroupChatOrchestrator.__init__

• It passes participants=["researcher", "writer"]. The constructor takes participant_registry: ParticipantRegistry, which is built from executors, so the call raises TypeError: GroupChatOrchestrator.__init__() got an unexpected keyword argument 'participants'.
• Its selector returns state.participants[state.current_round % len(state.participants)]. GroupChatState.participants is an OrderedDict of name to description, so indexing it by position raises KeyError: 0.
• It also uses GroupChatState without importing it.

GroupChatBuilder.with_checkpointing

• It imports MemoryCheckpointStorage from agent_framework. That name doesn't exist; the class is InMemoryCheckpointStorage.

Description & Review Guide

• What are the major changes? Docstring examples only:
  • Rewrite the orchestrator example after samples/03-workflows/orchestrations/group_chat_simple_selector.py: select speakers by name with list(state.participants) and build the orchestrator through GroupChatBuilder(participants=..., selection_func=..., orchestrator_name=..., max_rounds=...), which constructs a GroupChatOrchestrator. This avoids importing the non-exported ParticipantRegistry.
  • Use InMemoryCheckpointStorage in the checkpointing example.
• What is the impact of these changes? Documentation only.
• What do you want reviewers to focus on? Whether the builder route is the right thing to show here. Constructing GroupChatOrchestrator directly needs ParticipantRegistry, which the package doesn't export; I can export it in a separate PR if you'd prefer the direct form.

I ran both corrected examples with a stub chat client. The orchestrator workflow contains a GroupChatOrchestrator named "Coordinator" and stops at max_rounds. The checkpointed builder workflow wrote checkpoints to InMemoryCheckpointStorage. I found these by type-checking the code examples in the package docstrings.

Related Issue

N/A - trivial change: docstring examples are corrected to the current constructor and class names, with no behavior change.

AI Assistance

• No material AI assistance was used.
• This is an AI-assisted contribution. I reviewed, understood, and verified all submitted content and accept responsibility for it.

AI assistance details: Claude Code helped find these by type-checking the docstring examples, run the corrected examples against a stub client, make the edits, and draft this description.

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR links to an agreed issue with no competing open PR, or the Related Issue section documents a trivial-change or repository-automation exception.
• This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

The new consumer-facing example uses a private import, violating the repository’s explicit public-import requirement.

1 open issue

• Use the public import path for ParticipantRegistry · New

What changed in this PR

This documentation-only PR updates two group-chat examples to match the current Agent Framework APIs, without changing runtime behavior.

Changes:

• Construct the orchestrator with agent executors and a participant registry, then build a workflow.
• Select speakers by participant name and import GroupChatState.
• Replace MemoryCheckpointStorage with InMemoryCheckpointStorage.

File	Description
python/​packages/​orchestrations/​agent_framework_orchestrations/​_group_chat.py	Corrects orchestrator construction, speaker selection, and checkpoint-storage docstring examples.

_{Review effort: Balanced}

[Naveen Chatlapalli (1aifanatic)]

Agreed — ParticipantRegistry isn't exported, and the constructor requires one, so there's no public way to call GroupChatOrchestrator(...) directly. Rather than widen the public surface in a docs PR, the example now uses the supported route: GroupChatBuilder(participants=..., selection_func=..., orchestrator_name="Coordinator", max_rounds=10), which builds a GroupChatOrchestrator internally. Ran it with a stub chat client: the built workflow contains a GroupChatOrchestrator named "Coordinator" and the run completes at max_rounds=10. If maintainers would rather export ParticipantRegistry, I can do that in a separate PR.