Principle:Microsoft Semantic kernel AI Service Registration
| Knowledge Sources | |
|---|---|
| Domains | AI_Orchestration, Service_Connector_Architecture |
| Last Updated | 2026-02-11 19:00 GMT |
Overview
AI Service Registration is the principle of binding external AI provider connectors to an orchestration kernel through a uniform service registration interface.
Description
In any AI orchestration framework, the kernel must communicate with one or more external AI providers (such as OpenAI, Azure OpenAI, or Hugging Face). Rather than hard-coding these provider connections, the service registration principle establishes a uniform mechanism for declaring which AI services the kernel should use, along with their configuration (model identifiers, API keys, endpoints, and so on).
The registration follows a connector pattern in which each AI provider is wrapped in an adapter that conforms to the kernel's internal service interfaces (such as IChatCompletionService or IChatClient). When a developer registers an AI service on the builder, the framework stores a factory or instance in the dependency injection container. At runtime, the kernel resolves the appropriate service by interface type, making the application code agnostic to the specific provider behind the interface.
This design achieves several important goals. First, it enables provider portability: switching from OpenAI to Azure OpenAI or another provider requires changing only the registration call, not the prompt invocation code. Second, it supports multi-service scenarios where the kernel hosts several AI services simultaneously, each identified by a unique service ID. The kernel can then select the appropriate service based on execution settings or explicit service selection. Third, because registrations flow through standard dependency injection, they benefit from DI lifecycle management, making it straightforward to inject HTTP clients, loggers, and other cross-cutting concerns.
Usage
Use AI service registration immediately after creating the kernel builder and before calling Build(). Register at least one AI service to enable prompt invocation. Register multiple services when your application needs to route different prompts to different models or providers.
Theoretical Basis
AI Service Registration is an application of the Strategy Pattern combined with Dependency Injection. The strategy pattern defines a family of algorithms (AI service connectors), encapsulates each one behind a common interface, and makes them interchangeable.
Formal structure:
Interface: IChatCompletionService
+ GetChatMessageContentsAsync(chatHistory, settings, kernel, cancellationToken)
Concrete strategies:
OpenAIChatCompletionService implements IChatCompletionService
AzureOpenAIChatCompletionService implements IChatCompletionService
HuggingFaceChatCompletionService implements IChatCompletionService
The registration step binds a concrete strategy to the interface in the DI container:
Pseudocode:
builder.services.AddSingleton<IChatCompletionService>(
new OpenAIChatCompletionService(modelId, apiKey))
When multiple services are registered, they are distinguished by a serviceId tag. The kernel's service selector uses this tag to resolve the correct service at invocation time:
Pseudocode:
Resolve(IChatCompletionService, serviceId) → concrete implementation
This decoupling ensures that the kernel's prompt execution logic is entirely independent of the underlying AI provider, following the Dependency Inversion Principle (the D in SOLID): high-level modules (kernel) should not depend on low-level modules (specific AI SDKs); both should depend on abstractions (service interfaces).