PyAutoGen Reasoning Content

[pccidaos]

What happened?

Upstream Issue: PyAutoGen Reasoning Content

Repository: https://github.com/microsoft/autogen

Title: OpenAIClient.message_retrieval does not handle list content from reasoning models (gpt-5, o1)

---

Body (copy below)

Description

When using OpenAI-compatible APIs with reasoning models (gpt-5, o1), the Chat Completions API returns message.content as a list of content blocks, e.g.:

[
  {"type": "reasoning", "text": "..."},
  {"type": "text", "text": "actual response"}
]

OpenAIClient.message_retrieval returns this list unchanged. Downstream code in _generate_oai_reply_from_client uses extract_text_or_completion_object(response)[0], which yields the raw list. Callers expect a string or completion object, leading to empty or malformed responses.

Environment

• pyautogen 0.2.35
• OpenAI API with gpt-5 deployment

Expected Behavior

message_retrieval should normalize list content to a string by extracting text from blocks with type == "text" (or "output_text").

Suggested Fix

In OpenAIClient.message_retrieval, when choice.message.content is a list, concatenate text from blocks with type in ("text", "output_text") and return that string instead of the raw list.

Which packages was the bug in?

Python AgentChat (autogen-agentchat>=0.4.0)

AutoGen library version.

Python dev (main branch)

Other library version.

pyautogen 0.2.35

Model used

gpt-5

Model provider

OpenAI

Other model provider

No response

Python version

3.11

.NET version

None

Operating system

None

[pandego]

Small but important distinction here: the issue body mixes the old pyautogen surface (OpenAIClient.message_retrieval) with the new 0.4+ package layout.

On current main, the relevant code seems to live in autogen_ext.models.openai._openai_client, and it already has special handling for:

• plain string choice.message.content
• reasoning_content in model_extra
• tool calls

What I do not see handled is the case where choice.message.content itself is a list of typed blocks and the model returns something like:

[
  {"type": "reasoning", "text": "..."},
  {"type": "text", "text": "actual response"}
]

So I think the bug report is directionally valid, but it would be easier to triage if it were reframed in 0.4 terms:

• this is not really a message_retrieval bug on main
• it is a response-normalization bug in the OpenAI-compatible client when choice.message.content is a list instead of a string

Suggested behavior on main:

• collect visible output from blocks with type in ("text", "output_text") into content
• collect reasoning blocks into thought when present
• ignore unknown block types rather than returning the raw list upstream

That would match the existing content / thought split better than flattening everything into one string.