Repository navigation
Description
Description
The Microsoft Agent Framework has all the right infrastructure for AG UI state management - AgentSessionStateBag for session-level state (#3806), StateSnapshotEvent/StateDeltaEvent event types, and a transport layer that correctly converts DataContent into AG-UI SSE events — but it lacks the integration layer that would automatically bridge these pieces together.
As a result, any developer who wants to emit STATE_SNAPSHOT or STATE_DELTA events must write custom middleware (see SharedStateAgent.cs and PredictiveStateUpdatesAgent.cs in the AG-UI samples), manually wiring LLM output → state extraction → DataContent emission on every project. This is a significant ergonomic gap compared to peer frameworks like Pydantic AI and LangGraph, which have first-class framework primitives for exactly this.
What's missing
The framework currently has no way to:
- Automatically emit STATE_SNAPSHOT from AgentSession.StateBag at run start
- Automatically compute and emit STATE_DELTA (RFC 6902 JSON Patch) when StateBag.SetValue() is called
- Emit predictive STATE_DELTA events during tool-argument streaming (today FunctionCallContent is only surfaced after the argument is fully formed). PredictiveStateUpdatesAgent.cs is a workaround for this.
- Declare an agent's AGUI state schema and map tool arguments to state fields
The AGUI pipeline (MapAGUI() in Microsoft.Agents.AI.Hosting.AGUI.AspNetCore, and the conversion layer in ChatResponseUpdateAGUIExtensions) already handles the transport side, converting DataContent to STATE_SNAPSHOT/STATE_DELTA SSE events. What's missing is the upstream step: automatically populating those DataContent payloads from AgentSession.StateBag mutations when a run is being served through that pipeline.
Proposed solution
The basic case - emitting STATE_SNAPSHOT/STATE_DELTA automatically when AgentSession.StateBag is mutated, requires no configuration and could work out of the box. The advanced case, emitting predictive STATE_DELTA events during tool-argument streaming, would benefit from a declarative mapping from tool arguments to state paths, as demonstrated by Pydantic AI's AG-UI example.
References
- .NET: Support for intermediate state from Tools for AG-UI #2081 — maintainer currently points to SharedStateAgent.cs as the manual workaround
- .NET - AG-UI Support more AG-UI event types. #2558 — making internal AGUI event types public
- .NET: [BREAKING] Add session StateBag for state storage and support multiple providers on the Agent #3806 — StateBag on AgentSession (the state foundation this would build on)
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsDone
Activity
[-][Feature]: Automatic translation of StateBag mutations and streaming tool-argument deltas to AG-UI state events[/-][+].NET: [Feature]: Automatic translation of StateBag mutations and streaming tool-argument deltas to AG-UI state events[/+]danroth27 commentedon Jul 25, 2026
The AG-UI .NET SDK (
AGUI.Server/AGUIStreamOptions) now lives inag-ui-protocol/ag-ui, so the declarative stream-mapping portion of this request is tracked there: ag-ui-protocol/ag-ui#2245.Status of the pieces raised here:
AGUIStreamOptions:MapResultAsStateSnapshot(toolName)andMapResultAsStateDelta(toolName). CustomSharedStateAgent.cs-style middleware is no longer required for that case.predict_state_configequivalent) is still manual viaMapCall(...)— tracked in [.NET] Predictive state updates: stream a tool call's arguments to the UI as the model writes them ag-ui-protocol/ag-ui#2245.AgentSession.StateBagmutations — still open here, since it touchesAgentSessionin agent-framework core.Framing note for anyone picking this up: state events now flow via
RawRepresentation = StateSnapshotEvent/StateDeltaEventand theMapResultAsState*/MapCallmappings rather thanDataContent, andMapAGUI()is nowMapAGUIServer(). ThePredictiveStateUpdatesAgent.cs/SharedStateAgent.cssample workarounds referenced above have been replaced by the declarativeAGUIStreamOptionssamples.demidgost-sys commentedon Aug 4, 2026
Thanks — AgentSessionStateBag is documented as thread-safe, so individual SetValue operations should already be safe. What I was wondering about is the ordering guarantee in the proposed AG-UI bridge: if two mutations happen close together, should the generated RFC 6902 deltas be serialized or versioned so clients cannot apply them out of order? Would an integration test or a documented fallback to STATE_SNAPSHOT make sense for this case?
javiercn commentedon Aug 18, 2026
The current framing conflates
AgentSession.StateBagwith AG-UI shared state.StateBagis arbitrary persisted session state used by Agent Framework and provider integrations. It can contain internal data such as:Automatically emitting its contents or mutations to an AG-UI client would expose implementation state that was never declared as part of the application's frontend state contract.
StateBagalso has no UI schema, mutation-observation contract, transaction boundary, version, or ordered RFC 6902 delta stream.AG-UI state should instead be application-defined and mapped explicitly through the public AG-UI SDK:
Applications can also use:
MapCall(...);MapResult(...);MapContent(...);StateSnapshotEvent/StateDeltaEventvalues;Tool-argument streaming is similarly an explicit protocol-mapping concern.
AGUI.Serverexposes streaming argument extraction throughMapStreamingToolCallArguments(...); deciding whether and how those fragments represent application state remains application-specific.The older
DataContentconventions and sample middleware referenced in the issue have been superseded by publicAGUI.Abstractionsevents andAGUIStreamOptions.We do not plan to automatically expose
AgentSession.StateBagas AG-UI state. It remains session persistence infrastructure, not an implicit frontend state model. This issue can be closed as not planned.