.NET: [Bug]: Protocol hosting ignores AIAgent lifetimes and lacks consistent request-time selection #7733

Description

AddAIAgent explicitly supports Singleton, Scoped, and Transient registrations through its ServiceLifetime parameter. ASP.NET Core creates one request scope and exposes it through HttpContext.RequestServices.

The Agent Framework protocol hosting integrations currently bypass that request scope and resolve hosted agents or protocol services from the root provider.

Current behavior:

This means a scoped agent registration is either rejected by scope validation or effectively promoted/captured beyond its configured lifetime. It also prevents agent factories from consuming request-scoped services such as DbContext, tenant configuration, authenticated request state, or scoped tools.

There is a related usability gap: applications need a simple, consistent way to select a hosted agent at request time based on route values, authenticated claims, tenant configuration, headers, or other request state. Existing proposals have added AG-UI-specific factories, but the same requirement applies to AG-UI, OpenAI Chat Completions, OpenAI Responses, and A2A.

The solution should therefore cover two related capabilities consistently across hosting extensions:

1. honor the configured DI lifetime of an existing named/hosted registration;
2. select which hosted registration handles the request before resolving its agent and session services.

Expected behavior:

1. Hosted/named endpoint overloads resolve the keyed AIAgent from HttpContext.RequestServices for each request.
2. The associated keyed AgentSessionStore, isolation services, handlers, and protocol adapters are resolved from the same request scope.
3. Singleton registrations continue to return the same instance.
4. Scoped registrations return one instance per HTTP request and can consume scoped dependencies.
5. Transient registrations follow normal DI semantics.
6. Direct instance overloads remain fixed-instance APIs.
7. Session persistence remains stable across request-scoped agent instances. The hosting layer must use an explicit stable logical identity (for example, the hosted registration name) or fail clearly when a request-created agent cannot safely resume the previously serialized session. It must not silently reset persistence because a newly created agent received a new default ID.
8. Multi-user isolation continues to use AgentIsolationKeyProvider; resolving from the request scope does not make a client-supplied continuation ID an authorization boundary.
9. Each ASP.NET Core protocol integration provides the same request-time hosted-agent selection pattern.
10. Selection occurs before resolving the AIAgent, session store, protocol handler, or other agent-owned services.
11. The returned agent exposes a stable logical identity compatible with session persistence. The hosting integration resolves the associated session store and agent-owned services from the request scope.
12. A missing selection produces the protocol-appropriate not-found response; authorization failures remain application-owned and must occur before loading session state.
13. The selector can use ASP.NET Core request state, including route values and authenticated claims, without requiring IHttpContextAccessor inside the agent implementation.

A possible common API shape is to use Func<HttpContext, AIAgent> consistently across protocol integrations:

app.MapAGUIServer(
    "/agents/{agentId}/ag-ui",
    context => ResolveAgent(context));

app.MapOpenAIChatCompletions(
    "/agents/{agentId}/v1/chat/completions",
    context => ResolveAgent(context));

app.MapOpenAIResponses(
    "/agents/{agentId}/v1/responses",
    context => ResolveAgent(context));

app.MapA2AHttpJson(
    "/agents/{agentId}/a2a",
    context => ResolveAgent(context));

The returned agent must have a stable logical identity so its session state can be restored across requests.

Code Sample

Request-scoped hosted agent registration:

IHostedAgentBuilder hostedAgent = builder.Services.AddAIAgent(
    "assistant",
    (services, name) =>
    {
        var scopedDependency = services.GetRequiredService<MyScopedDependency>();
        var chatClient = services.GetRequiredKeyedService<IChatClient>("model");

        return chatClient
            .AsAIAgent(name: name)
            .AsBuilder()
            .Use((inner, services) =>
                new MyScopedAgentDecorator(inner, scopedDependency))
            .Build(services);
    },
    ServiceLifetime.Scoped);

hostedAgent.WithSessionStore(
    (services, _) => services.GetRequiredService<AgentSessionStore>());

app.MapAGUIServer(hostedAgent, "/ag-ui");
app.MapOpenAIResponses(hostedAgent, "/v1/responses");

hostedAgent.AddA2AServer();
app.MapA2AHttpJson(hostedAgent, "/a2a");

All endpoints should resolve the assistant registration from the active request scope and should observe the same scoped dependencies for that request.

The request-time factory receives HttpContext and returns the agent to invoke. The hosting integration resolves the associated session store and agent-owned services from HttpContext.RequestServices.

Error Messages / Stack Traces

With scope validation enabled, resolving a scoped registration from the root provider can fail with errors equivalent to:

Cannot resolve scoped service 'Microsoft.Agents.AI.AIAgent' from root provider.

Without validation, the scoped instance can become captive and behave like a singleton.

Package Versions

Current main versions of:

• Microsoft.Agents.AI.Hosting
• Microsoft.Agents.AI.Hosting.AGUI.AspNetCore
• Microsoft.Agents.AI.Hosting.OpenAI
• Microsoft.Agents.AI.Hosting.A2A
• Microsoft.Agents.AI.Hosting.A2A.AspNetCore

.NET Version

.NET 8, 9, and 10

Additional Context

Microsoft documentation confirms that:

• AddAIAgent(..., ServiceLifetime) defaults to singleton but accepts another DI lifetime.
• MEAI AddChatClient and AddKeyedChatClient also accept ServiceLifetime.
• ASP.NET Core creates one request scope and exposes scoped services through HttpContext.RequestServices.

Related issues and PRs that cover portions of this cross-host requirement:

• .NET: Support dynamic agent resolution in AG-UI endpoints (MapAGUI with factory delegate) #2988 — dynamic AG-UI agent resolution
• .NET: MapAGUI supports per-request agent selection #2343 — per-request AG-UI agent selection
• .NET: Support dynamic agent resolution in AG-UI endpoints #3162 — dynamic AG-UI factory/resolver
• .NET: Add MapAGUI overload that resolves the agent per request via a factory #6251 — current per-request AG-UI factory implementation with stable identity work
• .NET: ADR for unified dynamic agent resolution across AG-UI, Responses, and A2A #6643 — cross-host ADR
• .NET: Add factory delegate overload to MapAGUI for per-request agent resolution #6659 — AG-UI factory overload implementation
• .NET: Add name-derived MapAGUIServer overloads #2547 — hosted/name overload consistency; currently still resolves from the root provider

Request-time selection should use the same Func<HttpContext, AIAgent> pattern across every protocol integration. Returned agents must preserve stable identity and session compatibility across requests.