Understand planners, functions, and enterprise orchestration in Semantic Kernel.
Semantic Kernel and Agent Framework solve related but different moments.
Learners avoid conflating SK, AutoGen, Foundry, and Agent Framework.
Why this matters: The lesson stays accurate for existing code and new production choices.
Problem anchor: a learner finds an old Semantic Kernel plugin tutorial and a new Microsoft Agent Framework workflow sample. Both are Microsoft agent material, but they teach different abstractions and production paths.
Semantic Kernel centers kernels, model services, plugins, functions, planners, memory, and agents in app code. Microsoft Agent Framework is positioned for newer production agents, workflows, state, middleware, telemetry, and .NET/Python parity.
An enterprise already has SK plugins wrapping CRM and document search. A lesson should explain the kernel/plugin model instead of pretending the app is greenfield Agent Framework.
A new agent workflow with human approval, telemetry, and Azure hosting may be better framed with Microsoft Agent Framework.
The kernel wires model services and callable functions.
Learners understand SK’s original center of gravity.
Why this matters: Existing SK code often revolves around plugins and function invocation.
In Semantic Kernel, application code registers model services and plugins with the kernel. Plugins can wrap native code functions, prompt functions, OpenAPI functions, MCP tools, or other capabilities.
Automatic function choice is useful, but plugin descriptions, schemas, auth, and side-effect classification still matter. The app owns security and evaluation.
| Option | Surface | Use for | Risk | When to choose | Cost | Complexity |
|---|---|---|---|---|---|---|
| Native function | Application code exposed to model/kernel. | Lookups, transformations, safe actions. | Broad authority if function is vague. | Use for bounded backend operations. | Low | Medium |
| Prompt function | Reusable prompt behavior. | Text transformations or generation patterns. | Harder to validate than code. | Use with evals. | Low | Low |
| OpenAPI/MCP function | External service wrapped as tool. | Shared APIs and host-neutral tools. | Permissions and auth need host policy. | Use with curated operations. | Medium | Medium |
Agent Framework is the newer Microsoft workflow-oriented layer.
Learners map Agent Framework concepts to production needs.
Why this matters: This avoids using SK plugin examples for workflow problems they do not naturally solve.
Microsoft Agent Framework combines agents and workflows with sequential, concurrent, branching, handoff, and group collaboration patterns. It also emphasizes middleware, telemetry, state/checkpoints, and integration with Microsoft hosting and identity.
Use it when the surrounding system is Microsoft-heavy: Azure OpenAI, Foundry, Microsoft 365, .NET services, enterprise identity, OpenTelemetry, or durable hosting.
A compliance assistant runs research, review, human approval, and publish steps inside Azure-hosted infrastructure. Agent Framework can express agents and workflow steps while telemetry flows into the Microsoft stack.
A small notebook demo with one function call may not need that layer.
The code should reveal roles and review points.
Learners see the intended production shape.
Why this matters: Concrete artifacts make the Microsoft stack less abstract.
Microsoft docs and samples vary by package, language, and version. A lesson can show the production shape while warning learners to check current SDK signatures before copying.
Spaced recall: from choosing frameworks, prototype the riskiest slice. For Microsoft stack, that may be identity, telemetry, or workflow approval.
# Pseudocode: check current Microsoft Agent Framework SDK signatures before copying. class Agent: def __init__(self, name, tools=None): self.name = name self.tools = tools or [] def search_kb(topic): return f"grounded notes for {topic}" researcher = Agent("researcher", tools=[search_kb]) reviewer = Agent("reviewer") workflow = [ ("research", researcher.name), ("review", reviewer.name), ("human_approval", "required before publish"), ] print(workflow)
The human_approval step explicitly gates publish after research and review.
The overview ends with governance and migration discipline.
Learners define production checks for Microsoft agent apps.
Why this matters: Casual migration can break state, tools, observability, or deployment.
Do not casually rewrite SK or AutoGen systems into Agent Framework without checking plugin parity, state shape, tool auth, telemetry, deployment, human review, and evals. A working demo is not a migration plan.
Azure examples may assume Azure identity, Foundry, Microsoft 365, or Durable Task. Call those assumptions out when teaching provider-neutral concepts.
Review the framework layer and operational assumptions.
Retrieval prompt: reconstruct the Microsoft stack by naming kernel, plugins/functions, SK agents, Agent Framework agents, workflows, state/checkpoints, middleware, telemetry, Azure/Foundry fit, and migration risks.
Take an existing Semantic Kernel plugin demo and write a migration-aware note: what remains SK, what would move to Agent Framework, what telemetry/state changes, and what must be tested before migration. Next rung: compare Microsoft Agent Framework with OpenAI Agents SDK.
Semantic Kernel was Microsoft's original SDK for building LLM-powered apps. How does the newer Microsoft Agent Framework relate to it?
The Agent Framework is Microsoft's newer, recommended production path that builds on Semantic Kernel ideas — but migration isn't automatic; you must verify feature parity before switching.
A developer registers a C# method as a plugin function on the kernel and enables automatic function choice. What is the key risk to communicate to the team?
Automatic function choice lets the LLM decide when and how to call tools, which can produce unexpected calls — teams must define clear tool contracts and add approval steps for high-stakes actions.
Which combination of Agent Framework capabilities makes it a better fit for enterprise Azure deployments than bare Semantic Kernel?
The Agent Framework layers Agents, Workflows, middleware, state, and telemetry on top of the kernel — exactly the pieces enterprises need for observable, controllable, Azure-integrated deployments.
You are sketching a Microsoft-style agent workflow that: (1) retrieves customer data, (2) drafts a refund decision, and (3) issues a refund via a payment API. Which step should have a human-approval gate, and why?
Irreversible or high-stakes external actions (like writing to a payment system) are where human-in-the-loop approval gates belong; read or draft steps carry far lower risk.
Before migrating a production Semantic Kernel app to the Agent Framework, what are the TWO most critical enterprise checks?
Feature parity (including language/SDK version support) and verified telemetry plus Responsible AI controls are the non-negotiable checks before any enterprise migration — skipping either creates compliance and reliability gaps.