How do you handle HITL or avoid replays when using Workflows as Agent?

[wyarcdev]

Sequential Agent Workflow re-requesting HITL approvals on Session Resume

We are testing a sequential multi-agent workflow (AgentWorkflowBuilder.BuildSequential) consisting of a routing agent, summary agent, and an execution agent utilizing an ApprovalRequiredAIFunction.

We are running into two key issues with streaming and session state:

1. RunStreamingAsync yields multiple ToolApprovalRequestContent chunks sharing the same CallId, causing naive chunk counts to fail assertions.
2. Upon serializing, deserializing, and resuming the session with the user's approval response (CreateResponse(true)), the workflow restarts the sequence and prompts for the exact same tool approval a second time on top of executing the function.

How do we properly inject a tool approval response into a sequential workflow session so that the downstream execution agent consumes it rather than re-triggering the tool call?

Code:

// Create a sample function tool that the agent can use.
[Description("Get the weather for a given location.")]
static string GetWeather([Description("The location to get the weather for.")] string location)
    => $"The weather in {location} is cloudy with a high of 15°C.";

var openAiClient = new OpenAIClient(credential: new ApiKeyCredential(ApiKey!),
    options: new OpenAIClientOptions { Endpoint = new Uri(EndPoint) });

var chatClient = openAiClient.GetChatClient(Model).AsIChatClient();

var agent1 = new ChatClientAgent(chatClient, new ChatClientAgentOptions
{
    Name = "greeting",
    Description = "Interprets customer operations requests and routes toward execution.",
    ChatOptions = new ChatOptions
    {
        Instructions = "Convert user requests into a concise execution handoff. Do not include disclaimers, capability limitations, or user-facing prose. You are unable to call any tools. Do not attempt to.",
        ToolMode = ChatToolMode.None
    }
});
var agent3 = new ChatClientAgent(chatClient, new ChatClientAgentOptions
{
    Name = "summary bot",
    Description = "summary assistant.",
    ChatOptions = new ChatOptions
    {
        Instructions = "Return a single concise final answer using only execution results. Do not repeat content.",
        ToolMode = ChatToolMode.None,
    }
});
var agent2 = new ChatClientAgent(chatClient, new ChatClientAgentOptions
{
    Name = "execution",
    Description = "Executes governed customer operations using approved tools.",
    ChatOptions = new ChatOptions
    {
        Instructions = "You are a governed customer service agent.  Governance/HITL handles approvals outside the model.",
        ToolMode = ChatToolMode.Auto,
        Tools = [new ApprovalRequiredAIFunction(AIFunctionFactory.Create(GetWeather))]
    }
});

var agent = AgentWorkflowBuilder.BuildSequential("test-workflow", new List<AIAgent> { agent1, agent2, agent3 })
    .AsAIAgent("weather-agent", "weather agent");
// Call the agent and check if there are any function approval requests to handle.
// For simplicity, we are assuming here that only function approvals are pending.
AgentSession session = await agent.CreateSessionAsync();

// For streaming use:
var updates = await agent.RunStreamingAsync("What is the weather like in Amsterdam?", session).ToListAsync();
List<ToolApprovalRequestContent> approvalRequests = updates.SelectMany(x => x.Contents).OfType<ToolApprovalRequestContent>().ToList();
var countsPerCallId = approvalRequests
    .GroupBy(x => x.ToolCall.CallId)
    .Select(g => new
    {
        CallId = g.Key,
        Count = g.Count()
    })
    .ToList();
if (countsPerCallId.Count != 1)
{
    throw new InvalidOperationException("Expected only one unique function call request.");
}

if (countsPerCallId[0].Count != 1)
{
    throw new InvalidOperationException("Expected only one function call request.");
}
var message = string.Join("", updates
    .SelectMany(m => m.Contents)
    .OfType<TextContent>()
    .Select(t => t.Text));

// serialise session
var serializedState = await agent.SerializeSessionAsync(session);
session = await agent.DeserializeSessionAsync(serializedState);

approvalRequests = approvalRequests.DistinctBy(x => x.ToolCall.CallId).ToList();

while (approvalRequests.Count > 0)
{
    // Ask the user to approve each function call request.
    List<ChatMessage> userInputResponses = approvalRequests
        .ConvertAll(functionApprovalRequest =>
        {
            Console.WriteLine($"The agent would like to invoke the following function, please reply Y to approve: Name {((FunctionCallContent)functionApprovalRequest.ToolCall).Name}");
            return new ChatMessage(ChatRole.User, [functionApprovalRequest.CreateResponse(Console.ReadLine()?.Equals("Y", StringComparison.OrdinalIgnoreCase) ?? false)]);
        });

    // For streaming use:
    updates = await agent.RunStreamingAsync(userInputResponses, session).ToListAsync();
    var errors = updates.SelectMany(x => x.Contents).OfType<ErrorContent>().ToList();
    foreach (var item in errors)
    {
        Console.WriteLine(item.Message);
    }
    approvalRequests = updates.SelectMany(x => x.Contents).OfType<ToolApprovalRequestContent>().ToList();
    if(approvalRequests.Count > 0)
    {
        throw new InvalidOperationException("Expected no further function call requests.");
    }
    message = string.Join("", updates
   .SelectMany(m => m.Contents)
   .OfType<TextContent>()
   .Select(t => t.Text));
}

Console.WriteLine($"\nAgent: {message}");

[Evan Mattson (moonbox3)]

Jacob Alber (@lokitoth) are you able to help with this?

[Denis Samatov (denis-samatov)]

Correction: The original version of this comment was incorrect for BuildSequential(...).AsAIAgent(...).

The stream contains two representations of the same logical approval: an inner-agent ToolApprovalRequestContent, and the workflow-facing copy emitted from a RequestInfoEvent. They may share ToolCall.CallId, so grouping or deduplicating by CallId can retain the inner copy. That copy does not necessarily carry the workflow-facing RequestId needed to resume the pending request.

Select only the workflow-facing requests and correlate by RequestId:

List<ToolApprovalRequestContent> approvalRequests = updates
    .Where(update => update.RawRepresentation is RequestInfoEvent)
    .SelectMany(update => update.Contents.OfType<ToolApprovalRequestContent>())
    .DistinctBy(request => request.RequestId)
    .ToList();

Create the approval response from that exact request and send it as a user message on the restored session:

List<ChatMessage> approvalResponses = approvalRequests
    .Select(request => new ChatMessage(
        ChatRole.User,
        [request.CreateResponse(approved: true)]))
    .ToList();

JsonElement serializedState = await agent.SerializeSessionAsync(session);
session = await agent.DeserializeSessionAsync(serializedState);

updates = await agent.RunStreamingAsync(approvalResponses, session).ToListAsync();

ChatRole.Tool, DistinctBy(ToolCall.CallId), and the comparison with #5189 suggested in my earlier comments were not applicable to this workflow-as-agent path. Evan's maintainer explanation below identifies the relevant WorkflowSession behavior.

[weirdyang]

This will not work with the scenario described, please see the code it is already grouping by call id and it does not resend the user prompt or use plain json serialisation. The same session is used, and no new session is created

[Denis Samatov (denis-samatov)]

Update: The original version of this reply still misdiagnosed the problem. This is not the plain-agent serialization issue from #5189.

For BuildSequential(...).AsAIAgent(...), the stream exposes both the inner-agent approval and a workflow-facing copy from RequestInfoEvent. The response must be created from the latter so its ToolApprovalResponseContent.RequestId matches WorkflowSession's pending-request map. If the inner copy is retained by DistinctBy(ToolCall.CallId), the lookup misses and the response is treated as ordinary input, starting another sequential turn.

The relevant fix is therefore to filter updates with RawRepresentation is RequestInfoEvent, deduplicate by RequestId, and return request.CreateResponse(...) in a ChatRole.User message. See Evan's maintainer explanation below for the implementation details.

[wyarcdev]

Please re-read the OP. That is not the issue. The issue is when you convert Sequential Workflow to a workflow. It will go through the stages all over again as it does not have the same resume capability as a workflow.

[Evan Mattson (moonbox3)]

There are two different things being surfaced in this stream, even though they refer to the same underlying tool call:

1. the ToolApprovalRequestContent from the inner agent's streaming update; and
2. the workflow-level external request, surfaced by WorkflowSession from a RequestInfoEvent.

Those can have the same ToolCall.CallId, so counting every ToolApprovalRequestContent in every streaming update will make one logical approval look like a duplicate. More importantly, DistinctBy(x => x.ToolCall.CallId) can retain the inner-agent copy. That copy does not necessarily have the workflow-facing RequestId needed to resume the pending workflow request.

For a workflow exposed through AsAIAgent, select the approval request from the RequestInfoEvent update and correlate/deduplicate by its RequestId:

List<ToolApprovalRequestContent> approvalRequests = updates
    .Where(update => update.RawRepresentation is RequestInfoEvent)
    .SelectMany(update => update.Contents.OfType<ToolApprovalRequestContent>())
    .DistinctBy(request => request.RequestId)
    .ToList();

Then create the response from that exact workflow-facing request:

List<ChatMessage> approvalResponses = approvalRequests
    .Select(request => new ChatMessage(
        ChatRole.User,
        [request.CreateResponse(approved: true)]))
    .ToList();

JsonElement serializedState = await agent.SerializeSessionAsync(session);
session = await agent.DeserializeSessionAsync(serializedState);

updates = await agent.RunStreamingAsync(approvalResponses, session).ToListAsync();

The ordering of serialization versus creating the response object is not important here; preserving the workflow-facing RequestId is. WorkflowSession serializes both its last checkpoint and its pending external-request map. On resume it matches ToolApprovalResponseContent.RequestId against that map, converts the response back into the workflow's ExternalResponse, and removes the pending request.

If the response was created from the inner streaming copy instead, the ID lookup misses. The response is then treated as ordinary input, which sends a new turn through the sequential workflow. That explains the behavior you observed: the approved function can execute while the restarted sequence also reaches the same approval again.

The relevant implementation is in WorkflowSession: RequestInfoEvent is where the pending request is recorded and its content is rewritten to the workflow-facing request ID; SendMessagesWithResponseConversionAsync is where the approval response is matched during resume. The inner update is emitted earlier by AIAgentHostExecutor, which is why DistinctBy(ToolCall.CallId) normally keeps the wrong copy.

If this still reproduces after filtering to RawRepresentation is RequestInfoEvent, please share the exact Microsoft.Agents.AI and Microsoft.Agents.AI.Workflows package versions. The current code has explicit workflow-as-agent approval round-trip coverage, so a repro against current packages would indicate a separate bug rather than an issue with how the approval response is injected.

[Denis Samatov (denis-samatov)]

Thank you — this identifies the exact distinction I missed. I conflated the inner-agent approval update with the workflow-level copy emitted from RequestInfoEvent.

DistinctBy(ToolCall.CallId) can retain the inner-agent copy, whose RequestId is not the workflow-facing pending-request ID. Creating the response from that copy causes WorkflowSession to treat it as ordinary input and start another sequential turn.

Filtering updates by RawRepresentation is RequestInfoEvent and correlating by ToolApprovalRequestContent.RequestId is therefore the relevant fix. My earlier suggestions involving ChatRole.Tool and #5189 were incorrect for this scenario. Sorry for the confusion.