Microsoft's Agent Framework shipped three releases in the first ten days of July, and two of the changes matter more than the version numbers suggest. The Skills API — the thing you use to package a bundle of tools, resources, and scripts an agent can pull in on demand — left experimental. And a new piece of middleware lets you drop a message into a running agent mid-turn, so you can correct a live run instead of killing it and starting over.
If you build on this framework, those are the two lines to read. Everything else — including the progressive MCP disclosure that also shipped in 1.11.0 — is polish on top.
Skills is stable now — that's the real headline#
Experimental APIs in Agent Framework come with no promise: the signatures can move between minor versions, and if you shipped on top of one you shipped on sand. Python 1.11.0 (July 10) dropped the experimental designation from Skills, and Microsoft's DevBlog announced Agent Skills for .NET is now released. The abstraction is the same idea a lot of teams have been hand-rolling — a named, loadable unit that bundles the tools, files, and scripts an agent needs for a task — but now it's a first-class, stable primitive on both runtimes.
Why care? Because "stable" is what lets a skill become a product surface. You can publish skills, version them, and let agents discover and load them without betting your roadmap on an API that might change under you next release.
A skill you can build a business on is a different object than a skill you're afraid to depend on. That's the whole change.
Message injection: steer the run, don't restart it#
The subtler win is message-injection middleware. Agent Framework's core added a way for tools or host code to enqueue messages into an active run — those queued messages are drained into the next model call within the same AgentSession.
Read that as the fix for a pattern everyone hits: your agent is three tool-calls deep into a long task, and you — or a monitoring system — realize it needs one more constraint, a correction, or a piece of context it didn't have. The old move was to abort, edit the prompt, and re-run from zero, losing the work in flight. Now the host can inject "actually, use the staging bucket, not prod" into the live session and let the next model call pick it up.
That's real-time steering — and it's one of three shipped ways to control a live run, which we compare in inject vs. interrupt vs. gate. It slots into the framework's middleware model. Agent Framework supports three middleware types — Agent Run, Function-calling, and IChatClient — so injection sits alongside logging, security checks, and result transformation as a cross-cutting concern you attach without touching your agent's core logic.
The security default that should be the default everywhere#
Skills can come from places you don't control, and Microsoft treated that as a threat, not a footnote. The tools a skill exposes — load_skill, read_skill_resource, and run_skill_script — require approval by default. The reason is sharp: a maliciously crafted skill script can throw an exception whose message embeds a prompt-injection payload, which then lands in the model's context as if it were legitimate output. Approval-by-default closes that door unless you deliberately open it. If you've been waving skill execution through, this is the release that decides for you.
Foundry Hosting got the multi-tenant piece#
The .NET side did the unglamorous, load-bearing work. 1.13.0 (July 3) added per-user session isolation for Foundry Hosting on the v2 protocol, plus skill-approval configuration. Session isolation is the difference between "I can host one agent" and "I can host agents for many users without their state bleeding across the boundary." It also carried breaking changes — Foundry.Hosting experimental flags realigned to MAAI001, and caching was extracted into a separate CachingAgentSkillsSource decorator — so read the notes before you bump. 1.12.0 (July 2) aligned the file-editing tools with Python and added directory discovery for FileAccess operations.
What to do about it#
- If you're prototyping on Skills: the experimental caveat is gone. Pin to the release, and treat skills as a stable part of your architecture rather than a spike.
- If you supervise long-running agents: wire up message-injection middleware. A human-in-the-loop that can nudge without restarting is cheaper and less lossy than an abort-and-retry loop.
- If you load third-party skills: leave approval on. The exception-message injection path is exactly the kind of thing that looks paranoid until it isn't.
- If you host for other people: the .NET 1.13.0 session-isolation work is the prerequisite you were missing. Read the breaking changes first.
The pattern across all three releases is the same one the framework has been circling for months: give founders the primitives to run supervised autonomy — steer it, gate it, isolate it — instead of choosing between a locked-down assistant and an agent you can only watch. This is the release where those primitives stopped being experimental.
