Python: fix runtime response_format on foundry agent endpoint

[GitAashishG]

The Foundry agent endpoint rejects per-call text configuration when an agent is bound (400 invalid_payload, "Not allowed when agent is specified."). Strip text and text_format from the request body in _RawFoundryAgentChatClient._prepare_options so the user-supplied response_format is honored client-side via ChatResponse's lazy structured-value parsing instead of failing the request.

Fixes #5467

Motivation and Context

When using agent-framework-foundry, passing response_format at runtime (agent.run(..., options={"response_format": MyModel})) fails with:

400 invalid_payload, "Not allowed when agent is specified.", param: text

The Foundry agent endpoint rejects per-call text configuration when an agent is bound. The legacy azure-ai package handled this by dropping response_format from the request payload (#3230), but the equivalent strip is missing in agent-framework-foundry, so callers who migrated regressed.

Description

In _RawFoundryAgentChatClient._prepare_options, also pop text and text_format from run_options (in addition to the existing model / tools / tool_choice / parallel_tool_calls strips).

The user-supplied response_format still flows through validated_options, so OpenAIResponsesChatClient._parse_response_from_openai sets ChatResponse.response_format = MyModel. The lazy validation path in _parse_structured_response_value (added in #3274 for #3268) then surfaces a real pydantic.ValidationError if the agent's output does not match the runtime schema.

Net effect:

• No 400 from the service.
• Pydantic models: response.value is a validated instance (or a clear ValidationError on access).
• Dict json_schema: response.value is a parsed dict.
• The bound agent itself must be configured to emit JSON; otherwise response.value will raise on access. This matches the prior azure-ai behavior expectations.

Tests:

• Extended test_raw_foundry_agent_chat_client_prepare_options_strips_client_side_fields to assert text and text_format are stripped.
• New test_raw_foundry_agent_chat_client_prepare_options_strips_text_for_runtime_response_format covering the Pydantic and dict json_schema variants.

Contribution Checklist

• The code builds clean without any errors or warnings
• The PR follows the Contribution Guidelines
• All unit tests pass, and I have added new tests where possible
• Is this a breaking change? No.

[moonbox3]

Python Test Coverage Report •

File	Stmts	Miss	Cover	Missing
packages/foundry/agent_framework_foundry
_agent.py	231	54	76%	121, 124, 231–232, 236–238, 243–246, 336, 423–424, 436–437, 449–451, 453–454, 456–462, 464–465, 467, 469, 475–477, 480–489, 493–494, 681–682, 685, 711, 721, 737, 802
TOTAL	29867	3479	88%

Python Unit Test Overview

Tests	Skipped	Failures	Errors	Time
6024	30 💤	0 ❌	0 🔥	1m 39s ⏱️

[Copilot]

Pull request overview

This PR fixes a regression in agent-framework-foundry where providing response_format at runtime caused Foundry agent endpoint requests to fail with 400 invalid_payload due to disallowed per-call text configuration. The fix removes text and text_format from the outgoing request payload in the Foundry agent chat client so structured output is handled client-side via ChatResponse’s lazy parsing instead of being sent to the service.

Changes:

• Strip text and text_format from RawFoundryAgentChatClient._prepare_options request payload.
• Extend the existing _prepare_options stripping test to cover text/text_format.
• Add a new test to ensure runtime response_format variants (Pydantic and dict/json_schema) don’t result in text/text_format being sent.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
python/packages/foundry/agent_framework_foundry/_agent.py	Drops text/text_format from prepared run options to avoid Foundry agent endpoint rejection and rely on client-side structured parsing.
python/packages/foundry/tests/foundry/test_foundry_agent.py	Adds/extends unit tests to assert text/text_format are stripped, including runtime response_format scenarios.

[Copilot]

The explanatory comment implies that when the bound agent output doesn’t match the runtime schema, accessing response.value will raise pydantic.ValidationError. That’s only true for Pydantic response_format; for the dict/json_schema variant the lazy parsing path only does json.loads(...) and will raise ValueError on invalid JSON (and does not validate against the schema). Consider adjusting the comment to reflect both behaviors to avoid confusing users.

Suggested change

	# configured to emit JSON matching the requested schema; otherwise
	# ``response.value`` will raise ``pydantic.ValidationError`` on access.
	# configured to emit JSON compatible with the requested format; for a
	# Pydantic ``response_format``, accessing ``response.value`` may raise
	# ``pydantic.ValidationError`` if validation fails, while for a dict/
	# ``json_schema`` format the lazy path only parses JSON and may raise
	# ``ValueError`` for invalid JSON without validating against the schema.