Agent Skills for .NET Left Preview: What It Changes in the Microsoft Agent vs Flow Decision

Every instruction, reference document, and worked example you stuff into a system prompt gets paid for on every single call. The task that needed three lines of guidance carries the entire prompt anyway. That is the quiet reason so many agent pilots stall: cost scales with how much expertise you packed in, not with how much the task used.

Agent Skills for .NET leaving experimental preview in Microsoft Agent Framework is Microsoft’s production answer to that problem. And it changes the terms of the Microsoft agent vs flow question that enterprise platform teams are arguing about in architecture reviews right now. Not the way the announcement hype suggests, though. The release removes the strongest objection to agents. It does not remove the reasons flows exist.

The real story is lazy-loading, not the [Experimental] removal

Lazy-loading deserves the same AI cost governance Azure spend gets everywhere else: attribution, quotas, and boundaries you can actually enforce. The [Experimental] attribute removal is what unblocks your CI/CD pipeline. The lazy-loading model is what changes your token bill.

The release post describes skills as packages of “instructions, reference documents, and scripts” that agents load “only when a task needs them.” That is the inversion that matters. Instead of one monolithic prompt that carries everything always, you get a small base prompt plus expertise that arrives on demand.

The concrete consequences:

• Smaller baseline prompts. Tasks that never touch the invoice-reconciliation domain never pay for the invoice-reconciliation instructions.
• Less context poisoning. Instructions for one domain stop bleeding into unrelated tasks, which is a correctness win, not just a cost win.
• A governance seam. A skill boundary gives you a place to attribute, quota, and route. A paragraph inside a system prompt does not.

Be precise about what lazy-loading does and does not give you. It reduces input tokens on calls that skip the skill. It does not, by itself, give you per-task cost attribution or guaranteed savings. You instrument the boundary yourself, and agents remain the least predictable pattern for total spend because the model, not you, decides how many tool calls and reasoning turns a task takes.

Takeaway: skill scoping is the AI cost governance Azure agents actually need. Design the boundaries before you migrate a single prompt.

What Skills solves that prompt engineering never will

The old pattern is familiar. A system prompt grows section headers. “Formatting rules.” “Escalation policy.” “Domain glossary.” Then a second agent needs the glossary, so someone copy-pastes it, and now you maintain two diverging copies of the same expertise with no version numbers and no tests.

A multi-thousand-token system prompt is not testable as a unit. You cannot diff its behavior across versions, because there are no versions. A skill package is testable, versionable, and swappable, and that difference matters more than the token math.

Here is a before-and-after, and it is illustrative math using industry-standard inputs; calibrate against your own data, actuals vary. A 4,000-token system prompt handling five domains becomes a 600-token base plus five skills of roughly 700 tokens each. A task touching one domain now carries about 1,300 input tokens of instruction instead of 4,000. Run your own numbers against the Azure OpenAI pricing page for your model and volume. The point is the shape of the curve, not a specific percentage, and I will not hand you an invented one.

Takeaway: if your system prompt has section headers, you already needed Skills.

Microsoft agent vs flow: where this release moves the line

Take a position, because your architecture review will demand one. Flows win when the process is fixed and the steps are known. Agents with Skills win when the expertise is the asset and the task path genuinely varies. Both conditions, not one.

That second condition is where teams fool themselves. If your domain knowledge changes monthly but the process is a stable five-step chain, you do not need an agent. You need a flow with the knowledge externalized where you can update it. Changing expertise alone does not justify handing control flow to a model. In the Power Automate and Copilot Studio world, that discipline is what keeps automation auditable, and it remains correct. I made the longer version of this argument in when not to build an agent at all, and this release does not retire a word of it.

What this release does change: it removes the strongest pro-flow argument for .NET shops, which was “agents are not production-stable yet.” That objection was legitimate while every skill-shaped abstraction in Agent Framework carried an [Experimental] attribute and a compiler warning. It is now gone.

The pattern I would defend in a review is the bounded agent. Wrap your deterministic flows as skills the agent can invoke. Enforce authorization at the skill boundary. Cap tool-call iterations. Keep compliance-critical paths in flows, full stop. Skills leaving preview did not make agents beat flows. It gave you a governance seam where both can coexist without the agent’s unpredictability leaking into your regulated processes.

Takeaway: decide by rate of change and path variability together. Knowledge changes monthly and paths vary: package the knowledge as a skill inside an agent. Knowledge changes but the path is fixed: keep the flow, externalize the knowledge.

Production-ready means your architecture review can say yes

Read the release wording carefully before you put it in a design doc. The post’s own words: skills ship “through a stable, production-ready API” and “the [Experimental] attribute is removed.” That is the claim, verbatim. Whether your governance board stamps it as general availability (GA) in the formal Microsoft support sense is a check you run against the microsoft/agent-framework repo release notes, not against a blog headline. Verify the current API surface there too, because preview-era signatures floating around older posts will not match what shipped.

The practical unblock is real either way. No suppressed compiler warnings in CI/CD. No hedged “subject to change” paragraph in your design document. Both show up as findings in enterprise architecture reviews, and both are now off the table.

Where this sits in an Azure AI reference architecture: skills are the domain layer, Agent Framework is the orchestration layer, and Azure OpenAI or Foundry-hosted models sit underneath. One detail worth writing into the design doc explicitly: the model never hosts or executes the skill. It selects and parameterizes through tool-calling, and your code runs the rest. Put that sentence in front of your security reviewers before they ask.

Takeaway: the stability milestone is the unblock; the lazy-loading model is the reason to move.

The packaging model is the sleeper feature

Versioned skills change how expertise moves between teams. Today, agent expertise travels by someone pasting a prompt into Teams. A versioned skill package travels the way NuGet packages do: pinned, diffable, upgradeable on your schedule. The invoicing team publishes invoice-rules at a version, three other teams consume it, and an update ships through a version bump instead of a copy-paste campaign.

One verification note before you promise this in a design doc: confirm in the repo whether version pinning is a framework feature or a discipline you enforce through your own package feed. The release post does not spell out the packaging mechanics, and either answer is workable. The discipline is yours to impose regardless.

Takeaway: version your first skill from day one, even if it never leaves your team.

Where this leaves Semantic Kernel plugins

Nowhere bad, and nobody at Microsoft has said otherwise. The positioning is clean: plugins and functions carry capabilities, typed tool calls that do things. Skills carry expertise, the instructions and reference material that tell an agent how to use those capabilities well. A skill can wrap or expose plugins. They are complementary layers, not competitors.

Teams with heavy Semantic Kernel plugin investment do not need a migration project. They need to stop doing one specific thing: cramming reference documents and multi-paragraph policy text into plugin descriptions because there was nowhere better to put them. That content is expertise wearing a capability costume, and it belongs in a skill. This is the same layering argument behind the three context layers of enterprise AI: execution, knowledge, and instructions are different assets with different change rates, and mixing them is what makes systems unmaintainable.

Takeaway: capabilities in plugins, expertise in skills. That is the convergence Microsoft is signaling.

Do this next

One migrated skill this week beats a quarter of evaluation. The exercise is small enough to finish before your next architecture review and produces the one artifact reviewers respect: your own measured numbers.

For step three, per-task token spend governance is what turns “we think skills save money” into a line on a chart. Migrate one bloated prompt into a versioned skill this week and let the token delta make the argument for you.