.NET: Handoff workflow raises two approval requests for one tool call, and resuming reports an error after the tool has executed

[jaliyaudagedara]

Versions

• Microsoft.Agents.AI.Foundry.Hosting 1.22.0-preview.260918.1 (also 1.21.0-preview)
• Microsoft.Agents.AI.Workflows 1.22.0
• Deployed to Foundry with azd code deploy, runtime dotnet_10, protocol responses 2.0.0

Setup

Two agents in a handoff workflow built with AgentWorkflowBuilder.CreateHandoffBuilderWith(...), exposed as a single agent with workflow.AsAIAgent(...) and served with AddFoundryResponses(...). One tool is wrapped in ApprovalRequiredAIFunction:

tools: [
    AIFunctionFactory.Create(GetRestaurants, nameof(GetRestaurants)),
    new ApprovalRequiredAIFunction(AIFunctionFactory.Create(BookTable, nameof(BookTable)))
]

What happens

1. One tool call produces two approval requests. The response contains two mcp_approval_request items with different ids and identical arguments, for a single BookTable call:

mcpr_E41E3C55A3EF084A2EE2339780FE661F4219A723CCDEE141E6  BookTable  {"restaurant":"The Domain Kitchen", ...}
mcpr_A3C8F9317B062E63C739D44A10DA0DE19C79BF37FBFB2A1869  BookTable  {"restaurant":"The Domain Kitchen", ...}

The same agent without a handoff workflow produces one.

2. Answering fails the run, after the tool has already executed. Posting mcp_approval_response for both ids (answering only one behaves the same) returns HTTP 200 with:

{
  "status": "failed",
  "error": { "code": "server_error", "message": "An error occurred while executing the workflow." },
  "output": [
    { "type": "function_call", "name": "BookTable" },
    { "type": "function_call_output", "output": "{\"reference\":\"BK-4651\", ... }" },
    { "type": "message", "role": "assistant", "content": [ { "type": "output_text",
      "text": "Booked: The Domain Kitchen (Auckland) for 2 people on 2026-09-26 at 19:00. Booking reference: BK-4651" } ] }
  ]
}

So the side effect happens and the caller is told the run failed. A client that retries on failure would book twice.

3. Nothing is logged. Container logs for the session show no exception and all four POST /responses completing HTTP 200. The failure exists only in the response payload, which makes this hard to diagnose from logs.

4. The response carrying the approval is marked completed. Not incomplete, so a client cannot use the status to tell that something is waiting on a human; it has to look for the item.

Expected

One mcp_approval_request per tool call, and answering it completes the run.

Note

In-process the same workflow behaves correctly: the run pauses with ToolApprovalRequestContent, CreateResponse(approved) resumes it, and the tool runs only after approval.

[manjunathshiva]

Both halves reproduce without Foundry hosting and without a deployment — plain in-process RunAsync against Azure OpenAI (gpt-5-mini), no AddFoundryResponses, no azd. That moves the bug: it is in the workflow layer, and the Foundry mcpr_… ids in your report are this duplication rendered onto the wire rather than its cause.

1. The two approval requests are one approval emitted at two layers, not two independent ones. The ids give it away:

control (single agent, no workflow)  -> 1 approval
    ficc_call_zdqHTKB4AjdkKbaQe9oeO7vW

handoff workflow via AsAIAgent       -> 2 approvals
    49:Booker_0baac4d9216f4591b29884c91faf036d_UserInput:ficc_call_zdqHTKB4AjdkKbaQe9oeO7vW
    ficc_call_zdqHTKB4AjdkKbaQe9oeO7vW

The second is the inner agent's raw request; the first is that same id wrapped in a workflow-executor prefix (<edge>:<executorId>_UserInput:). The workflow host republishes the inner request as its own user-input request and the original is not suppressed, so both reach the caller. Identical arguments, one model call.

2. Approving them executes the tool and still reports failure. Sending CreateResponse(approved: true) for both ids on the same session:

BookTable executed      : 1 time
FunctionResult items    : 1
ErrorContent items      : 1  -> "An error occurred while executing the workflow."
still-pending approvals : 0
final text              : "Done - I've made a booking at The Domain Kitchen for 2 people. Booking reference: BK-4651."

Same message as your server_error, and the run carries a successful function result and an assistant message saying the booking succeeded, alongside the error. So the double-booking risk you describe does not depend on the hosting layer either.

Reproduction, in full:

AIAgent coordinator = chatClient.AsAIAgent(
    instructions: "You triage restaurant requests. Hand off to Booker for any booking.", name: "Coordinator");
AIAgent booker = chatClient.AsAIAgent(
    instructions: "You help users book restaurant tables. Use the tools.", name: "Booker",
    tools: [
        AIFunctionFactory.Create(GetRestaurants, nameof(GetRestaurants)),
        new ApprovalRequiredAIFunction(AIFunctionFactory.Create(BookTable, nameof(BookTable))),
    ]);

Workflow workflow = AgentWorkflowBuilder
    .CreateHandoffBuilderWith(coordinator)
    .WithHandoff(coordinator, booker)
    .Build();

AIAgent workflowAgent = workflow.AsAIAgent(name: "BookingWorkflow");
AgentSession session = await workflowAgent.CreateSessionAsync();

var first = await workflowAgent.RunAsync(
    "Book a table at The Domain Kitchen in Auckland for 2 people on 2026-09-26 at 19:00.", session);
// -> 2 ToolApprovalRequestContent, one prefixed, one raw

var approvals = first.Messages.SelectMany(m => m.Contents).OfType<ToolApprovalRequestContent>()
    .Select(r => new ChatMessage(ChatRole.User, [r.CreateResponse(approved: true)])).ToList();

var resumed = await workflowAgent.RunAsync(approvals, session);
// -> BookTable ran once, one FunctionResultContent, and one ErrorContent

Scope of what I actually ran, so nobody over-reads this: one prompt, gpt-5-mini, Windows, in-process only. I did not test answering only one of the two ids — your report says it behaves the same and I have not confirmed that — and I have not verified the Foundry-hosted path, since it did not turn out to be necessary.

Two things this settles: the fix lives under dotnet/src (workflow host / handoff), not in Microsoft.Extensions.AI, and it needs neither a Foundry deployment nor the responses protocol to reproduce in a test.

Happy to take this if it is not already spoken for, but the shape is a maintainer call I would rather not guess at: should the workflow host suppress the inner request when it republishes it as _UserInput:, or should the prefixed id be the only one surfaced and correlation on resume accept the raw id too? The second defect looks like the flip side of the same question — the resume seems to satisfy the request under one id while something still expects the other.

[jaliyaudagedara]

Thanks, that's a much better localisation than mine, and it corrects my framing: I reported this as a hosting problem because that's where I hit it, and your control case shows hosting is incidental.

Reproduced in-process on a different path to yours: plain AzureOpenAIClient → AsIChatClient → AsAIAgent, gpt-5.2 instead of gpt-5-mini, Microsoft.Agents.AI 1.22.0-preview.260918.1. Same two requests, same _UserInput: prefix, same outcome. One detail worth adding: both requests carry the same ToolCall.CallId, so deduping on that is a viable client-side workaround.

RequestId : 49:Booker_ecf88c3f..._UserInput:ficc_call_upiKfOwcdpocSaHX9xMT4FAg
ToolCallId: call_upiKfOwcdpocSaHX9xMT4FAg
RequestId : ficc_call_upiKfOwcdpocSaHX9xMT4FAg
ToolCallId: call_upiKfOwcdpocSaHX9xMT4FAg

Answering only one id, which you flagged as untested:

answered	BookTable ran	FunctionResult	ErrorContent
both	1	1	1
prefixed _UserInput: only	1	1	1
raw ficc_... only	0	0	2

So the prefixed request is the one the host is actually waiting on; the raw one appears to be a leak. That may answer part of your question, surfacing only the prefixed id would lose nothing functionally, whereas a client that picks the raw one gets silent non-execution.

The error is worth separating out though: it appears in all three rows, including when both ids are answered. So it does not look like a consequence of an unsatisfied request, and may be a second defect rather than the flip side of the first.

One note for anyone reading this thread. A sample that prints only response.Text looks fine in-process: the tool ran, the text says the booking succeeded. The ErrorContent sits in the same response and is easy to miss. I had concluded in-process was a safe place to keep an approval gate until this was fixed, and my own sample was hiding the error from me.

Retitling the issue, since "hosted" is the wrong scope.