Python: kwargs are not passed to _prepare_thread_and_messages in ChatAgent.run

[anguzo]

In ChatAgent.run_stream kwargs are passed

agent-framework/python/packages/core/agent_framework/_agents.py

Line 837 in dd69cab

thread=thread, input_messages=input_messages

[eavanvalkenburg]

@anguzo we are looking more broadly into how we treat kwargs, because that might be a messy thing, what are you using the kwargs for here?

[anguzo]

@eavanvalkenburg I was implementing a tool and context provider for Azure AI Search. My idea was that context provider enables more deterministic context retrieval while tool a more autonomous (needed to evaluate which approach would work best for my case). In case of context provider I wired a small LLM for search query rewriting and in case of tool query rewriting is done automatically by LLM inferring tool call arguments.
In either case I wanted to pass some other parameters to search (like by which value to filter search results before Azure AI Search will search by query). I understood from some source code, specifically Chat agent.run docstring that passing kwargs to it automatically passes them down to context providers or tools.
This felt as actually pretty neat feature, exactly the type of development freedom that Python enables (along with possible messiness of such approach).
Basically, what I had is a unified search service that both context provider and tool use under the hood:

class AzureAISearchService:
async def invoke(self, query: str,  **kwargs: Any):
search_params = SearchParameters.model_validate(kwargs.get("search_params")) # this hugely solves the possible messiness 

Either way whether your team decides to use kwargs for this purpose or not, it would be great if there would be parity between Chat agent.run vs Chat agent.run_stream and context provider vs tool for passing additional parameters for the time being.

[eavanvalkenburg]

Thanks for this insight @anguzo I have fixed the parity issue, so both now get the **kwargs and we will take this into account if we decide to make changes to kwargs. One of the things I'm thinking about is basically making this a bit more explicit, something like:

async def run(
    messages: ...
    <other params>,
    function_kwargs: dict[str, Any],
    context_provider_kwargs: dict[str, Any],
    ...
    **kwargs: Any
)

then it's more explicit where you are passing things (and we keep the kwargs itself, because that prevents breaking changes if we do need to change something)

[anguzo]

Honestly I think you should not be concerned with breaking changes until you reach GA and users should be taking into account the possible chaotic nature of preview tech. Supporting both function/context provider kwargs and ordinary kwargs will most likely result in somewhat sloppier code with more branching logic (reading both, whether to merge them and such).
Making this more explicit makes more sense, as it communicates intent better through the method signature rather than through docs. But in this case this will most likely be best to be somehow be reflected on the context provider/tool side as well rather than require user to specifically write Context provider.invoking and ai_function with kwargs in method signature.
Just my two cents :)
Thank you for the work!

[eavanvalkenburg]

Def true that breaking changes are not as important, my concern is more that if at some point we do want to change the behavior of context providers (for instance) and we want to remove those specific kwargs, that is less of a breaking change if we already have generic kwargs on the method.

For functions, my preferred way to add additional context is to wrap the functions in a class and use class attributes to get context in, rather then passing all of that along throughout, but that has it's own downsides, context providers should also have "state" that could just be updated, but that might be trickier for something like a filter as in this case.