1 Overview: From Hand-Wiring to Orchestration

In tutorial 12 you wrote the function-calling loop by hand: define tools with JSON schemas, detect tool-call finish reasons, execute functions, append tool messages, and loop until the model produced an answer. In tutorial 15 you wired retrieval into a prompt by hand. That manual work taught you exactly what happens under the hood — and now Semantic Kernel lets you stop writing it. Semantic Kernel is an open-source .NET SDK for orchestrating AI: it connects models, prompts, plugins, and memory into an application, and it runs the function-calling loop for you with automatic function calling.

This tutorial covers Semantic Kernel end to end at an intermediate level: its architecture (the kernel, connectors, plugins, and memory); prompt engineering with reusable prompt templates; plugins and skills as containers of callable functions; semantic memory built on embeddings; building a working Semantic Kernel-based assistant; integrating an enterprise API as a skill so the model can reach real systems; and memory-based context retrieval, which is the RAG pattern from tutorial 15 expressed through the framework. Everything sits comfortably on the Azure OpenAI deployments and Azure AI Foundry project from earlier tutorials.

2 Learning Objectives

• Describe the Semantic Kernel architecture: the kernel, connectors, plugins, kernel functions, and memory.
• Do prompt engineering with reusable prompt templates and KernelArguments instead of inline strings.
• Build plugins (skills) containing native functions and prompt functions the kernel can call.
• Use semantic memory and embeddings to store and recall text by meaning.
• Build a Semantic Kernel-based assistant that answers using automatic function calling.
• Integrate an enterprise API as a skill so the model can invoke real backend operations safely.
• Implement memory-based context retrieval — the RAG pattern via Semantic Kernel memory.

3 Prerequisites

• Tutorial 12: function calling and tools — the manual loop Semantic Kernel automates.
• Tutorial 11 and 15: embeddings, vectors, and the RAG retrieve-augment-generate pattern.
• Tutorials 13–14: IChatService, dependency injection, and clean layering — Semantic Kernel registers in DI the same way.
• An Azure OpenAI chat deployment and an embedding deployment (text-embedding-3-small), configured via user secrets or a Foundry connection.

4 Key Concepts: The Kernel and Its Parts

Semantic Kernel's job is orchestration — coordinating models, prompts, functions, and memory into a working flow — and its parts are few. The kernel is the center: a container that holds configured AI services (via connectors) and plugins, and runs prompts and functions through them. A connector adapts the kernel to a provider — an Azure OpenAI chat model, an embedding model, a vector store. A plugin (historically called a skill) is a named group of related kernel functions. A kernel function is one callable unit, either a native function (C# code) or a prompt function (a prompt template). And semantic memory stores and recalls text by meaning using embeddings and a memory store.

The unifying idea is that Semantic Kernel treats prompts and code as the same kind of thing: both are kernel functions the kernel can call, compose, and — with automatic function calling — let the model choose among. That uniformity is what turns the scattered mechanics of earlier tutorials into one coherent programming model. Register the kernel in dependency injection like any other service, and your application orchestrates AI the same disciplined way it does everything else.

5 Deep Dive 1: Architecture and Prompt Engineering

You build a kernel with a builder, adding connectors for the services you need. Once built, the kernel can invoke functions — including prompt functions, which is where prompt engineering with Semantic Kernel lives. Instead of concatenating strings inline, you define a prompt template: a parameterized instruction with placeholders like {{$input}} that the kernel fills from KernelArguments before sending to the model. A prompt template is reusable, testable, and separable from code — the same maturity leap that DTOs brought to web contracts, now for prompts.

using Microsoft.SemanticKernel;

// Build the kernel with an Azure OpenAI chat connector.
IKernelBuilder builder = Kernel.CreateBuilder();
builder.AddAzureOpenAIChatCompletion(
    deploymentName: "gpt-4o-mini",
    endpoint: endpoint,
    apiKey: apiKey);          // or use a Foundry connection / Managed Identity
Kernel kernel = builder.Build();

// A reusable prompt template with a placeholder.
var summarize = kernel.CreateFunctionFromPrompt(
    "Summarize the following text in one sentence:\n{{$input}}");

// Invoke it, filling the placeholder from KernelArguments.
FunctionResult result = await kernel.InvokeAsync(summarize,
    new KernelArguments { ["input"] = longText });
Console.WriteLine(result);

Prompt functions can be created inline (as above), loaded from files, or organized into plugins so a set of prompts ships as a unit. The payoff of templating is the same discipline the course has stressed throughout: prompts become named, versioned, reviewable artifacts with explicit inputs, instead of string literals scattered through business logic. And because a prompt function and a native function are both just kernel functions, they compose together seamlessly.

6 Deep Dive 2: Plugins, Skills, and Automatic Function Calling

A plugin (skill) is how you give the kernel capabilities. A native function is a plain C# method annotated so the kernel — and the model — understand it: [KernelFunction] marks it callable, and [Description] tells the model what it does and what its parameters mean. This is the same information you wrote as a JSON schema by hand in tutorial 12, but now generated automatically from your method signature and attributes. You group related functions into a class and add it to the kernel as a plugin.

using System.ComponentModel;
using Microsoft.SemanticKernel;

public sealed class OrderPlugin
{
    [KernelFunction, Description("Gets the status and delivery estimate of a customer order by its order number.")]
    public async Task<string> GetOrderStatus(
        [Description("The order number, e.g. ORD-1042")] string orderNumber)
    {
        // Validate, then call the real backend/repository (tutorial 12's discipline).
        if (!orderNumber.StartsWith("ORD-")) return "{\"error\":\"invalid order number\"}";
        OrderStatus? s = await OrderRepository.FindAsync(orderNumber);
        return s is null ? "{\"error\":\"not found\"}"
                         : $"{{\"stage\":\"{s.Stage}\",\"eta\":\"{s.Eta}\"}}";
    }
}

// Register the plugin on the kernel.
kernel.Plugins.AddFromType<OrderPlugin>();

With plugins registered, automatic function calling is the headline convenience. Enable it in the execution settings, and the kernel runs the entire function-calling loop you wrote manually in tutorial 12: it advertises the plugin functions to the model, detects when the model wants to call one, executes the native function, feeds the result back, and repeats until the model produces a final answer — all inside one call. The tool-call finish reason, the assistant/tool message bookkeeping, the loop: gone from your code, handled by the framework.

7 Deep Dive 3: Memory, Embeddings, and Context Retrieval

Semantic memory is Semantic Kernel's abstraction for storing and recalling text by meaning. You add an embedding connector and a memory store (in-memory for demos, or a vector database like Azure AI Search for production), then save pieces of text; the kernel embeds each into a vector and stores it. Later you recall by a query, and the kernel embeds the query, finds the nearest vectors in the memory store, and returns the most semantically relevant saved texts. If this sounds exactly like tutorial 15's retrieval, that is because it is — semantic memory is the RAG retrieval step wrapped in a framework abstraction.

// Configure memory with an embedding connector and a store.
// (Exact memory API names vary by SK version — see section 13.)
var memory = new SemanticTextMemory(memoryStore, embeddingGenerator);

// Save facts; each is embedded and stored by meaning.
await memory.SaveInformationAsync("policies", id: "refund",
    text: "Refunds are available within 30 days of purchase with a receipt.");
await memory.SaveInformationAsync("policies", id: "shipping",
    text: "Standard shipping takes 3-5 business days.");

// Recall by meaning — 'get my money back' finds the refund policy.
await foreach (var hit in memory.SearchAsync("policies",
        "how do I get my money back?", limit: 2, minRelevanceScore: 0.7))
{
    Console.WriteLine($"{hit.Metadata.Id}: {hit.Metadata.Text} ({hit.Relevance:F2})");
}

Memory-based context retrieval combines the two ideas: recall the relevant remembered text for a question and inject it into the prompt before the model answers. You can do this explicitly — search memory, then pass the results as an argument to a grounded prompt function — or through plugins that make recall a function the model can call. Either way, the retrieve-augment-generate flow of tutorial 15 is preserved; Semantic Kernel just gives it named parts (memory, connectors, prompt functions) and removes the plumbing. For production, back the memory store with Azure AI Search so you get the hybrid search and scale of tutorial 15 beneath the framework abstraction.

8 Deep Dive 4: Building an Assistant & Integrating an Enterprise API as a Skill

Putting the parts together yields a Semantic Kernel-based assistant with strikingly little code. Build a kernel with a chat connector, register your plugins, enable automatic function calling, and invoke with the user's message — the kernel orchestrates prompts, function calls, and (if configured) memory recall to produce the answer. What was a 1,600-line hand-rolled controller in spirit becomes a kernel, a plugin class, and a few lines of setup.

using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.Connectors.OpenAI;

IKernelBuilder builder = Kernel.CreateBuilder();
builder.AddAzureOpenAIChatCompletion("gpt-4o-mini", endpoint, apiKey);
Kernel kernel = builder.Build();
kernel.Plugins.AddFromType<OrderPlugin>();          // native functions

// Let the model choose and the kernel run functions automatically.
var settings = new OpenAIPromptExecutionSettings
{
    ToolCallBehavior = ToolCallBehavior.AutoInvokeKernelFunctions
};

FunctionResult answer = await kernel.InvokePromptAsync(
    "Where is my order ORD-1042?",
    new KernelArguments(settings));
Console.WriteLine(answer);   // grounded in the order backend, loop handled for you

Integrating an enterprise API as a skill is the pattern that makes this valuable in the real world. Wrap a call to an internal service — an inventory API, a ticketing system, an HR service — in a native function inside a plugin, annotate it with a clear description, and register it. Now the model can invoke that enterprise system through the kernel whenever a user's request calls for it, with your code owning authentication, validation, and error handling around the actual HTTP call. The skill is the safe, described boundary between the model's intent and your backend.

public sealed class InventoryPlugin
{
    private readonly HttpClient _http;   // injected, points at the internal API
    public InventoryPlugin(HttpClient http) => _http = http;

    [KernelFunction, Description("Checks available stock for a product SKU in the warehouse.")]
    public async Task<string> CheckStock(
        [Description("The product SKU, e.g. SKU-8842")] string sku,
        CancellationToken ct = default)
    {
        // Your code owns auth, validation, and error handling around the real call.
        if (string.IsNullOrWhiteSpace(sku)) return "{\"error\":\"sku required\"}";
        using var resp = await _http.GetAsync($"/inventory/{sku}", ct);
        if (!resp.IsSuccessStatusCode) return "{\"error\":\"inventory service unavailable\"}";
        return await resp.Content.ReadAsStringAsync(ct);   // compact JSON back to the model
    }
}

// Registered like any plugin; created via DI so HttpClient is injected.
kernel.Plugins.AddFromType<InventoryPlugin>(serviceProvider: kernel.Services);

9 Ecosystem and Tools

Semantic Kernel is the orchestration layer that ties this course's building blocks together: it calls the Azure OpenAI deployments from tutorial 10, uses the embeddings of tutorial 11, automates the function calling of tutorial 12, registers in the DI of tutorial 13, and can use Azure AI Search from tutorial 15 as its memory store — all reachable through Foundry from tutorial 16. The advanced planner-and-agent capabilities are the subject of the next tutorial; this one establishes the framework's core so those build cleanly on top.

10 Use Cases

• Order/support assistant: rebuild tutorial 12's assistant with an OrderPlugin and automatic function calling, in a fraction of the code and with the loop maintained for you.
• Enterprise system copilot: wrap inventory, ticketing, or HR APIs as skills so one assistant can act across internal systems through described, guarded functions.
• Grounded knowledge bot: use semantic memory (backed by Azure AI Search) for memory-based context retrieval, answering from company documents.
• Reusable prompt library: package prompt functions (summarize, classify, extract) as plugins shared across applications with explicit inputs.
• Mixed prompt-and-code workflows: compose prompt functions and native functions in one flow — e.g. extract fields with a prompt function, then act on them with a native function.
• Multi-capability agent foundation: register several plugins and let automatic function calling coordinate them — the stepping stone to the planners and agents of tutorial 18.
• Model-agnostic apps: swap the connector to change providers without rewriting orchestration logic.

The common thread is orchestration: whenever an application needs to coordinate a model with real functions, reusable prompts, and remembered knowledge, Semantic Kernel provides the structure so you write intent, not plumbing. The more capabilities an assistant must juggle, the more the framework earns its place.

11 Code Examples

These examples assemble the pieces: a kernel with chat and embedding connectors registered in DI, a plugin, automatic function calling, and memory-based retrieval — the full framework surface for a grounded, tool-using assistant.

using Microsoft.SemanticKernel;

// The kernel registers like any service; consumers inject Kernel.
builder.Services.AddKernel()
    .AddAzureOpenAIChatCompletion("gpt-4o-mini", endpoint, apiKey)
    .AddAzureOpenAITextEmbeddingGeneration("text-embedding-3-small", endpoint, apiKey);

// Register plugins so every resolved kernel has them.
builder.Services.AddSingleton<OrderPlugin>();
builder.Services.AddSingleton<InventoryPlugin>();

// A reusable grounded prompt function: answer only from provided context.
var answerFromContext = kernel.CreateFunctionFromPrompt(
    """
    Answer the question using ONLY the context. Cite nothing outside it.
    If the context lacks the answer, say you don't know.

    Context:
    {{$context}}

    Question: {{$question}}
    """);

// Retrieve context from semantic memory, then invoke the function.
var recalled = new List<string>();
await foreach (var hit in memory.SearchAsync("policies", question, limit: 3, minRelevanceScore: 0.7))
    recalled.Add(hit.Metadata.Text);

FunctionResult grounded = await kernel.InvokeAsync(answerFromContext, new KernelArguments
{
    ["context"] = string.Join("\n", recalled),
    ["question"] = question
});
Console.WriteLine(grounded);

using Microsoft.SemanticKernel.ChatCompletion;
using Microsoft.SemanticKernel.Connectors.OpenAI;

// Automatic function calling lets the model use OrderPlugin + InventoryPlugin,
// while a memory-recall step (or a memory plugin) supplies grounding context.
var chat = kernel.GetRequiredService<IChatCompletionService>();
var history = new ChatHistory("You are an assistant. Use functions for live data; " +
                              "answer policy questions from provided context; never invent details.");
history.AddUserMessage(userMessage);

var settings = new OpenAIPromptExecutionSettings
{
    ToolCallBehavior = ToolCallBehavior.AutoInvokeKernelFunctions,
    Temperature = 0.2
};

ChatMessageContent reply = await chat.GetChatMessageContentAsync(history, settings, kernel);
Console.WriteLine(reply.Content);   // functions + memory orchestrated by the kernel

12 Step by Step: A Semantic Kernel Assistant

This walkthrough rebuilds the order/support assistant on Semantic Kernel, adds an enterprise skill, and grounds policy answers with semantic memory — the whole framework surface in one project.

1. Create a console project and add Microsoft.SemanticKernel plus the Azure OpenAI connector package.
2. Build a kernel with an Azure OpenAI chat connector (deployment, endpoint, credential from user secrets or a Foundry connection), and add an embedding connector for memory.
3. Write OrderPlugin: a native function GetOrderStatus annotated with [KernelFunction] and [Description], validating input and calling your order repository — the tutorial-12 tool, minus the JSON schema you no longer hand-write.
4. Write InventoryPlugin wrapping an internal inventory API in a native function CheckStock, taking HttpClient via DI so your code owns auth and error handling around the real call.
5. Register both plugins on the kernel (AddFromType), and enable automatic function calling via ToolCallBehavior.AutoInvokeKernelFunctions in the execution settings.
6. Ask 'Where is my order ORD-1042?' and confirm the kernel runs the whole function-calling loop — model picks GetOrderStatus, kernel executes it, model answers — without any loop code from you.
7. Set up semantic memory: an embedding connector plus a memory store (in-memory to start), and SaveInformationAsync a few policy statements (refund, shipping, returns).
8. Add memory-based context retrieval: for a policy question, SearchAsync the memory, pass the hits as {{$context}} to a grounded prompt function, and confirm the answer is grounded and refuses when the context lacks it.
9. Ask a mixed question ('Is SKU-8842 in stock and what's the refund policy?') and watch functions and memory combine in one orchestrated answer.
10. Compare with tutorial 12: note how much loop, schema, and message bookkeeping disappeared, and confirm the safety disciplines (validation, structured errors) still live inside your native functions.
11. Production step: swap the in-memory store for an Azure AI Search-backed memory store so recall uses real hybrid search at scale, unchanged above the memory abstraction.

13 Limitations and Caveats

• SDK evolution caveat: Semantic Kernel has moved quickly and its APIs have changed across versions — memory abstractions especially (ISemanticTextMemory, memory connectors, and newer vector-store abstractions) have been reworked, and execution-settings names (ToolCallBehavior vs newer function-choice settings) differ by version. The examples are correct in shape and intent; verify exact types and members against the installed package.
• Automation hides the loop, not the responsibility: automatic function calling runs the tutorial-12 loop for you, but validation, authorization, idempotency, and structured errors must still live inside every native function. The kernel does not vet your code.
• Automatic function calling costs tokens and rounds like the manual loop: every advertised function's description is prompt tokens, and each round is a model call. Keep plugins few and sharply described, and cap behavior where the SDK allows.
• Semantic memory is convenient but abstracts away control: for demanding retrieval you may want direct Azure AI Search with explicit hybrid queries and ranking (tutorial 15) rather than the memory front-end.
• The framework is orchestration, not intelligence: a poorly described plugin or a vague prompt template fails the same way the hand-rolled versions did. Good descriptions and prompts remain your job.
• Model choice still matters: automatic function calling depends on a model that supports tools well; weaker deployments choose functions unreliably.
• Debugging shifts: because the kernel runs the loop, understanding failures relies on logging/filters to see which functions were chosen and executed — enable that observability early.
• Lock-in consideration: adopting the framework's abstractions is a trade of control for productivity; it is a sound trade for orchestration-heavy apps, but a one-line completion call needs no kernel at all.

14 Best Practices

• Register the kernel and plugins in DI, and inject Kernel where you need it — treat it like any other service, with the service-layer discipline from tutorial 13.
• Write prompt functions as templates with explicit KernelArguments, not inline strings; version and review them like code.
• Give every native function a precise [Description] and describe each parameter — this replaces the hand-written JSON schema and drives the model's choices.
• Keep the tutorial-12 safety discipline inside native functions: validate, authorize as the user, stay idempotent, return structured errors — automation does not absolve you.
• Keep plugins few and orthogonal; overlapping functions confuse selection and cost tokens, exactly as overlapping tools did in tutorial 12.
• Enable function-invocation logging/filters from the start so you can see which functions the kernel chose and executed.
• Back semantic memory with Azure AI Search for production scale and hybrid retrieval; use in-memory only for demos and tests.
• Reach for the framework when orchestration is real (multiple functions, memory, reusable prompts); use a bare completion call for trivial one-shot prompts.

20 Summary

• Semantic Kernel is an open-source .NET SDK for orchestrating AI — a kernel that holds models (via connectors) and plugins and runs prompt and native functions through them, registered in DI like any service.
• Prompt engineering becomes prompt functions built on reusable, parameterized prompt templates filled from KernelArguments — named, versioned, testable artifacts instead of inline strings.
• Plugins (skills) group kernel functions; native functions are annotated C# ([KernelFunction], [Description]) whose schema is generated for you, and automatic function calling runs the entire tutorial-12 loop inside the framework.
• Semantic memory stores and recalls text by meaning via embeddings and a memory store, and memory-based context retrieval is the RAG retrieve-augment-generate pattern expressed through the framework — back it with Azure AI Search for production.
• You build an assistant with a kernel, a plugin or two, and automatic function calling in a fraction of tutorial-12's code, and integrate an enterprise API as a skill where your native function owns auth, validation, and error handling.
• Automation removes the loop and the schema, not the responsibility: keep validation, authorization, idempotency, and structured errors inside every native function, and enable function-call logging for visibility.

Semantic Kernel is where the course's building blocks become one programming model: it calls your Azure OpenAI deployments, uses your embeddings, automates your function calling, registers in your DI, and can use Azure AI Search as its memory — all reachable through Foundry. The framework does not replace what you learned; it embodies it, turning scattered mechanics into composable functions and orchestrated flows. With prompts and code unified as kernel functions and the model able to choose among them, you have the foundation for autonomy — which is exactly where the next tutorial goes, extending Semantic Kernel with planners and more advanced agent patterns.

21 Next Steps

Next tutorial: Semantic Kernel Advanced (semantic-kernel-advanced). With the kernel, plugins, prompts, and memory in hand, the advanced tutorial adds the capabilities that turn orchestration into autonomy: planners that ask the model to compose your functions into multi-step plans toward a goal, richer memory patterns, and more sophisticated agent behaviors — all built on the core you established here.

• Practice: rebuild tutorial 12's order assistant as an OrderPlugin with automatic function calling, and confirm the loop code you wrote before is entirely gone while the safety checks remain inside the function.
• Practice: write a prompt function with a {{$input}} placeholder, invoke it with KernelArguments, then load a second prompt from a file and compare the two ways of authoring prompts.
• Practice: wrap a small internal or public API as an InventoryPlugin-style skill, injecting HttpClient via DI, and let the model call it through the kernel.
• Practice: set up semantic memory with an in-memory store, save several facts, and implement memory-based context retrieval into a grounded prompt function — then swap the store for Azure AI Search.
• Read: the official documentation for 'Semantic Kernel overview', 'Plugins in Semantic Kernel', 'Function calling with Semantic Kernel', and 'Semantic Kernel memory and embeddings'.