Principle:Microsoft Semantic kernel Plugin Registration
| Knowledge Sources | |
|---|---|
| Domains | AI_Orchestration, Plugin_Architecture, Dependency_Injection |
| Last Updated | 2026-02-11 19:00 GMT |
Overview
Plugin registration is the process of making plugin functionality available to an AI orchestration kernel through type-based or instance-based registration at configuration time.
Description
Plugin Registration is the principle that governs how AI-callable function collections are introduced into the kernel's runtime environment. Before an AI model can invoke any function, the corresponding plugin must be registered with the kernel so that the kernel knows which functions exist, what their schemas look like, and how to invoke them.
In Semantic Kernel, registration occurs during the builder configuration phase, before the kernel is built. The framework provides multiple registration strategies to accommodate different scenarios:
- Type-based registration (AddFromType<T>()) tells the builder to instantiate the plugin class at build time using the DI container, scanning it for [KernelFunction] methods. This is the most common approach for plugins whose constructors may have dependencies resolved via dependency injection.
- Instance-based registration (AddFromObject()) accepts an already-constructed plugin instance and scans it for annotated methods. This is useful when the plugin has been pre-configured or when constructor injection is not applicable.
- Function-based registration (CreateFromFunctions()) allows manual construction of a plugin from a collection of KernelFunction instances, providing maximum control.
The registration process internally uses KernelPluginFactory to perform reflection over the target type, discover all methods marked with [KernelFunction], extract their [Description] metadata, and create the corresponding KernelFunction objects. These are then bundled into a KernelPlugin which is added to the kernel's Plugins collection.
Registration is additive: multiple plugins can be registered, and the kernel accumulates all their functions. When the AI model is invoked with function calling enabled, all registered functions across all plugins are presented to the model as available tools.
Usage
Use plugin registration at kernel build time for any plugin whose functions should be available to AI models. Type-based registration via AddFromType<T>() is the recommended default because it integrates with the dependency injection container and supports constructor injection. Use instance-based registration when you have a pre-existing object instance or when you need to configure the plugin before registration.
Theoretical Basis
Plugin Registration implements the Service Locator and Registry patterns within the context of AI orchestration. The kernel maintains a registry of plugins, each containing a set of functions. At invocation time, the kernel acts as a service locator, finding and invoking the requested function from its registry.
Formal model:
Let P be the set of all registered plugins and F(p) the set of functions within plugin p:
Kernel.Plugins = { p1, p2, ..., pk }
AvailableFunctions = Union( F(p1), F(p2), ..., F(pk) )
The registration operation R takes a type T and a service provider SP and produces a plugin:
R(T, SP) = KernelPlugin {
name: derive_name(T),
functions: { KernelFunction(mi) | mi in methods(T) AND has_attribute(mi, [KernelFunction]) }
}
Key invariants:
- Uniqueness: Each plugin name within the kernel must be unique. Attempting to register two plugins with the same name will fail.
- Completeness at build time: All plugins must be registered before Build() is called (or added to the kernel's plugin collection at runtime). Functions not registered are invisible to the AI model.
- DI integration: Type-based registration resolves the plugin instance through the DI container, enabling constructor injection of services like HttpClient, ILogger, or custom repositories.