Up-voting, this analysis by @joslat.

The null parameter for the AgentThread effectivly exposes the agent-as-a-tool as equivelent to KernelFunctionFromPrompt.

There's a couple way of looking at how to manage the context of the agent-as-a-tool:

1. Provide access to the outer conversation or thread. While injects the full context of the outer conversation, it introduces the following considerations:

   • How is this managed across different agent modalities. That is, it is entirely possible that outer agent AzureAIAgent and the agent-as-a-tool is ChatCompletionAgent. There two different agent modalities require different AgentThread instances.
   • Is the agent-as-a-tool allowed to update the outer thread? If both the outer agent and agent-as-a-tool are AzureAIAgent types, and the same thread-id is utilized by the tool, then (in the absence of any special handling) the tool response will be added to the thread. I believe this is undesired when using agent-as-a-tool.

2. The inner agent-as-a-tool maintains its own inner (of forked) thread that retains context when the agent-as-a-tool is invoked multiple times for the same conversation. This retains context for the inner agent-as-a-tool without mutating the outer conversation / thread.

Finally, there could feasibly be a mode where the developer desires the agent to not retain an context other than the input queryString.

Note: We should also take care to align both Python and .NET with whatever decision point is made for this feature.