ChatCompletionAgent Service Selection Issue with Multiple Registered Services in DI Container

[hexbit2]

We're experimenting with the Semantic Kernel Agent Framework (v1.63.0) in a .NET 8 Web API application and encountering a service selection issue when multiple Azure OpenAI chat completion services are registered in the dependency
injection container.

Setup

Service Registration in Program.cs:

// Register multiple Azure OpenAI services with different service IDs
builder.Services.AddAzureOpenAIChatCompletion(
    deploymentName: "gpt-4o-mini",
    apiKey: "api-key",
    endpoint: "https://resource.openai.azure.com/",
    serviceId: "default"
);

builder.Services.AddAzureOpenAIChatCompletion(
    deploymentName: "gpt-4o",
    apiKey: "api-key",
    endpoint: "https://resource.openai.azure.com/",
    serviceId: "advanced"
);

builder.Services.AddAzureOpenAIChatCompletion(
    deploymentName: "o4-mini",
    apiKey: "api-key",
    endpoint: "https://resource.openai.azure.com/",
    serviceId: "reasoning"
);

// Register kernel as transient
builder.Services.AddTransient<Kernel>();

Agent Creation:

  public class MyAIService : IMyAIService
  {
      private readonly ChatCompletionAgent _agent;

      public MyAIService(Kernel kernel, ILogger<MyAIService> logger)
      {
          _agent = new ChatCompletionAgent()
          {
              Name = "MyAgent",
              Instructions = "You are a helpful assistant.",
              Kernel = kernel
          };
      }
  }

Problem

When invoking the agent, we consistently get:
Microsoft.SemanticKernel.KernelException: No service was found for any of the supported types: Microsoft.SemanticKernel.ChatCompletion.IChatCompletionService, Microsoft.Extensions.AI.IChatClient. Expected serviceIds: default.

What We've Tried

1. Arguments with ServiceId: Used Arguments = new KernelArguments(new AzureOpenAIPromptExecutionSettings() { ServiceId = "default" }) - still fails
2. OpenAIPromptExecutionSettings vs AzureOpenAIPromptExecutionSettings: Tried both - same error
3. Manual service extraction: kernel.GetRequiredService("default") - works, but then how to pass to agent?
4. Dedicated kernel approach: Creating a separate kernel with only one service - works but feels awkward

Questions

1. How should we properly specify which chat completion service a ChatCompletionAgent should use when multiple services are registered?
2. Is there a direct way to inject a specific IChatCompletionService into ChatCompletionAgent? (Similar to Python's service=AzureChatCompletion() parameter)
3. Are we missing something in our service registration or agent configuration?

Looking at the ChatCompletionAgent source code, it uses GetChatCompletionService(kernel, arguments) which relies on the kernel's service selector, but it seems to fail despite our services being registered correctly.

Environment

• Semantic Kernel: 1.63.0
• Semantic Kernel Agents Core: 1.63.0
• .NET 8
• ASP.NET Core Web API

Any guidance would be greatly appreciated! We're excited about the agent framework but stuck on this service selection issue.

[hexbit2]

Update: Keyed Kernels Workaround - Works but Need Design Feedback

The workaround solution works! Here's what we implemented:

What We Did

Instead of trying to select services within a single kernel, we created multiple dedicated kernels using keyed services:

// Program.cs - Register dedicated kernels for each service

  if (aiSettings?.ChatCompletionServices?.AzureOpenAI != null)
  {
      foreach (var (serviceId, deploymentSettings) in aiSettings.ChatCompletionServices.AzureOpenAI)
      {
          if (deploymentSettings.Enabled)
          {
              builder.Services.AddKeyedTransient<Kernel>(serviceId, (serviceProvider, key) =>
              {
                  var kernelBuilder = Kernel.CreateBuilder();
                  kernelBuilder.AddAzureOpenAIChatCompletion(
                      deploymentName: deploymentSettings.DeploymentName,
                      apiKey: deploymentSettings.ApiKey,
                      endpoint: deploymentSettings.Endpoint
                      // No serviceId needed - this kernel only has one service
                  );
                  return kernelBuilder.Build();
              });
          }
      }
  }

  // Service class - Inject specific kernel
  public UserManagementAIService(
      [FromKeyedServices("default")] Kernel defaultKernel,
      ILogger<UserManagementAIService> logger)
  {
      _agent = new ChatCompletionAgent()
      {
          Name = "UserManagementAgent",
          Instructions = GetSystemInstructions(),
          Kernel = defaultKernel  // Each kernel has exactly one service
      };
  }

Results

• ✅ It works perfectly - No more "service not found" errors
• ✅ Clean separation - Each kernel has one dedicated service
• ✅ Agent architecture preserved - Still using ChatCompletionAgent properly
• ✅ Flexible - Can inject different kernels for different use cases

Design Concerns & Questions

While this approach works, I'm wondering about the design implications:

1. Resource overhead: Is maintaining multiple Kernel instances (one per AI service) resource-intensive or acceptable?
2. Architectural pattern: Is this the intended/recommended way to handle multiple AI services with agents, or are we working around a framework limitation?
3. Scalability: In a complex application with many different AI services, this could lead to a lot of kernel registrations. Is this sustainable?
4. Service selection: The original goal was dynamic service selection (e.g., choose gpt-4o-mini for basic tasks, gpt-4o for complex ones). This approach requires deciding at DI registration time rather than runtime. Is there a
   better pattern for intelligent model selection?
5. Framework evolution: Will future Semantic Kernel versions provide better support for service selection within ChatCompletionAgent?

Alternative Patterns Considered

• Multiple services in single kernel with Arguments/ExecutionSettings → Failed
• Manual service extraction + dedicated kernel creation → Worked but felt hacky
• Keyed kernels (current approach) → Works cleanly but raises design questions

Would love to hear from the SK team: Is this keyed kernel approach considered a best practice, or should we expect better service selection support in future versions?

Thanks for any guidance!

[pedershk]

I'd say you're on the right path. In the solution I work on, we deal with one Semantic Kernel instance per "Document Process" - or document type - each document type can have (different) assigned plugins and the embedding and chat models are user-selectable in the admin UI per document type.

We did previously register every SK instance in the DI container individually, but we no longer do this, as it requires a restart of the affected service each time a document type is added or its associated models are changed. Today, we use the factory pattern, where a SemanticKernelFactory (custom type) is registered in the kernel as a singleton. You can have a collection in the factory (for instance a ConcurrentCollection) where you add the kernels as they are registered - and resolve them per use.

So you'd inject the ISemanticKernelFactory or SemanticKernelFactory into wherever you're using a Kernel instance today (instead of directly injecting the Kernel - and then resolve the actual kernel in either the constructor or in any method.

It's up to you to determine lifetime, but we construct the kernel transiently, meaning we don't keep it around - so we DON'T store it in a collection in the factory. Performance is great, we don't notice any delay in construction, and a deployment of our solution typically hosts dozens of different kernels that are constructed many times per minute each.

This gives you a lot of flexibility in how you configure your kernels - in our case we store config in a DB and cache temporarily in Redis, and build the kernels from that.

i.e.

var kernel = await _kernelFactory.GetKernelForDocumentTypeAsync("AnnualReport");

In the factory (without sharing the whole rather large class):

/// <inheritdoc />
public async Task<Kernel> GetKernelForDocumentProcessAsync(string documentProcessName)
{
    using var scope = _serviceProvider.CreateScope();
    var documentProcessInfoService = scope.ServiceProvider.GetRequiredService<IDocumentProcessInfoService>();

    // Get document process info and create a new kernel
    var documentProcess = await documentProcessInfoService.GetDocumentProcessInfoByShortNameAsync(documentProcessName);
    if (documentProcess == null)
    {
        throw new InvalidOperationException($"Document process with name {documentProcessName} not found");
    }

    return await GetKernelForDocumentProcessAsync(documentProcess);
}

// <summary>
/// Creates a new Semantic Kernel instance for the specified document process.
/// </summary>
private async Task<Kernel> CreateKernelForDocumentProcessAsync(DocumentProcessInfo documentProcess)
{
    _logger.LogInformation("Creating new kernel for document process: {DocumentProcessName}", documentProcess.ShortName);

    using var scope = _serviceProvider.CreateScope();

    // Create kernel with document process-specific completion service via shared factory
    var kernelBuilder = Kernel.CreateBuilder();
    kernelBuilder.Services.AddSingleton(scope.ServiceProvider);

    // Use native SK AzureOpenAI connector to ensure tool-calling auto invocation works with Agents
    string deploymentName = documentProcess.AiModelDeploymentId.HasValue
        ? (GetAiModelDeploymentName(documentProcess.AiModelDeploymentId.Value) ?? _serviceConfigurationOptions.OpenAi.Gpt4o_Or_Gpt4128KDeploymentName)
        : _serviceConfigurationOptions.OpenAi.Gpt4o_Or_Gpt4128KDeploymentName;

    var loggerFactory = scope.ServiceProvider.GetService<ILoggerFactory>();
    var skChatService = new AzureOpenAIChatCompletionService(deploymentName, _openAiClient, modelId: null, loggerFactory: loggerFactory);
    kernelBuilder.Services.AddSingleton<IChatCompletionService>(skChatService);
    // Embedding generation provided globally; no per-kernel embedding registration.

    var kernel = kernelBuilder.Build();

    // Add required plugins to the kernel
    await EnrichKernelWithPluginsAsync(documentProcess, kernel);

    // Add function invocation filter(s)
    kernel.FunctionInvocationFilters.Add(
        scope.ServiceProvider.GetRequiredKeyedService<IFunctionInvocationFilter>("InputOutputTrackingPluginInvocationFilter"));

    kernel.FunctionInvocationFilters.Add(
        scope.ServiceProvider.GetRequiredKeyedService<IFunctionInvocationFilter>("PluginExecutionLoggingFilter"));

    return kernel;
}

We have several supporting services to enrich the kernel with plugins, set AzureOpenAiPromptExecutionSettings, and so on - but I don't share them here for brevity (it's also very application specific).

There's also a few steps in between here - but it's mostly about convenience methods to retrieve kernels based on different types of settings.

The benefit of getting the kernel transiently is that you have a reliable Data dictionary in the kernel across exactly one object lifecycle, be that a web request, an orleans grain tied to a specific content item, etc. That means you can say set an execution ID and use SK Invocation Filters to intercept things like function calls and log them or trace them. We use this to store information about what plugins were used by a particular generation event, for instance, and then adding that to the generated content.

Hope this helps!