Enterprise AI | The .NET Blog

Microsoft Foundry June 2026: From Feature Drops to a Governed Agent Platform

Emiliano Montesdeoca — Sat, 18 Jul 2026 00:00:00 +0000

The June 2026 Foundry wave is not just another monthly digest. It marks a maturity transition from “build cool agents” to “operate agents as governed enterprise systems.” That distinction matters more than any single feature.

Original source: https://devblogs.microsoft.com/foundry/whats-new-in-microsoft-foundry-june-2026/

Three updates define the shift. First, agent publishing to Microsoft 365 Copilot and Teams reached GA, which moves distribution from custom integration projects to an opinionated deployment lane. Second, Toolboxes gained stronger discovery and execution controls, including tool search and routines. Third, observability plus optimization became a deliberate closed loop, not an afterthought.

My take: this is the most important pattern in the release. Tracing, evaluation, optimization, and controlled rollout form the minimum viable operating model for non-deterministic systems. If you have only one of those pieces, you have telemetry or tuning, not governance.

Claude GA inside Foundry is also strategic, but not mainly because of model quality. The bigger value is enterprise integration: Entra auth, RBAC, billing continuity, and policy alignment. Teams moving from direct model endpoints to Foundry should frame this as operational consolidation, not just provider swapping.

Autopilot agents are promising, but organizations should approach them with sober architecture choices. Shared-space collaboration in Teams can unlock productivity, yet it raises identity, permission, and accountability complexity fast. Start with bounded scopes and strict approval checkpoints before broad deployment.

Practical recommendations:

If you are already in pilot, prioritize instrumentation before capability expansion. Wire GenAI tracing first. Then establish evaluator suites tied to business outcomes, not generic model metrics. Only after that should you run optimizer loops and promotion workflows.
For toolbox-heavy agents, enable tool search early to reduce context noise and wrong-tool selection risk as catalogs grow.
For memory-enabled agents, define TTL and retention policy up front. Memory without lifecycle controls becomes compliance debt.

The most opinionated conclusion I can draw is this: Foundry is now less about “which model do I pick?” and more about “can I run agent behavior as a managed lifecycle?” Teams that answer the second question well will adapt to model churn easily. Teams fixated on model rankings will keep rebuilding fragile stacks every quarter.

June’s release makes one thing clear. Foundry is becoming an operations platform for AI systems, not just a development toolkit. That is a harder product to build, and a far more valuable one to adopt.

Agent Skills for .NET Is Stable, and That Changes Enterprise Agent Architecture

Emiliano Montesdeoca — Sat, 11 Jul 2026 00:00:00 +0000

Agent Skills for .NET moving to stable is one of the most practical milestones in the current agent ecosystem. It solves a core scaling problem: domain expertise does not belong inside one giant instruction blob.

Original source: https://devblogs.microsoft.com/agent-framework/agent-skills-for-net-is-now-released/

The design is elegant and pragmatic. Skills package instructions, resources, and optional scripts in reusable units that load on demand through progressive disclosure. That keeps context lean, reduces prompt bloat, and enables cross-team ownership of specialized knowledge.

My opinion: this is the first credible path to enterprise-grade agent maintainability in .NET stacks. Without modular expertise boundaries, every new policy or playbook update becomes a fragile prompt surgery exercise.

What matters most is not just modularity, but governance. The built-in approval model for loading skills, reading resources, and running scripts addresses the exact operational concerns security teams raise when agents move from demo to production. The extensible script execution model also makes responsibility explicit: if you want file-based script execution, you own sandboxing and audit posture.

Practical adoption pattern

Start with file-based skills for policy-heavy content maintained by mixed technical teams.
Use class-based skills when you need package distribution through NuGet and tighter engineering lifecycle controls.
Reserve code-defined skills for dynamic runtime assembly where stateful composition is necessary.

Add filtering early. Not every skill should be visible to every agent or tenant. Curated skill visibility is both a security control and a relevance control that improves routing quality.

Also, log everything: skill selection, resource reads, script execution requests, and approvals. If your incident review cannot reconstruct which skill influenced an answer, you do not have production observability.

The bigger strategy shift is this: skills turn agent behavior into a composable supply chain. Teams can version, review, and release expertise similarly to software components. That enables independent evolution without constantly retraining humans to rewrite mega-prompts.

The bottom line

If you are building .NET agents at enterprise scale, delaying this pattern will cost you. You will end up with instruction sprawl, inconsistent policy application, and brittle behavior under change.

Agent Skills does not remove complexity, but it moves complexity into governable components. That is exactly what mature software architecture should do. For many teams, this release is the moment where agent engineering in .NET starts to look like real platform engineering.

AI Alone Won’t Change the Business — the System Around It Will

Emiliano Montesdeoca — Sun, 14 Jun 2026 00:00:00 +0000

There is one line in the latest Microsoft AI platform essay that I think gets to the heart of the current moment:

the winners will not be the ones with the most demos, but the ones that turn AI into a governed, continuously improving system for real work.

That is exactly right.

This is one of the better strategic AI pieces because it gets the level right

Too many AI conversations still collapse into model talk.

Which model is smarter. Which model is cheaper. Which model is newest.

Those are not irrelevant questions, but they are too small if you are thinking like an enterprise.

The source article gets the scale of the challenge right. It says clearly that “What determines success is the system around the AI.”

That is the useful frame.

Because real enterprise value comes from the system around the model:

how agents are built
how they are grounded in enterprise context
how they are deployed
how they are governed
how they improve over time

That is what separates scattered experimentation from actual transformation.

Why I think this framing matters so much

If you only focus on the model, you get short-lived advantages.

If you focus on the system, you get leverage that compounds.

That is the key distinction.

And it aligns closely with where Foundry, GitHub, Microsoft IQ, and Agent Framework stories have all been heading lately.

My take

This is one of the stronger strategic pieces in the batch because it describes AI as an operating system for work, not as a set of disconnected demos.

That is the level enterprises actually need to think at.

And honestly, more of the public AI conversation should be happening at that level.

Original post: AI alone won’t change your business. The system running it will.