How does the sub-agent return the tool request for approval?

[Hao Xiong (XiongHaoTrigger)]

In the source code, a child agent can be exposed as a tool via AsAIFunction. However, this seems to introduce a problem:

public static AIFunction AsAIFunction(this AIAgent agent, AIFunctionFactoryOptions? options = null, AgentSession? session = null)
{
    Throw.IfNull(agent);

    [Description("Invoke an agent to retrieve some information.")]
    async Task<string> InvokeAgentAsync(
        [Description("Input query to invoke the agent.")] string query,
        CancellationToken cancellationToken)
    {
        // Propagate any additional properties from the parent agent's run to the child agent if the parent is using a FunctionInvokingChatClient.
        AgentRunOptions? agentRunOptions = FunctionInvokingChatClient.CurrentContext?.Options?.AdditionalProperties is AdditionalPropertiesDictionary dict
            ? new AgentRunOptions { AdditionalProperties = dict }
            : null;

        var response = await agent.RunAsync(
            query,
            session: session,
            options: agentRunOptions,
            cancellationToken: cancellationToken).ConfigureAwait(false);

        return response.Text;
    }

    options ??= new();
    options.Name ??= SanitizeAgentName(agent.Name);
    options.Description ??= agent.Description;

    return AIFunctionFactory.Create(InvokeAgentAsync, options);
}

If the child agent requests approval for a tool call, wouldn't that approval request be completely swallowed here, since InvokeAgentAsync only returns response.Text?

In other words, converting an agent into an AIFunction appears to collapse the child agent's entire execution into a plain string result, which means intermediate events such as tool-call approval requests cannot propagate back to the parent agent or ultimately to the user.

Why was AsAIFunction designed this way? 🤔

[Junaid Hussnain (Junaid-PK)]

Your reading is correct for the current .NET implementation: the approval request does not propagate through AsAIFunction.

AsAIFunction is intentionally shaped as a simple model-compatible function: its contract says it accepts a query and returns the agent response as a string, and the implementation calls RunAsync(...) then returns only response.Text (current source). Any ToolApprovalRequestContent in the child response is therefore lost at that boundary.

This is also a reproduced open bug, #6062. A proposed passthrough/resume implementation in #6369 was closed without merging; the follow-up analysis explains that correct nested approval requires preserving the invocation frame, pending/completed calls, child session, and pause/resume state rather than merely returning a different object.

So today:

• AsAIFunction is fine when the child agent is expected to complete synchronously and return text.
• Do not rely on it for a child agent that may pause for AIApprovalFunction; there is no hidden approval channel back to the parent.
• For nested agents plus human approval, use a Workflow + Checkpoint / HITL design so the child invocation can suspend and resume with its state intact. That is the workaround recommended in the open issue.
• A plain text response such as approve is not equivalent to a ToolApprovalResponseContent tied to the original call ID, so treating text as approval would weaken the safety boundary.

In short, this is a known limitation/bug rather than behavior you are missing in the API.

[solim (soul-sol)]

Worth naming what this costs operationally, because I hit the same shape and it was
expensive: when an approval request can't propagate, the parent has no way to
distinguish "the child is working" from "the child is blocked waiting for a human".
Both look like a live call that hasn't returned.

The incident: a worker sat waiting for an approval it never received. The process stayed
alive, so every check said "running", and the orchestrator reported success at the end of
the batch. Nothing had been implemented.

So even where the approval can't be surfaced through the function boundary, two things
help a lot:

• Make "blocked" a distinct terminal state, not silence. Three states, not two:
  finished (status recorded), needs-approval (surfaced), and unknown — alive, no output
  for N seconds, no request seen. The third is the one that loses time, and it only exists
  if you name it.
• Never infer completion from the absence of a question. A child that returns a string
  without having done the work is indistinguishable from one that succeeded, if the parent
  only checks that the call returned. The recorded outcome has to come from something only
  the real completion could produce.

If AsAIFunction stays intentionally simple, a timeout on the parent side that resolves to
UNVERIFIED rather than FAILED at least prevents the other half of the damage —
UNVERIFIED must never auto-retry, or the side effects fire twice.