Microsoft Agent Framework 1.25 changes Python and MCP requirements
Microsoft Agent Framework Python 1.25.0 gives developers several reasons to review their deployment before upgrading. The release removes Python 3.10 installation eligibility, introduces finite defaults for MCP discovery and requests, and changes how shared workflows and Foundry Toolbox approvals are handled. Microsoft published the official release on November 7, 2026.
For teams running agents behind a web interface, the practical question is whether existing sessions, tool catalogs and approval settings still behave as intended. This is a release focused on migration with changes that can affect otherwise working applications.
Check the interpreter before the package update
The Python compatibility change raises package requirements to Python 3.11 or later. Microsoft explains that 3.11 was already the supported baseline, but older package metadata still permitted installation on 3.10. The new distributions remove that remaining eligibility.
Check the interpreter in production containers, background workers and build jobs, not just the one on a developer laptop. A successful local upgrade says little about a deployment image that still uses Python 3.10. Upper bounds set by individual integrations still apply, so moving every component to the newest interpreter without checking its dependencies is not a complete migration plan.
MCP discovery now has finite defaults
The MCP discovery change limits each tool or prompt catalog to 100 pages and 1,000 items by default. Clients created by the framework also receive a request timeout of 30 seconds. Clients supplied by the application retain their own transport and timeout policies.
These settings matter for an agent connected to a large internal tool directory or a slow service. Before rollout, compare the expected catalog size and request duration with the new defaults. A directory that exceeds a limit needs an explicit configuration decision rather than an assumption that discovery will keep fetching indefinitely.
Developers can raise max_discovery_pages or max_discovery_items. The release notes reserve unlimited discovery settings for trusted servers. A failed refresh preserves the previous complete catalog snapshot, which means applications should also make refresh errors visible instead of assuming that a retained catalog contains the latest tools.
A new workflow object may still share a session
The workflow authorization change addresses a subtle ownership problem. AgentExecutor retains an AgentSession and approval state between runs. Reusing that executor across callers can therefore reuse conversation history and approvals, even when the surrounding application appears to create separate workflows.
The release binds live workflow executors and sessions to one authorization scope. For AG-UI applications serving multiple users, the migration is to use a workflow factory that creates fresh workflows, executors and sessions for each call. Rebuilding from a shared builder is insufficient when the builder retains the same executor instances.
A useful review exercise is to trace where each executor is constructed. If it lives at module scope while requests arrive from different users, inspect that ownership before deploying the update. The single_user option is appropriate only when every caller is the same principal.
The guard has a defined boundary: it covers live executor and session identity. It does not establish isolation for state loaded from shared storage or for custom tool functions that invoke workflows.
Foundry Toolbox approvals follow discovered metadata
A separate Foundry Toolbox update makes the default approval policy honor approval metadata attached to discovered tools. Explicit local scalar, dictionary or callable policies override that metadata handling, so existing overrides deserve attention during an upgrade.
Missing metadata still retains the default of requiring no approval. Malformed metadata causes discovery to fail rather than quietly disabling approval. This distinction matters when reviewing a tool directory: absence of a policy is not equivalent to an explicit requirement for human approval.
Microsoft reports local regression validation for the change, but the pull request also says the patched package had not been redeployed to its live reproduction. Teams should verify their own approval and rejection paths, including resumed requests, before treating an upgrade as evidence that every hosted interaction has been checked.
Prioritize a migration review over a blind rollout
Start with the runtime version, then inspect catalog limits, workflow ownership and tool approval configuration. Those checks cover different failure modes and should remain separate in a deployment checklist. ByteForward has not independently tested this release. The recommendations here are based on Microsoft’s release notes and merged changes, with illustrative deployment scenarios rather than measured results.
For a broader testing plan, our Google ADK evaluation guide explains why repeated runs and individual failures deserve attention alongside an average score. Apply that testing principle to your own workflow, rather than assuming that a successful upgrade proves reliable behavior.
Featured image: AI generated editorial illustration by ByteForward. Microsoft logo used for editorial identification. Used with permission from Microsoft. No endorsement implied.
