Semantic Kernel makes prompt preparation part of the program

Microsoft has released Semantic Kernel, an open-source SDK for combining language-model prompts with application code. Its March 17 announcement describes a route from a user’s request to functions, contextual memory and external services. The launch implementation reveals a practical distinction: preparing a prompt can itself run registered functions, before the main language-model request begins.

The launch announcement presents C# as the starting point, with Python available separately in an experimental preview branch. TypeScript and other languages are possibilities, not announced implementations. The launch-day repository labels the project early alpha. Its C# getting-started example uses a prerelease package and an OpenAI or Azure OpenAI service key; that example isn’t a promise that every deployment runs locally.

File photo: Microsoft buildings, efes, 2015. CC0 1.0, via Wikimedia Commons. Recompressed and responsively cropped; not the Semantic Kernel launch.

A template can do more than insert text

Semantic Kernel groups functions into “skills.” A semantic function wraps a prompt, while a native function uses conventional code. Developers can chain them, but the connection also exists inside the prompt template.

The original template specification distinguishes a variable such as {{$input}} from a function call such as {{weather.getForecast}}. The latter invokes a registered function and inserts its result. The syntax supports a single explicit argument, rather than a general-purpose programming language with loops and conditional blocks.

That distinction affects when work happens. In the C# implementation, rendering completes before the text-completion request is sent. A template can therefore gather live information through a native function before asking the model to write an answer. Depending on the registered function, rendering may involve external calls rather than just string substitution. This is application-controlled composition, not a claim that arbitrary model output is automatically executable code.

Creating a plan isn’t executing it

The launch PlannerSkill exposes separate creation and execution functions. Creation supplies descriptions of available functions to a semantic function and stores the resulting XML plan. Execution passes that plan to a runner that invokes registered functions.

An application can use that separation to examine a generated plan before executing it. It shouldn’t mistake the separation for a built-in human-approval requirement. Nor does generating a plan supply credentials or implement a missing business operation: the functions available to the application remain consequential.

The ordinary kernel pipeline also checks for errors between function calls and returns when an error occurs. That explains where a chain stops, not whether an earlier external action has been undone.

Memory needs its own configuration

The kernel builder starts with NullMemory. Semantic memory isn’t populated automatically by creating a kernel. The supplied implementation pairs an embedding generator with storage: saving information generates an embedding, while searching generates a query embedding and asks the store for nearby matches. Choosing a model for text completion doesn’t, by itself, complete that memory setup.

These observations come from the launch-day source, not a runtime or security test. The repository’s MIT licence permits software reuse subject to its notice requirements and supplies the software without warranty; it doesn’t grant access to a hosted model service or establish rights to Microsoft branding.