Polymorphism issue: CodeExecutorAgent calls classmethod via concrete class in on_messages_stream

[Momo-Not-Emo]

What happened?

Describe the bug
In CodeExecutorAgent.on_messages_stream, the class method _reflect_on_code_block_results_flow is invoked via the concrete class name:

autogen/python/packages/autogen-agentchat/src/autogen_agentchat/agents/_code_executor_agent.py

Lines 667 to 675 in 13e144e

	async for reflection_response in CodeExecutorAgent._reflect_on_code_block_results_flow(
	system_messages=system_messages,
	model_client=model_client,
	model_client_stream=model_client_stream,
	model_context=model_context,
	agent_name=agent_name,
	inner_messages=inner_messages,
	):
	yield reflection_response # Last reflection_response is of type Response so it will finish the routine

This introduces a static binding to CodeExecutorAgent and breaks polymorphism for subclasses that override _reflect_on_code_block_results_flow.

This appears to be the same pattern and root cause as a previously reported polymorphism bug:

• polymorphism bug in in AssistantAgent._process_model_result #5953

To Reproduce
Create a child class of CodeExecutorAgent and override method _reflect_on_code_block_results_flow. When calling on_messages_stream on an agent of the custom class, it still calls the parent class's methods.

Expected behavior
The override methods should be be called.

Which packages was the bug in?

Python AgentChat (autogen-agentchat>=0.4.0)

AutoGen library version.

Python dev (main branch)

Other library version.

No response

Model used

No response

Model provider

None

Other model provider

No response

Python version

None

.NET version

None

Operating system

None

[joaquinariasco-lab]

Avoiding Static Bindings in A2A Orchestration

Hi @Momo-Not-Emo
I’ve been following your bug report on the static binding issue within CodeExecutorAgent. It’s a frustrating pattern—breaking polymorphism in a framework as large as AutoGen really limits how we can subclass and extend agent behavior.

I am building a Global Agentic Economy (GAEP) protocol, and we are obsessively focused on Clean Architecture and true extensibility. We want to ensure that our "Agent Base Classes" are fully polymorphic so the community can build specialized economic entities on top of our core without hitting the walls you’ve identified in autogen-agentchat.

I’d love to have your "architect’s eye" on our orchestration layer. We are designing an A2A (Agent-to-Agent) settlement system where extensibility is a requirement, not an afterthought.

Since you’ve already pinpointed these inheritance bottlenecks in Microsoft’s stack, your perspective on how to build a truly "subclass-friendly" agent protocol would be incredibly valuable to us.

Are you open to a brief technical discussion?

Best,

Joaquin

[Momo-Not-Emo]

Hey @joaquinariasco-lab, Thanks for sharing — the A2A orchestration concept sounds really interesting. Ensuring extensibility and clean polymorphism in agent frameworks is definitely important. I’m just a student, and I actually noticed this static binding issue by referencing other related issues

[joaquinariasco-lab]

Hey, thanks for the context, and nice catch on the static binding issue. That kind of observation usually comes from actually reading systems closely, so it’s valuable regardless of seniority.

If you’re curious, here’s a small public repo where I’m experimenting with agent-to-agent orchestration in a very minimal way (no framework lock-in, just basic coordination primitives):

https://github.com/joaquinariasco-lab/flowing.git

It’s early and intentionally simple, but if you try it and notice any design or extensibility issues, I’d genuinely appreciate the feedback, especially from a learning / systems perspective.

Thanks for taking the time to reply,
Joaquín