1 Overview: From One Orchestrated Turn to Autonomous Workflows

Tutorial 17 gave the kernel one job per call: given a message, use automatic function calling to invoke the right plugin functions and produce an answer, in one orchestrated turn. This tutorial extends that into autonomy across many turns and many participants. An agent is a component with a goal, instructions, and access to functions that can reason across a conversation rather than answer once. A planner asks the model to compose your functions into a multi-step plan before anything runs. And orchestration patterns coordinate multiple agents — sequentially, concurrently, in a group chat, or by handoff — into workflows no single call could express.

This is an advanced tutorial: it assumes you are comfortable with the kernel, plugins, native and prompt functions, and automatic function calling from tutorial 17, and it builds four things on top of that foundation — agent framework concepts, planner patterns, orchestration patterns, and how to build an orchestrated multi-step workflow end to end. Every capability here is a natural extension of what you already understand: an agent is a kernel with a persistent goal and thread; a plan is what automatic function calling does, made explicit and inspectable; orchestration is several agents doing what one agent does, coordinated.

2 Learning Objectives

• Explain the agent framework concepts in Semantic Kernel: agents, instructions, threads, and how they extend the kernel and plugins from tutorial 17.
• Describe planner patterns, including function-calling-based planning, and when an explicit plan is preferable to automatic function calling.
• Compare orchestration patterns — sequential, concurrent, group chat, and handoff — and identify which fits a given multi-agent problem.
• Build an orchestrated multi-step workflow in .NET combining agents, a plan, and a termination strategy.
• Apply guardrails — termination strategies, turn limits, and human-in-the-loop checkpoints — to autonomous, multi-turn AI systems.

3 Prerequisites

• Tutorial 17 in full: the kernel, connectors, plugins, native and prompt functions, KernelArguments, semantic memory, and automatic function calling.
• Tutorial 12's function-calling loop and its safety disciplines (validation, authorization, idempotency, structured errors) — every agent and plan still needs them.
• Comfort with async/await and C# collections, since orchestration code coordinates multiple in-flight operations.
• An Azure OpenAI chat deployment and the plugins you built in tutorial 17 (an OrderPlugin or similar) are ideal to reuse here.

4 Key Concepts: Agents, Plans, and Orchestration

Three ideas extend tutorial 17's single-turn orchestration into multi-turn autonomy. An agent wraps a kernel with a persistent goal, instructions, and a thread (conversation state), so it can reason across turns rather than answer once — automatic function calling within a longer-lived, purposeful conversation. A planner makes the model's function-composition explicit: instead of letting automatic function calling decide step-by-step inside one call, a planner asks the model to lay out a multi-step plan up front, which your code can inspect, log, or gate before executing. Orchestration coordinates multiple agents (or steps) into a workflow — sequential, concurrent, group chat, or handoff — for problems too broad for one agent to handle alone.

None of this removes tutorial 12's or tutorial 17's disciplines — validating arguments, authorizing as the user, idempotent actions, structured errors inside every function. It adds a layer above them: because agents and plans can take many actions with less human oversight per action, this tutorial adds termination strategies, turn limits, and human-in-the-loop checkpoints as the new, necessary controls for that added autonomy.

5 Deep Dive 1: Agent Framework Concepts in Semantic Kernel

Semantic Kernel's Agent Framework provides abstractions for building AI components that act across a conversation rather than answer once. A ChatCompletionAgent is the concrete type you will use most: it wraps a kernel (with its plugins) plus instructions — a persistent system-level goal, like 'You are an order-support agent; use the OrderPlugin for facts and never invent order details' — and can be invoked repeatedly against an agent thread, the conversation state that persists across those invocations. Where tutorial 17's kernel answered one message, an agent maintains context and purpose across many.

using Microsoft.SemanticKernel.Agents;

// The agent wraps a kernel (with plugins already registered) and instructions.
ChatCompletionAgent agent = new()
{
    Name = "OrderAgent",
    Instructions = "You are an order-support agent. Use OrderPlugin for order facts. " +
                   "Never invent details. Ask for clarification if the order number is missing.",
    Kernel = kernel      // already has OrderPlugin registered (tutorial 17)
};

// A thread holds conversation state across multiple turns.
AgentThread thread = new ChatHistoryAgentThread();

await foreach (var response in agent.InvokeAsync("Where is my order ORD-1042?", thread))
{
    Console.WriteLine(response.Message.Content);
}

// A later turn reuses the same thread, so context (e.g. the order number) can persist.
await foreach (var response in agent.InvokeAsync("And what carrier is it with?", thread))
{
    Console.WriteLine(response.Message.Content);
}

6 Deep Dive 2: Planner Patterns

Automatic function calling (tutorial 17) already lets the model choose functions step by step, inside one InvokeAsync call — but that choice happens implicitly, one step at a time, with no plan you can inspect before it runs. A planner makes the composition explicit: given a goal and the kernel's available functions, it asks the model to produce a plan — a structured sequence of function calls — that your code can log, review, modify, or gate before any step executes.

The dominant planner pattern in modern Semantic Kernel is the function-calling planner: it relies on the same native function-calling capability of the model that powers automatic function calling, but surfaces the result as an inspectable plan rather than letting the kernel silently execute each step as it's decided. Earlier Semantic Kernel versions also had dedicated planner types (e.g. a stepwise or handlebars planner) that generated plans via specialized prompts; the trend has moved toward using the model's native function-calling strength directly, since it is both simpler and more reliable than bespoke planning prompts.

// Automatic function calling (tutorial 17): implicit, step-by-step, inside one call.
var autoSettings = new OpenAIPromptExecutionSettings
{
    ToolCallBehavior = ToolCallBehavior.AutoInvokeKernelFunctions
};
var direct = await kernel.InvokePromptAsync(
    "Check stock for SKU-8842 and, if available, get the price.",
    new KernelArguments(autoSettings));

// Planner pattern: ask for the plan FIRST, inspect it, then execute.
FunctionCallingStepwisePlanner planner = new(new FunctionCallingStepwisePlannerOptions
{
    MaxIterations = 5
});
FunctionCallingStepwisePlannerResult planResult = await planner.ExecuteAsync(
    kernel, "Check stock for SKU-8842 and, if available, get the price.");

// You can log/inspect planResult's steps and final answer before trusting it.
Console.WriteLine(planResult.FinalAnswer);

Choose a planner over plain automatic function calling when you need the plan itself as a first-class object: to log or audit the intended steps before they run, to insert a human-approval checkpoint between planning and execution, to cap the number of steps explicitly, or to build workflows where the plan spans multiple agents rather than one kernel's functions. For a single-turn task where the model choosing functions on the fly is acceptable, automatic function calling remains simpler and is usually the right default — planners earn their complexity when the plan needs to be inspected or governed, not merely executed.

7 Deep Dive 3: Orchestration Patterns

A single agent, however capable, is one perspective with one set of instructions. Some problems are better solved by multiple agents, each specialized, coordinated by an orchestration pattern. Semantic Kernel's Agent Framework supports several standard patterns for this coordination, and choosing the right one is a design decision, not a default.

using Microsoft.SemanticKernel.Agents.Orchestration;

// Conceptually: each agent's output becomes the next agent's input.
var orchestration = new SequentialOrchestration(researcherAgent, writerAgent, reviewerAgent);

OrchestrationResult result = await orchestration.InvokeAsync(
    "Produce a short brief on hybrid search in Azure AI Search.");
Console.WriteLine(await result.GetValueAsync());

Group chat and handoff orchestrations need explicit stopping rules, because multiple agents conversing can otherwise continue indefinitely. A termination strategy decides when the conversation is done — a goal-met check (perhaps another agent judging completion), a maximum turn count, or a specific agent's sign-off — and a selection strategy decides who speaks next in a group chat. Both are configuration you set deliberately, not defaults you can skip; an unbounded multi-agent conversation is a cost and correctness risk, not just an inefficiency.

8 Deep Dive 4: Building an Orchestrated Multi-Step Workflow

Putting agents, a plan (or automatic function calling), an orchestration pattern, and guardrails together yields a multi-step workflow: a task broken into ordered steps, possibly across specialized agents, executed and tracked as a whole with a defined stop condition. The design sequence is consistent regardless of pattern: define the goal, decide whether one agent or several are needed, choose an orchestration pattern if several, decide whether planning should be explicit or left to automatic function calling, and set a termination strategy and turn limit before running anything.

using Microsoft.SemanticKernel.Agents;
using Microsoft.SemanticKernel.Agents.Chat;

ChatCompletionAgent researcher = new() { Name = "Researcher", Instructions = "Gather facts only.", Kernel = kernel };
ChatCompletionAgent writer     = new() { Name = "Writer",     Instructions = "Draft from the Researcher's facts.", Kernel = kernel };
ChatCompletionAgent reviewer   = new() { Name = "Reviewer",   Instructions = "Approve, or request changes with reasons.", Kernel = kernel };

// A group chat where a termination strategy stops the loop once Reviewer approves,
// with a hard cap as a backstop against a conversation that never converges.
AgentGroupChat chat = new(researcher, writer, reviewer)
{
    ExecutionSettings = new AgentGroupChatSettings
    {
        TerminationStrategy = new ApprovalTerminationStrategy(approverName: "Reviewer")
        {
            MaximumIterations = 6      // hard backstop even if approval never comes
        }
    }
};

chat.AddChatMessage(new ChatMessageContent(AuthorRole.User,
    "Produce a short, accurate brief on hybrid search in Azure AI Search."));

await foreach (var message in chat.InvokeAsync())
{
    Console.WriteLine($"{message.AuthorName}: {message.Content}");
}

For workflows with real-world consequences — anything touching money, irreversible actions, or external communication — insert a human-in-the-loop checkpoint between planning and execution, or before a specific high-stakes step: surface the proposed plan or action to a person and require explicit approval before the workflow proceeds. This is the multi-agent, multi-step generalization of tutorial 12's rule that irreversible tool calls need confirmation — the more autonomous the system, the more deliberately that checkpoint must be designed in, not assumed.

9 Ecosystem and Tools

Everything here is layered directly on tutorial 17: an agent is a kernel with instructions and a thread; a planner surfaces what automatic function calling already does implicitly; orchestration patterns are ways of running several agents together. The next tutorial, AutoGen, introduces a different (Python-rooted, also usable from .NET) multi-agent framework, letting you compare philosophies once this tutorial's concepts are solid.

10 Use Cases

• Multi-turn support agent: a ChatCompletionAgent with an order plugin and a persistent thread handles an entire support conversation, not just one question.
• Content pipeline: sequential orchestration of Researcher, Writer, and Reviewer agents produces a reviewed document from a single topic prompt.
• Parallel review: concurrent orchestration runs several specialist agents (security, performance, style) over the same code change and aggregates their findings.
• Customer triage: handoff orchestration routes a conversation from a general assistant to a BillingAgent or TechnicalAgent based on what the user actually needs.
• Collaborative drafting: group chat orchestration lets a Writer and a Critic iterate on a document in a shared thread until a termination strategy detects approval.
• Governed automation: a planner produces an explicit multi-step plan for a business process, which a human approves before a workflow executes it.
• Complex task decomposition: a goal too broad for one agent (e.g. 'audit this codebase for security issues and propose fixes') is broken into an orchestrated multi-step workflow with specialized agents per step.

The pattern across these: whenever a task needs multiple turns, multiple perspectives, or multiple specialized skills coordinated toward one goal, agents and orchestration patterns provide the structure — always paired with a termination strategy and, for consequential actions, a human checkpoint.

11 Code Examples

These examples build on tutorial 17's kernel and plugin (OrderPlugin), showing an agent, a planner-produced plan inspected before execution, and a guarded group-chat orchestration.

using Microsoft.SemanticKernel.Agents;

ChatCompletionAgent orderAgent = new()
{
    Name = "OrderAgent",
    Instructions = "Answer order questions using OrderPlugin only. Never invent details.",
    Kernel = kernel   // OrderPlugin already registered
};

AgentThread thread = new ChatHistoryAgentThread();
await foreach (var r in orderAgent.InvokeAsync("Where is ORD-1042?", thread))
    Console.WriteLine(r.Message.Content);
await foreach (var r in orderAgent.InvokeAsync("When was it placed?", thread))
    Console.WriteLine(r.Message.Content);   // thread supplies the order context

// Ask for a plan, log it, and only then let it run — the governance planners exist for.
FunctionCallingStepwisePlanner planner = new(new() { MaxIterations = 5 });
FunctionCallingStepwisePlannerResult planResult =
    await planner.ExecuteAsync(kernel, "Cancel order ORD-1042 and notify the customer.");

// Because this plan includes an irreversible action (cancel), require approval
// before treating planResult.FinalAnswer as done -- human-in-the-loop checkpoint.
logger.LogInformation("Proposed plan result: {Result}", planResult.FinalAnswer);
bool approved = await humanApprovalService.RequestApprovalAsync(planResult.FinalAnswer);
if (!approved)
{
    logger.LogWarning("Plan rejected by reviewer; no cancellation executed.");
    return;
}
// Only on approval would the corresponding action actually be committed.
logger.LogInformation("Plan approved; action already reflected via planner execution.");

using Microsoft.SemanticKernel.Agents.Chat;

ChatCompletionAgent writer   = new() { Name = "Writer",   Instructions = "Draft the requested text.", Kernel = kernel };
ChatCompletionAgent reviewer = new() { Name = "Reviewer", Instructions = "Say APPROVED or request specific changes.", Kernel = kernel };

AgentGroupChat chat = new(writer, reviewer)
{
    ExecutionSettings = new AgentGroupChatSettings
    {
        TerminationStrategy = new KeywordTerminationStrategy("APPROVED")
        {
            Agents = new[] { reviewer },   // only Reviewer's approval counts
            MaximumIterations = 6           // backstop if approval never arrives
        }
    }
};
chat.AddChatMessage(new ChatMessageContent(AuthorRole.User, "Draft a 3-sentence summary of hybrid search."));

await foreach (var msg in chat.InvokeAsync())
    Console.WriteLine($"{msg.AuthorName}: {msg.Content}");

12 Step by Step: An Orchestrated Review Workflow

This walkthrough builds a small but complete orchestrated workflow — a Writer and Reviewer agent collaborating in a group chat with a termination strategy — then adds a human-approval checkpoint for a higher-stakes variant.

1. In a project with Microsoft.SemanticKernel and Microsoft.SemanticKernel.Agents installed, reuse the kernel and chat connector from tutorial 17.
2. Define two ChatCompletionAgents: Writer ('draft the requested text') and Reviewer ('reply APPROVED or list specific requested changes').
3. Create an AgentGroupChat with both agents, and configure a termination strategy that ends the chat when Reviewer's message contains APPROVED, restricted to Reviewer's messages only.
4. Set MaximumIterations as a hard backstop (e.g. 6) so the chat cannot run away if Reviewer never approves.
5. Send an initial user message with a drafting task, invoke the chat, and print each agent's turn — observe Writer draft, Reviewer critique or approve, and Writer revise if needed.
6. Confirm the loop actually stops on APPROVED, and separately confirm it also stops at MaximumIterations if you instruct Reviewer never to approve — proving both exit paths work.
7. Add a FunctionCallingStepwisePlanner call for a task involving your tutorial-17 OrderPlugin, and log the plan's result before treating it as final.
8. Identify one step in your workflow that is irreversible or consequential (e.g. an action that would cancel an order) and add a human-in-the-loop checkpoint: log the proposed action and require an explicit approval flag before it is allowed to execute.
9. Add step-by-step logging across the whole workflow — which agent or planner ran, what it produced, why termination did or didn't fire — and use it to narrate a full run.
10. Reflect on the design sequence you followed: goal, single agent or several, orchestration pattern, explicit plan or automatic function calling, termination strategy, turn cap, and human checkpoint — the checklist for any future multi-step workflow.

13 Limitations and Caveats

• API surface caveat: Agent Framework and planner types (ChatCompletionAgent, AgentThread, AgentGroupChat, termination/selection strategies, FunctionCallingStepwisePlanner, orchestration classes) have moved and continue to move quickly across Semantic Kernel versions. Names, namespaces, and construction patterns here are illustrative of shape and intent — verify against the installed package before relying on them.
• More autonomy, more compounding risk: an agent or multi-agent workflow that makes several decisions per run compounds the chance of a wrong step, and errors early in a workflow can propagate through later steps. Guardrails (validation inside functions, termination strategies, turn caps, human checkpoints) are not optional extras here — they are load-bearing.
• Cost and latency scale with participants and turns: each agent turn and each planning step is a model call; group chat and handoff orchestrations especially can consume many calls before termination, so turn caps also function as cost controls.
• Termination is not guaranteed correct by construction: a keyword or goal-met check can be gamed, misfire, or never trigger due to model variability — always pair a semantic termination condition with a hard maximum-iteration backstop.
• Debugging multi-agent systems is harder than single-call systems: with multiple agents and possibly non-deterministic turn order, step-by-step logging is not optional polish — without it, diagnosing why a workflow produced a given result is close to guesswork.
• Planners depend on the same function-calling reliability as automatic function calling: a model that struggles with tool selection produces unreliable plans, regardless of the planner wrapping it.
• Orchestration patterns are structures, not guarantees of quality: choosing 'group chat' does not make agents collaborate well; instructions, roles, and termination design still determine whether the result is actually good.
• This tutorial's safety patterns (human-in-the-loop, termination strategies) are necessary but not sufficient for production autonomy — broader responsible-AI and security review (tutorial 24) still applies to autonomous systems especially.

14 Best Practices

• Default to a single agent with automatic function calling; reach for multiple agents and orchestration only when the problem genuinely needs multiple perspectives or specializations.
• Give every agent narrow, specific instructions and a narrow plugin set — the same orthogonality discipline as tutorial 12's tools, now at the agent level.
• Pair every termination strategy with a hard MaximumIterations backstop; never trust a semantic 'are we done?' check alone.
• Insert a human-in-the-loop checkpoint before any irreversible or high-stakes action a plan or agent proposes — cancellations, payments, external communication.
• Use a planner (not bare automatic function calling) whenever you need to inspect, log, or gate the sequence of steps before it runs.
• Log every agent turn, plan, and termination decision with a correlation id — multi-agent debugging without this trace is impractical.
• Keep tutorial 12's function-level safety (validation, authorization, idempotency, structured errors) inside every function every agent can call — autonomy raises the stakes, it doesn't lower the bar.
• Choose the orchestration pattern by the problem's shape: sequential for pipelines, concurrent for independent perspectives, group chat for collaborative refinement, handoff for specialist routing.

20 Summary

• An agent (ChatCompletionAgent) wraps tutorial 17's kernel and plugins with persistent instructions and a thread, extending one-shot automatic function calling into reasoning across many turns.
• A planner makes the model's step composition explicit — a plan you can log, review, or gate — built on the same native function-calling ability as automatic function calling, and used when the sequence needs governance rather than just execution.
• Orchestration patterns coordinate multiple agents: sequential for pipelines, concurrent for independent perspectives, group chat for iterative collaboration (with a selection strategy), and handoff for specialist routing.
• A multi-step workflow combines agents, a plan or automatic function calling, and an orchestration pattern with a mandatory termination strategy and a hard iteration-cap backstop.
• Autonomy compounds risk: tutorial 12's function-level safety (validation, authorization, idempotency, structured errors) still applies inside every function, and higher autonomy adds termination strategies, turn caps, human-in-the-loop checkpoints for consequential steps, and step-by-step logging as necessary new controls.
• Orchestration patterns are structures, not guarantees of quality — good instructions, narrow scoping per agent, and deliberate termination design determine whether a multi-agent system actually outperforms a single well-built agent.

You now have the vocabulary and mechanics to build systems that reason across turns and coordinate multiple specialized agents toward a goal — agents, planners, orchestration patterns, and the guardrails that keep growing autonomy safe. Every capability here is a direct extension of tutorial 17's kernel and plugins, which is why none of it should feel like a new system so much as the same one, given more room to act. The next tutorial introduces AutoGen, a different multi-agent framework, letting you compare its philosophy against everything just learned here.

21 Next Steps

Next tutorial: The AutoGen Framework (autogen-framework). Having built agents, planners, and orchestration patterns in Semantic Kernel, the next tutorial introduces AutoGen — a complementary, Python-rooted multi-agent framework also usable from .NET — so you can compare its approach to conversation-driven multi-agent systems against the Agent Framework concepts just covered.

• Practice: build the group-chat Writer/Reviewer workflow from the walkthrough, then deliberately break the termination keyword to prove the MaximumIterations backstop actually fires.
• Practice: convert a single-agent tutorial-17 assistant into a ChatCompletionAgent with a thread, and hold a genuine multi-turn conversation that relies on earlier-turn context.
• Practice: use a function-calling planner on a task involving two of your plugin functions, log the plan's result, and add a human-approval gate before treating any consequential step as final.
• Practice: design (on paper first) which orchestration pattern fits a task of your choosing — sequential, concurrent, group chat, or handoff — and justify the choice before implementing it.
• Read: the official documentation for 'Semantic Kernel Agent Framework', 'Semantic Kernel planners', 'Agent orchestration in Semantic Kernel', and the current guidance on function-calling-based planning.