Structuring Semantic Kernel Functions with Plugins

In the evolving landscape of AI orchestration, passing raw text to a Large Language Model (LLM) is rarely enough. To build robust applications, we need models that can "do" things—retrieve data, calculate numbers, or interact with APIs. In Microsoft’s Semantic Kernel, the architecture that bridges the gap between mere text generation and functional execution is the Plugin.

The Concept: Plugins as Containers

Think of a Plugin in Semantic Kernel exactly as you would a Module or a Class in Object-Oriented Programming. It is a container designed to group logically related functions under a unified namespace.

While the kernel is the engine, the plugins are the tools. Whether you are grouping functions by domain (e.g., FinancePlugin, HRPlugin) or by capability (e.g., EmailSender, DataConverter), the goal is to simplify function management. When a query is sent to the LLM, the Kernel packages the user prompt, history, and available functions (prefixed with their plugin names) to help the model decide which tool to pull from the toolbox.

Under the Hood: The Protocol

When using Semantic Kernel, the framework abstracts the complexity of API calls. However, understanding the underlying protocol is crucial. Under the hood, the Kernel constructs a payload compatible with the OpenAI API (or similar providers).

Below is a demonstration of what this request looks like at the protocol level. Instead of the standard weather example, let’s imagine an E-commerce Inventory System where an LLM needs to check stock levels.

The Request Structure (cURL)

In this scenario, a user asks: "Do we have 'The Pragmatic Programmer' in the downtown warehouse?"

The Response

The LLM does not generate text; it generates a function call request:

Key Features of Kernel Plugins

1. Domain Specificity: Plugins prevent "namespace pollution." You can have a delete function in a FilePlugin and a delete function in a UserPlugin without conflict.
2. Hybrid Capabilities: A single plugin can contain Native Functions (C#/Python code for logic/math) and Semantic Functions (Prompts for creativity/reasoning). They are complementary, not antagonistic.
3. Dependency Injection: Plugins can encapsulate dependencies (like database services), making your code testable and modular.

Implementation Strategy: Import vs. Create

Semantic Kernel offers two distinct workflows for loading plugins. Choosing the right one depends on whether you need static integration or dynamic runtime configuration.

1. The "Import" Strategy (Immediate)

Use the ImportPlugin* methods when you want the plugin to be immediately available to the kernel's collection. This is best for straightforward integration.

1. kernel.ImportPluginFromPromptDirectory(): Scans a folder for semantic prompts.
2. kernel.ImportPluginFromType(): Scans a class for [KernelFunction] attributes.
3. kernel.ImportPluginFromObject(): Uses an instantiated object.

2. The "Create" Strategy (Deferred)

Use the CreatePlugin* methods when you need to instantiate a plugin object without adding it to the kernel immediately. This is critical in enterprise scenarios where you might need to:

1. Configure the plugin at runtime based on user permissions.
2. Combine multiple plugin objects before registration.
3. Modify properties dynamically.

The methods mirror the import strategy:

1. kernel.CreatePluginFromPromptDirectory()
2. kernel.CreatePluginFromType()
3. kernel.CreatePluginFromObject()

Best Practices

1. Use CreatePlugin* if you are building complex systems requiring runtime modification or conditional logic before the AI interacts with the tools.
2. Use ImportPlugin* for standard setups where the tools are known and static at startup.
3. Mix and Match: Don't hesitate to combine native code and semantic prompts in the same plugin. If a task is computational, write code. If it is linguistic, write a prompt.