.NET: feat: Implement message filtering to exclude non-portable content typ…#5410
Merged
lokitoth merged 10 commits intoMay 5, 2026
Merged
Conversation
…es before forwarding Co-authored-by: Copilot <[email protected]>
… executors Co-authored-by: Copilot <[email protected]>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR addresses a .NET Workflows interoperability bug where provider-specific, output-only Responses API items (e.g., reasoning/tool call artifacts) were being forwarded between agents and then round-tripped as invalid input, causing invalid_payload errors when chaining Foundry-backed agents.
Changes:
- Added a message sanitization step in
AIAgentHostExecutorto forward only “portable”AIContenttypes and to stripChatMessage.RawRepresentation. - Dropped messages that become empty after content filtering (at the message level).
- Added unit tests covering filtering of non-portable content and stripping of
RawRepresentation.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| dotnet/src/Microsoft.Agents.AI.Workflows/Specialized/AIAgentHostExecutor.cs | Filters forwarded response messages to remove output-only artifacts and strips message-level RawRepresentation before forwarding. |
| dotnet/tests/Microsoft.Agents.AI.Workflows.UnitTests/AIAgentHostExecutorTests.cs | Adds tests validating content filtering behavior and RawRepresentation stripping for forwarded messages. |
…stExecutor.cs Co-authored-by: Copilot <[email protected]>
…stExecutor.cs Co-authored-by: Copilot <[email protected]>
…stExecutor.cs Co-authored-by: Copilot <[email protected]>
…ests Co-authored-by: Copilot <[email protected]>
…://github.com/tarockey/agent-framework into feature/dotnet-workflow-agent-message-filters
This was referenced Jun 1, 2026
Closed
This was referenced Jun 10, 2026
This was referenced Jun 17, 2026
This was referenced Jun 24, 2026
This was referenced Jul 1, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a draft PR, happy to close it or modify based on discussion.
Motivation and Context
Closes #5338
When a Foundry server-side agent with server-side tools (MCP, web search, code interpreter, Fabric Data Agent, etc.) runs as part of a multi-agent workflow, the Responses API returns output-only items like
mcp_list_tools,reasoning,web_search_call, andfabric_dataagent_preview_callin its response. These items were being forwarded as-is to the next agent in the workflow viacontext.SendMessageAsync(response.Messages...).When the receiving agent sent its own Responses API request, the Microsoft.Extensions.AI library round-tripped these items via
ChatMessage.RawRepresentation, including them as input items. The Responses API rejected the request withinvalid_payload/invalid_request_errorbecause these are output-only item types that are not valid as input.This makes multi-agent workflows involving Foundry server-side agents with server-side tools unusable.
Description
Adds
FilterForwardableMessagestoAIAgentHostExecutorthat sanitizes response messages before forwarding them into the workflow. The filter does two things:Strips non-portable content: Only content items with recognized portable types (
TextContent,DataContent,UriContent,FunctionCallContent,FunctionResultContent,ToolApprovalRequestContent,ToolApprovalResponseContent,HostedFileContent,ErrorContent) are retained. Server-side artifacts like reasoning tokens and provider-specific tool call items are dropped.Strips
RawRepresentation: NewChatMessageobjects are constructed without the provider-specificRawRepresentation, preventing the Microsoft.Extensions.AI library from round-tripping the original output-only items (e.g.,mcp_list_tools) as input to the next agent.Messages that contain zero portable content items after filtering are dropped entirely.
What is NOT affected:
AgentResponseUpdates yielded viaYieldOutputAsync— these fire before the filter and retain full fidelityAgentResponseevents emitted viaEmitAgentResponseEvents— unaffectedRawRepresentationis[JsonIgnore]and was never persistedAIContent.RawRepresentationon individual content items — preserved; only the message-levelRawRepresentationis strippedKnown follow-up:
HandoffAgentExecutorhas a similar unfiltered path atsharedState.Conversation.AddMessages(result.Response.Messages)that would need an equivalent fix if Foundry server-side agents participate in handoff workflows.Contribution Checklist