July 7th, 2026
0 reactions

Agent Skills for .NET Is Now Released

Principal Software Engineer

You can now give your .NET agents reusable packages of domain expertise – instructions, reference documents, and scripts they load only when a task needs them – through a stable, production-ready API. Agent Skills for .NET in Microsoft Agent Framework has moved out of experimental preview – the [Experimental] attribute is removed and the API is stable. Teams can build skills, ship them independently, and combine them in any agent, with the governance controls enterprises need before putting agents into production.

If you’ve been following our earlier posts on file-based skills and authoring modes with script execution, everything described there is now stable and shipping.

What are Agent Skills?

Agent Skills is an open format for packaging domain expertise that agents discover and use on demand. Each skill has metadata and instructions – a SKILL.md file for file-based skills, or equivalent properties in code – optionally accompanied by scripts, reference documents, and other resources. The agent loads only what it needs, when it needs it, keeping the context window lean through a four-stage progressive disclosure pattern: advertise skill names → load instructions → read resources → run scripts.

The result is agents that gain specialized capabilities without bloating their core instructions or their context window – and expertise you author once and reuse across every agent that needs it.

For a full introduction to the format, see Give Your Agents Domain Expertise with Agent Skills.

What you can do with it

Enforce enterprise policy consistently

Package your company’s HR policies, expense rules, or IT security guidelines as skills. An employee-facing agent loads the relevant policy skill when someone asks “Can I expense a co-working space?” and answers from the policy itself – without every policy sitting in context at all times. Because the skill drives a repeatable, auditable workflow, every employee gets the same grounded answer.

Turn support playbooks into repeatable workflows

Turn your support team’s troubleshooting guides into skills. When a customer reports an issue, the agent loads the matching playbook and follows the documented steps – so resolution is consistent regardless of which agent instance handles the request.

Compose skills from multiple teams

Different teams can author and maintain skills independently – as file directories in a shared repo, or as packages on your internal NuGet feed – and you combine them into one agent without cross-team coordination. The agent decides which skill to use based on each skill’s description; you write no routing logic.

A great place to find some existing skills is in the Awesome Copilot repo for skills.

Three ways to author skills

The release supports three authoring styles, so each team can pick what fits how they work. All three plug into the same provider, and the agent treats them identically at runtime:

File-based skills – A directory with a SKILL.md, optional scripts, and reference documents. Good for skills that live in a shared repo and are maintained by non-developers or cross-functional teams.

Class-based skills – C# classes that package instructions, resources, and scripts for distribution through normal .NET workflows, including internal NuGet packages.

Code-defined skills – Skills created directly in application code. Useful when a skill needs to be generated dynamically or close over application state.

Built for production

Giving an agent new capabilities is only useful if you can govern how it uses them. This release includes the controls you need to run skills in production.

Human-in-the-loop approval. The skills provider exposes three tools the agent calls to work with skills – load_skill (load a skill’s instructions), read_skill_resource (fetch a bundled resource), and run_skill_script (execute a bundled script). All three require approval by default, so nothing loads or executes without oversight – and you can relax it selectively for trusted operations.

Controlled script execution. Class-based and code-defined skill scripts run in-process. File-based scripts are delegated to a runner you provide, so you own sandboxing, resource limits, and audit logging.

Filtering. Expose only a curated subset of a shared skill library to a given agent, with a predicate that can make context-aware decisions based on the requesting agent or tenant.

Caching. Skills are resolved once and reused, with optional per-key isolation so one provider can serve different skill sets to different agents or tenants.

Extensible source pipeline. The underlying source classes are now public, so when the builder doesn’t fit your needs you can compose custom pipelines or integrate skills from your own registries.

As with any dependency that can influence agent behavior, review skill content before deployment, sandbox file-based scripts, and log which skills, resources, and scripts are used.

Getting started

Install the required .NET packages, then wire a skills provider into an agent:

using Azure.AI.OpenAI;
using Azure.Identity;
using Microsoft.Agents.AI;

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 = "MyAgent",
        ChatOptions = new() { Instructions = "You are a helpful assistant." },
        AIContextProviders = [skillsProvider],
    },
    model: deploymentName);

AgentResponse response = await agent.RunAsync("Help me with onboarding.");
Console.WriteLine(response.Text);

Why this matters

Agent Skills gives you a standard way to package, distribute, and govern domain expertise for your agents. Teams author skills independently, the builder composes them into a single provider, and approval keeps a human in the loop for anything that matters. Now that the .NET API is stable and released, you can build on it in production without the churn of an experimental API.

Author

Sergey Menshykh
Principal Software Engineer

0 comments