Semantic-Kernel | The .NET Blog

Agent Skills in .NET Just Got Seriously Flexible

Emiliano Montesdeoca — Tue, 14 Apr 2026 00:00:00 +0000

If you’ve been building agents with the Microsoft Agent Framework, you know the drill: you define skills, wire them into a provider, and let the agent figure out which one to invoke. What’s new is how you author those skills — and the flexibility jump is significant.

The latest update introduces three distinct authoring patterns for agent skills: file-based, class-based, and inline code-defined. All three plug into a single AgentSkillsProviderBuilder, meaning you can mix and match without any routing logic or special glue code. Let me walk you through each one and when you’d reach for it.

File-based skills: the starting point

File-based skills are exactly what they sound like — a directory on disk with a SKILL.md file, optional scripts, and reference documents. Think of it as the most straightforward way to give your agent new capabilities:

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

The SKILL.md frontmatter declares the skill name and description, and the instructions section tells the agent how to use the scripts and references:

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

Then you wire it up with SubprocessScriptRunner.RunAsync for script execution:

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

The agent discovers the skill automatically and invokes the provisioning script when it needs to check account status. Clean and simple.

Class-based skills: ship via NuGet

Here’s where it gets interesting for teams. Class-based skills derive from AgentClassSkill<T> and use attributes like [AgentSkillResource] and [AgentSkillScript] so the framework discovers everything via reflection:

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

The beauty here is that a team can package this as a NuGet package. You add it to your project, drop it into the builder, and it works alongside your file-based skills with zero coordination:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Both skills show up in the agent’s system prompt. The agent decides which one to use based on the conversation — no routing code needed.

Inline skills: the quick bridge

You know that moment when another team is building exactly the skill you need, but it won’t ship for a sprint? AgentInlineSkill is your bridge:

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

Add it to the builder just like the others:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

When the NuGet package eventually ships, you swap out the inline skill for the class-based one. The agent doesn’t know the difference.

But inline skills aren’t just for bridges. They’re also the right choice when you need to generate skills dynamically at runtime — think one skill per business unit loaded from config — or when a script needs to close over local state that doesn’t belong in a DI container.

Script approval: human-in-the-loop

For us .NET developers building production agents, this is the part that actually unblocks deployment conversations. Some scripts have real consequences — enrolling someone in benefits, querying production infra. Flip on UseScriptApproval and the agent pauses before executing any script:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

When the agent wants to run a script, it returns an approval request instead. Your app collects the decision — approve or reject — and the agent continues accordingly. In regulated environments, this is the difference between “we can deploy this” and “legal says no.”

Why this combination matters

The real power isn’t any single authoring pattern — it’s the composition. You can:

Start small with a file-based skill, iterate on the instructions, and ship it without writing C#
Ship reusable skills as NuGet packages that other teams can add with one line
Bridge gaps with inline skills when you need something now
Filter shared skill directories with predicates so your agent only loads what it should
Add human oversight for scripts that touch production systems

All of these compose through AgentSkillsProviderBuilder. No special routing, no conditional logic, no skill type checks.

Wrapping up

Agent skills in .NET now have a genuinely flexible authoring model. Whether you’re a solo developer sketching out a prototype with file-based skills or an enterprise team shipping packaged capabilities via NuGet, the patterns fit. And the script approval mechanism makes it production-ready for environments where you need that human checkpoint.

Check out the original announcement for the full walkthrough, the Agent Skills documentation on Microsoft Learn, and the .NET samples on GitHub to get hands-on.

Microsoft Agent Framework Hits 1.0 — Here's What Actually Matters for .NET Developers

Emiliano Montesdeoca — Fri, 03 Apr 2026 00:00:00 +0000

If you’ve been following the Agent Framework journey from the early Semantic Kernel and AutoGen days, this one is significant. Microsoft Agent Framework just hit version 1.0 — production-ready, stable APIs, long-term support commitment. It’s available for both .NET and Python, and it’s genuinely ready for real workloads.

Let me cut through the announcement noise and focus on what matters if you’re building AI-powered apps with .NET.

The short version

Agent Framework 1.0 unifies what used to be Semantic Kernel and AutoGen into a single, open-source SDK. One agent abstraction. One orchestration engine. Multiple AI providers. If you’ve been bouncing between Semantic Kernel for enterprise patterns and AutoGen for research-grade multi-agent workflows, you can stop. This is the one SDK now.

Getting started is almost unfairly simple

Here’s a working agent in .NET:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

That’s it. A handful of lines and you have an AI agent running against Azure Foundry. The Python equivalent is equally concise. Add function tools, multi-turn conversations, and streaming as you go — the API surface scales up without getting weird.

Multi-agent orchestration — this is the real deal

Single agents are fine for demos, but production scenarios usually need coordination. Agent Framework 1.0 ships with battle-tested orchestration patterns straight from Microsoft Research and AutoGen:

Sequential — agents process in order (writer → reviewer → editor)
Concurrent — fan out to multiple agents in parallel, converge results
Handoff — one agent delegates to another based on intent
Group chat — multiple agents discuss and converge on a solution
Magentic-One — the research-grade multi-agent pattern from MSR

All of them support streaming, checkpointing, human-in-the-loop approvals, and pause/resume. The checkpointing part is crucial — long-running workflows survive process restarts. For us .NET developers who’ve built durable workflows with Azure Functions, this feels familiar.

The features that matter most

Here’s my shortlist of what’s worth knowing:

Middleware hooks. You know how ASP.NET Core has middleware pipelines? Same concept, but for agent execution. Intercept every stage — add content safety, logging, compliance policies — without touching agent prompts. This is how you make agents enterprise-ready.

Pluggable memory. Conversational history, persistent key-value state, vector-based retrieval. Choose your backend: Foundry Agent Service, Mem0, Redis, Neo4j, or roll your own. Memory is what turns a stateless LLM call into an agent that actually remembers context.

Declarative YAML agents. Define your agent’s instructions, tools, memory, and orchestration topology in version-controlled YAML files. Load and run with a single API call. This is a game-changer for teams that want to iterate on agent behavior without redeploying code.

A2A and MCP support. MCP (Model Context Protocol) lets agents discover and invoke external tools dynamically. A2A (Agent-to-Agent protocol) enables cross-runtime collaboration — your .NET agents can coordinate with agents running in other frameworks. A2A 1.0 support is coming soon.

The preview features worth watching

Some features shipped as preview in 1.0 — functional but APIs may evolve:

DevUI — a browser-based local debugger for visualizing agent execution, message flows, and tool calls in real time. Think Application Insights, but for agent reasoning.
GitHub Copilot SDK and Claude Code SDK — use Copilot or Claude as an agent harness directly from your orchestration code. Compose a coding-capable agent alongside your other agents in the same workflow.
Agent Harness — a customizable local runtime giving agents access to shell, file system, and messaging loops. Think coding agents and automation patterns.
Skills — reusable domain capability packages that give agents structured capabilities out of the box.

Migrating from Semantic Kernel or AutoGen

If you have existing Semantic Kernel or AutoGen code, there are dedicated migration assistants that analyze your code and generate step-by-step migration plans. The Semantic Kernel migration guide and AutoGen migration guide walk you through everything.

If you’ve been on the RC packages, upgrading to 1.0 is just a version bump.

Wrapping up

Agent Framework 1.0 is the production milestone that enterprise teams have been waiting for. Stable APIs, multi-provider support, orchestration patterns that actually work at scale, and migration paths from both Semantic Kernel and AutoGen.

The framework is fully open source on GitHub, and you can get started today with dotnet add package Microsoft.Agents.AI. Check out the quickstart guide and the samples to get your hands dirty.

If you’ve been waiting for the “safe to use in production” signal — this is it.

Getting Started with Semantic Kernel

Emiliano Montesdeoca — Tue, 10 Feb 2026 00:00:00 +0000

Semantic Kernel (SK) is Microsoft’s open-source SDK for building AI orchestration into .NET (and Python/Java) applications. It’s the layer between your app code and LLMs: it handles prompts, plugins, memory, and multi-step planning so you don’t have to wire everything together manually.

This tutorial gets you from zero to a working SK-powered console app that calls an LLM and uses a plugin.

Prerequisites

.NET 8 or later
An OpenAI API key or an Azure OpenAI deployment

Step 1: Install the SDK

dotnet new console -n SkDemo
cd SkDemo
dotnet add package Microsoft.SemanticKernel

Step 2: Set up the kernel

The Kernel is the central object in SK. You configure it with an AI service (OpenAI, Azure OpenAI, or a local model):

using Microsoft.SemanticKernel;

var builder = Kernel.CreateBuilder();

builder.AddOpenAIChatCompletion(
 modelId: "gpt-4o-mini",
 apiKey: Environment.GetEnvironmentVariable("OPENAI_API_KEY")!
);

Kernel kernel = builder.Build();

Step 3: Invoke a prompt

The simplest thing SK does: send a prompt to the LLM and get a response.

var result = await kernel.InvokePromptAsync(
 "Summarize the key features of .NET 10 in three bullet points."
);

Console.WriteLine(result);

That’s it for the basics. But SK’s real power is in plugins.

Step 4: Create a plugin

A plugin is a C# class whose methods SK can call as tools. Here’s a simple one:

using System.ComponentModel;
using Microsoft.SemanticKernel;

public class DatePlugin
{
 [KernelFunction, Description("Returns the current date and time.")]
 public string GetCurrentDate() => DateTime.UtcNow.ToString("R");
}

kernel.ImportPluginFromObject(new DatePlugin());

Step 5: Let the kernel call the plugin

Enable automatic function calling so the LLM can invoke plugins when needed:

var settings = new OpenAIPromptExecutionSettings
{
 ToolCallBehavior = ToolCallBehavior.AutoInvokeKernelFunctions
};

var result = await kernel.InvokePromptAsync(
 "What is today's date? Format it nicely.",
 new KernelArguments(settings)
);

Console.WriteLine(result);

The model will call GetCurrentDate() automatically and incorporate the result into its response.

What to explore next

Planners — have SK break a complex task into steps and execute them
Memory — add semantic search over your documents using embeddings
Agents — build multi-agent workflows using the AgentGroupChat API

The Semantic Kernel repo on GitHub has a rich set of samples in dotnet/samples/ covering all of these scenarios.