Agent Hosting Extensions and AIAgent DI alternatives

[Daniel G Smith (danielgsmith)]

Hey Team,

I've spent some time looking through the hosting extensions (Microsoft.Agents.AI.Hosting & partner projects - OpenAI, AGUI, A2A) and I'm looking for some guidance on the best way to make these work for my use case.

My understanding is that currently all of these hosting extensions rely on the target AIAgent being injected via DI at startup and avalible to fetch from the IServiceProvider at runtime. Almost all of the extensions also explicitly target a single AIAgent on their respective IEndpointConventionBuilder extension methods. It looks like the only exception to this is a single MapOpenAIResponses extension that does not require an agent as a pram, but instead uses the AgentReference in the CreateResponse model to fetch the correct agent from DI. Please correct me if this understanding it wrong...

Now on to my problem - the way my system is setup requires that agents be created on the fly. Some come from configurations in remote storage not avalible immediately at startup, some are agent configurations passed in via seperate API's from clients, etc. So i can't really inject my agents in to the service collection at startup very easily. I basically need a way to use the extensions which does not require targeting a specific agent, but rather resolve the correct agent on a per request basis.

I'd really love to be able to use the hosting extensions... it would really help to make sure my system aligns with industry standards, consistent api patterns, etc. but I'm not really seeing a path where i can use them as is.

Is there a recommended pattern to handle this sort of dynamic agent creation behind the hosting extensions?

If not, would the team consider adding some sort of abstraction that allows for this sort of pattern? Maybe additional extensions that allow for something like a IAIAgentResolverFactory (build and resolve by name or some other attribute) - a default factory could obviously just fetch from the service provider still, but then I could have my own factory instead. Or maybe an extension that uses a Delegate to resolve agents by name? Agent names could be pulled from HTTP request path parms or query params...

Thanks for your help and guidance.

[Raj (rajshukla09)]

This is an important distinction, especially once agents start depending on request-scoped services such as tenant context, DbContext, authenticated user state, or scoped tools.

Resolving a scoped agent from the root provider can easily turn into a captive dependency problem, so resolving the agent and its related session services from HttpContext.RequestServices feels like the cleaner model.

The part I think becomes especially important with A2A is maintaining a stable logical agent identity even when the concrete agent instance is request-scoped, otherwise session restoration can become inconsistent.

I’ve been working through A2A and production hosting patterns in .NET here:
https://github.com/rajshukla09/building-ai-agents-with-dotnet-part-2

I’d be interested to see whether the hosting APIs eventually converge on one consistent request-time resolution model across AG-UI, OpenAI-compatible endpoints and A2A.