.NET: surface a workflow tool approval request once

[Yashvant Mahadev Hange (YashvantHange)]

Motivation & Context

A tool approval raised inside a workflow reaches the caller twice, with two different IDs, and only one of them is answerable.

An agent host executor streams the agent's updates straight out as workflow output, so the ToolApprovalRequestContent the agent produced is emitted with the agent-local RequestId. It then hands that same approval to its request port, and WorkflowSession turns the resulting RequestInfoEvent into a second ToolApprovalRequestContent, cloned with the workflow-facing request ID (<len>:<portId>:<requestId>). A caller consuming workflow.AsAIAgent().RunStreamingAsync sees both.

Only the second is answerable. WorkflowSession matches an incoming ToolApprovalResponseContent against _pendingRequests, which is keyed by the workflow-facing ID. A response addressed with the agent-local ID misses that lookup and is forwarded into the workflow as an ordinary message, so it silently does nothing.

Reported against a handoff workflow, but HandoffAgentExecutor and AIAgentHostExecutor have the same pair of emissions, so a plain agent binding with EmitAgentUpdateEvents = true and InterceptUserInputRequests = false shows it too.

Description & Review Guide

• What are the major changes?

An agent host executor no longer emits, as its own output, an approval it hands to its request port. AIContentExternalHandler gains RaisesExternalRequests so the executor can tell a port-backed handler from an intercepted one, and AIAgentUnservicedRequestsCollector gains the two filters that apply it: one for the streamed AgentResponseUpdate, one for the AgentResponse emitted under EmitAgentResponseEvents. Both executors call them; nothing else changes about how a request is raised or answered.

The response filter runs after the whole response has been collected, so it removes exactly the approvals whose requests are about to be raised. The streaming filter cannot know that yet, so it keeps each withheld copy and SubmitAsync emits it after all if no request was raised for that ID, which is what happens when an agent answers its own approval within one run.

• What is the impact of these changes?

An approval reaches the caller once, carrying the ID the caller has to answer with. Intercepted user-input handling (InterceptUserInputRequests = true) is untouched, because no workflow-facing request exists for it. The AgentResponse returned by the executor is not modified, so message forwarding, the handoff conversation and chat history are unaffected; only the copy emitted as output is filtered. No public API changed: both new members are on internal types.

One consequence worth naming: a turn whose only agent output was the approval now emits an AgentResponseEvent with no messages, so under includeWorkflowOutputsInResponse that turn contributes nothing to the response instead of contributing the duplicate approval. That is the intended trade, since the approval itself is already on the wire as the workflow-facing request.

Function call content is deliberately left alone. Unterminated function calls have the equivalent double-surfacing, but a function call in an agent stream is normally terminated inline in the same run and there is no way to tell mid-stream, so filtering them would hide ordinary tool calls. Magentic/ExecutorAgentHarness repeats the same emit-then-collect shape and is left as it is because it is currently never constructed; it would need the same filter on the day it is wired up.

• What do you want reviewers to focus on?

Whether withholding the streamed copy and repairing it in SubmitAsync is the right split, or whether the executor should instead defer the whole approval-carrying update until the run ends.

Related Issue

Fixes #7857

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR is linked to an issue and there is no other open PR for this issue (see Related Issue above).
• This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.

[Copilot]

Pull request overview

Prevents duplicate workflow tool-approval requests by exposing only the answerable workflow-facing request.

Changes:

• Filters externally raised approvals from agent updates and responses.
• Restores self-answered approvals that never become external requests.
• Adds host and handoff workflow coverage.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
WorkflowHostSmokeTests.cs	Tests approval filtering scenarios.
HandoffOrchestrationTests.cs	Tests single approval surfacing in handoffs.
HandoffAgentExecutor.cs	Filters emitted approval copies.
AIContentExternalHandler.cs	Identifies externally raised requests.
AIAgentUnservicedRequestsCollector.cs	Withholds, filters, and restores approvals.
AIAgentHostExecutor.cs	Applies filtering to host outputs.

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.