[Manohar Paturi (ManoharPaturi)]

Motivation & Context

The base group chat contract says a max round count below 1 is coerced to 1. Magentic assigns its round limit from manager.max_round_count after super().__init__, which bypasses that rule, so a limit of 0 ends the workflow at the first limits check before any coordination round or participant turn happens.

Description & Review Guide

• What are the major changes? The assignment now applies the same coercion the base class uses when the value is set.
• What is the impact of these changes? A limit below 1 now yields exactly one coordination round before the limit ends the run, matching GroupChatOrchestrator. Values of 1 or higher and None behave as before.
• What do you want reviewers to focus on? The test counts progress ledger creations to show one round runs before termination.

Related Issue

Fixes #9500

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.

[Eduard van Valkenburg (eavanvalkenburg)]

The change restores the BaseGroupChatOrchestrator round-limit contract before Magentic's first limits check, and the regression demonstrates that one coordination round runs instead of terminating immediately.

[Manohar Paturi (ManoharPaturi)]

The Public API Compatibility check fails on every open PR in this repo right now (e.g. #9602, #9607, and all of this author's open PRs), so it looks like a repo-wide CI issue rather than something introduced by this change.

The job crashes inside griffe while loading the base (main) snapshot, before it compares the PR changes — the traceback points at the base copy of the package:

griffe._internal.exceptions.AliasResolutionError: Could not resolve alias
agent_framework._workflows._edge.EdgeGroup.builtin_type pointing at builtins.type
(in /tmp/python-api-base-.../python/packages/core/agent_framework/_workflows/_edge.py:315)

Example run: https://github.com/microsoft/agent-framework/actions/runs/39810016173/job/119933441343

None of the changes in this PR touch _workflows/_edge.py. Filed an issue for the CI failure; happy to help debug if useful.

[Manohar Paturi (ManoharPaturi)]

Eduard van Valkenburg (@eavanvalkenburg) the failing Public API Compatibility check was the repo wide griffe crash on the base snapshot, and that is fixed on main now: every API compat run since, including four on my other PRs today, passes. 9798ecf merges current main so the check re-runs against the healthy base, and the branch was out of date anyway. The magentic suite still passes locally (58 tests). The only thing left is a re-approval, since your earlier one went stale when the typing fix landed after it.