.NET: [Bug]: Human-in-the-loop (AIApprovalFunction) not triggering when agent is used as a tool in triage agent

[Mohanr1122]

Description

Human-in-the-loop functionality using AIApprovalFunction is not working when an agent is configured as a tool and invoked by a triage agent.

Scenario:

Created Agent B with AIApprovalFunction (human approval required).

Agent B works correctly when invoked directly.

Agent B is then registered as a tool in Agent A (triage agent).

When Agent A invokes Agent B as a tool, the approval flow is not triggered.

Expected Behavior:

When Agent B is called (even as a tool), the AIApprovalFunction should trigger the human-in-the-loop approval process.

Actual Behavior:

Agent B executes without triggering approval.

No human intervention step is invoked.

Steps to Reproduce:

Create an agent (Agent B) with AIApprovalFunction.

Verify approval flow works when calling Agent B directly.

Register Agent B as a tool in another agent (Agent A - triage agent).

Invoke Agent B via Agent A.

Observe that approval is skipped.

Code Sample

Error Messages / Stack Traces

Package Versions

Microsoft.Agents.AI 1.6.2

.NET Version

No response

Additional Context

No response

[github-actions]

🤖 Automated triage reproduction notes (agent-authored — trust but verify)

Agent analysis

Repro: AIAgentExtensions.AsAIFunction() in dotnet/src/Microsoft.Agents.AI/AgentExtensions.cs line 82 calls agent.RunAsync() then returns only response.Text, discarding ToolApprovalRequestContent produced by the inner agent's FunctionInvokingChatClient when tools are wrapped in ApprovalRequiredAIFunction. Minimal repro: create a ChatClientAgent with an ApprovalRequiredAIFunction tool, convert to AIFunction via .AsAIFunction(), invoke it — the returned string is empty and the approval request is lost. The HandoffAgentExecutor handles this correctly via AIContentExternalHandler for reference.

• Failing test: dotnet/tests/Microsoft.Agents.AI.UnitTests/ChatClient/AsAIFunction_AprovalNotPropagatedTests.cs
• Files examined: dotnet/src/Microsoft.Agents.AI/AgentExtensions.cs, dotnet/src/Microsoft.Agents.AI.Abstractions/AgentResponse.cs, dotnet/src/Microsoft.Agents.AI/ChatClient/ChatClientAgent.cs, dotnet/src/Microsoft.Agents.AI.Workflows/Specialized/HandoffAgentExecutor.cs, dotnet/tests/Microsoft.Agents.AI.UnitTests/ChatClient/ChatClientAgent_ApprovalsTests.cs, dotnet/tests/Microsoft.Agents.AI.UnitTests/AgentExtensionsTests.cs
• Tests run: dotnet/tests/Microsoft.Agents.AI.UnitTests/ChatClient/AsAIFunction_ApprovalNotPropagatedTests.cs
• Reported version: 1.6.2
• Current version: 1.6.2

[XiongHaoTrigger]

Yes, the issue here is that when an agent as a "AIFunction", after the call is completed, the response's text is directly returned without any approval objects. This results in the caller not being able to obtain any approval objects. I need to look at Microsoft's designer documentation to see how to fix it.

[zyofeng]

This is a bug, currently only textcontent is returned, requring manual text input to "approve"

[rpelevin]

The important contract here seems to be that approval requirements should survive agent-as-tool wrapping.

If Agent B requires approval when invoked directly, registering Agent B as a tool in Agent A should not flatten that into plain text or let the triage agent bypass it. The pending approval should propagate as a first-class envelope through the parent run.

I would expect the envelope to preserve:

• parent agent/run id;
• child agent/run id;
• nested tool call id;
• approval function name;
• target operation/resource;
• canonical arguments digest;
• approval state: pending, approved, denied, timeout;
• final resolver: human/manual text/system;
• timeout/fail-closed behavior.

Two acceptance tests would make the bug concrete:

1. Direct call to Agent B triggers AIApprovalFunction; Agent B registered as a tool under Agent A triggers the same pending approval envelope before execution.
2. The triage agent receives text content that says "approve" but no matching approval envelope/decision id. The child action does not execute.

That keeps manual text approval possible as a UI surface, but makes the runtime boundary explicit: text is not the approval; the approval decision tied to the nested call is.