Description
What problem does it solve?
The Python agent-framework package ships a complete A2UI integration under agent_framework_ag_ui._a2ui (A2UIAgent, enable_a2ui, generate_a2ui / render_a2ui tooling, catalog forwarding, progressive paint, validate→retry recovery). .NET (Microsoft Agent Framework dotnet) has no equivalent first-party package today.
As a result, .NET developers who want A2UI surfaces in their agents have to reverse-engineer the Python reference (_a2ui/_agent.py, ag_ui_a2ui_toolkit) and maintain a community port. It is unclear whether the .NET team plans parity, or whether we should build/maintain this ourselves.
What would the expected behavior be?
Provide an official Microsoft.Agents.AI.AGUI.A2UI (or similar) package for .NET that mirrors the Python _a2ui design:
A2UIAgent wrapper / enable_a2ui(...) helper- Planner-facing
generate_a2ui tool + render sub-agent forced to call render_a2ui
- Progressive paint: stream
render_a2ui argument fragments to the client via AG-UI
- Validate→retry recovery loop
- Component catalog forwarding from
RunAgentInput.context (a2ui_schema)
- Multi-turn tool-call sanitation (unanswered
render_a2ui / generate_a2ui calls)
If a first-party package is not planned, official guidance on how the .NET community should self-integrate with ag-ui-a2ui-toolkit semantics would be equally valuable.
Design questions
While building our own .NET prototype, we hit a few architectural questions that affect whether we align with the Python implementation:
- Is the planner + render-sub-agent split required primarily to enable progressive paint (streaming
render_a2ui argument fragments incrementally), or is it mostly separation-of-concerns + recovery? Could a single-agent model-driven approach stream progressively using AG-UI TOOL_CALL_ARGS deltas?
- Is
a2ui_schema in RunAgentInput.context the canonical, cross-language-stable channel for catalog forwarding?
- Is there a public roadmap for .NET A2UI support, or should the Python
_a2ui + ag_ui_a2ui_toolkit be treated as the reference implementation to port?
Happy to share our prototype and help validate an official .NET design.
Alternatives considered
Maintaining a community port of the Python _a2ui adapter on top of Microsoft.Agents.AI. This works, but risks drifting from upstream toolkit changes and from the official wire semantics.
Code Sample
Language/SDK
.NET
Description
What problem does it solve?
The Python agent-framework package ships a complete A2UI integration under
agent_framework_ag_ui._a2ui(A2UIAgent,enable_a2ui,generate_a2ui/render_a2uitooling, catalog forwarding, progressive paint, validate→retry recovery). .NET (Microsoft Agent Framework dotnet) has no equivalent first-party package today.As a result, .NET developers who want A2UI surfaces in their agents have to reverse-engineer the Python reference (
_a2ui/_agent.py,ag_ui_a2ui_toolkit) and maintain a community port. It is unclear whether the .NET team plans parity, or whether we should build/maintain this ourselves.What would the expected behavior be?
Provide an official
Microsoft.Agents.AI.AGUI.A2UI(or similar) package for .NET that mirrors the Python_a2uidesign:A2UIAgentwrapper /enable_a2ui(...)helpergenerate_a2uitool + render sub-agent forced to callrender_a2uirender_a2uiargument fragments to the client via AG-UIRunAgentInput.context(a2ui_schema)render_a2ui/generate_a2uicalls)If a first-party package is not planned, official guidance on how the .NET community should self-integrate with
ag-ui-a2ui-toolkitsemantics would be equally valuable.Design questions
While building our own .NET prototype, we hit a few architectural questions that affect whether we align with the Python implementation:
render_a2uiargument fragments incrementally), or is it mostly separation-of-concerns + recovery? Could a single-agent model-driven approach stream progressively using AG-UITOOL_CALL_ARGSdeltas?a2ui_schemainRunAgentInput.contextthe canonical, cross-language-stable channel for catalog forwarding?_a2ui+ag_ui_a2ui_toolkitbe treated as the reference implementation to port?Happy to share our prototype and help validate an official .NET design.
Alternatives considered
Maintaining a community port of the Python
_a2uiadapter on top ofMicrosoft.Agents.AI. This works, but risks drifting from upstream toolkit changes and from the official wire semantics.Code Sample
Language/SDK
.NET