Add api_key argument to specify API KEY when creating agents

[ufownl]

This argument allows us to create agents with different API KEYs at runtime. It helps implement workflows that require users to provide an API KEY.

[evalstate]

Only slight concern here is the AgentConfig/Decorator getting a bit unwieldy.

Would you be able to a) add a test to test_provider_keys.py to show create an agent and show the override. b) take a look at the doc site and add a note for this feature (https://github.com/evalstate/fast-agent-docs)?

Out of interest - is this a feature you're using in production?

[ufownl]

Only slight concern here is the AgentConfig/Decorator getting a bit unwieldy.

Indeed, an additional argument/field. This is inspired by Agno, it exposes the classes of providers and provides an argument to set the API KEY programmatically. However, in fast-agent, augmented_llm is created by the factory and attached implicitly. So I think this is a reasonable solution for now, and this also allows the sampling agent to obtain the API KEY from the agent that connects the MCP servers, if it is in the auto sampling mode.

Would you be able to a) add a test to test_provider_keys.py to show create an agent and show the override. b) take a look at the doc site and add a note for this feature (https://github.com/evalstate/fast-agent-docs)?

Maybe I can do these later today.

Out of interest - is this a feature you're using in production?

Currently, it is not in production, but I want to deploy the online demos that require the users to provide their API KEYs to run. So I need a way to set the API KEY programmatically like Agno.

[evalstate]

Indeed, an additional argument/field.

Agreed (and good catch picking up the key for auto-sampling). I do wonder about the correct balance here -- would be interested in ideas on how to manage this (if do anything at all -- there's nothing inherently wrong with having a lot of arguments in a config interface). Might be that separating "Model" from "Agent" would be good. You might have noticed I've introduced the A2A types in a few places as they seem to provide a nice way of modelling Agents. One of the things in the short-term plan is to create a new Orchestrator that generates Agents on the fly based on task/agent cards.

Currently, it is not in production, but I want to deploy the online demos that require the users to provide their API KEYs to run. So I need a way to set the API KEY programmatically like Agno.

Seems reasonable -- do they enter these through the TUI/Command Line or a different way (I quite like the sound of this User Experience). At the moment, a lot of my usage of fast-agent is with fast-agent go --url <blah-blah> and I was also thinking of changing the System Default model to look for API KEYs when doing its selection. It might be quite nice if e.g. you were prompted to enter if one wasn't found. (PR #269 adds some more convenience here, including omitting go)

Anyway, thanks for the PR and would be interested in further thoughts/PR/commits on any of the above :)

[ufownl]

Might be that separating "Model" from "Agent" would be good.

Agno uses this design and provides different arguments for different providers, which brings better flexibility and stronger control over the model. But the current design of fast-agent is impressive for rapid prototyping. It may need more consideration to balance them.

do they enter these through the TUI/Command Line or a different way

Maybe I'll integrate fast-agent and streamlit to build the demo APPs, I need to allow some users who don’t know how to use the command line to experience these demos.

[evalstate]

@ufownl -- are you OK if i move the api_key in to request_params? i'm cool either way and don't mind doing the work. wdyt?

[ufownl]

Maybe this is not a good idea, although it is indeed more closely related to API requests, but most providers set the API key when the client is initialized, and RequestParams should model the parameters that can be set to every request, in my opinion. Therefore, I prefer to make it an argument of the agent, so that we can set the model and its provider's API key at the same level when we create agents.

[evalstate]

You're right :) I'll get this merged and released shortly.