Where the agent runs: Foundry hosted agents reach GA the week the whole runtime stack grew up
Edition 009 asked what the model costs. This week the question moved to where the agent runs. Build 2026 promised hosted agents in Foundry Agent Service by early July, and last week's edition flagged it as the thing to watch. It landed: hosted agents went generally available as a managed production runtime for agents that run for hours or days, with SLAs and 24/7 support, alongside GPT-5.6 GA and the Asia-Pacific Data Zone. Around it, the rest of the stack matured in the same days. Dataverse became the agent data platform inside every coding agent, Agent Framework's orchestration patterns reached 1.0 across Python and .NET, Agent Skills arrived for .NET, and enterprise governance followed the agents out to the telemetry stream.
This week's thread: the runtime stopped being a roadmap promise
For two months the Foundry story was a set of demos with a date on them. Build 2026 shipped the surface area in June, then told developers that hosted agents, the managed runtime that lets an agent run for hours or days without you provisioning the compute, would reach general availability by early July. Edition 009 put it at the top of the coming-up list. This week @Jeff Hollan's platform made it real: hosted agents in Foundry Agent Service are generally available, on one production runtime that takes agents built in Microsoft Agent Framework, the GitHub Copilot SDK, LangGraph, or any other harness. It did not arrive alone. GPT-5.6 reached general availability in Foundry the same day, the Asia-Pacific Data Zone went GA so those agents can run compliantly closer to APAC data, @Julie Koesmarno's Dataverse plugin reached every major coding agent so the data layer travels with the developer, and Agent Framework's orchestration patterns hit 1.0 across both SDKs. The pattern of the week is that every layer an agent needs to reach production, the runtime, the model, the data, the orchestration, and the governance, moved from preview to stable in the same few days. Edition 009 was about the price on the meter. This one is about the place the work actually happens, and who controls it.
Signal of the week
Hosted agents in Foundry Agent Service reach general availability
This week Microsoft made hosted agents in Foundry Agent Service generally available, giving developers a managed runtime for production agents. The service removes the work of provisioning and scaling compute for long-running agent orchestration, and it comes with production guarantees including SLAs and 24/7 support. Every session runs sandboxed with its own compute, memory, and durable state, so a workflow can run for hours, days, or weeks and pick up where it left off. It is one runtime for agents built with any framework and harness, Microsoft Agent Framework, the GitHub Copilot SDK, LangGraph, and others, and the agents it hosts can publish straight into Microsoft 365 Copilot and Teams. It is the general availability that edition 009 flagged as expected in early July, and it is the piece that turns a Foundry prototype into something you can actually operate.
Why it matters
This is the week the agent got a place to live. Until now, taking a Foundry agent to production meant owning the plumbing yourself: container registries, session state, identity wiring, compute that scales with a workload nobody can predict. Hosted agents move all of that behind an SLA, which is the difference between a demo you show a client and a system you put on a contract. For anyone advising on build versus buy, it changes the build side of the argument, because build no longer means also run the infrastructure. The one thing to check before you commit is the boundary: confirm which regions, which data zone, and which network posture your workload needs, because a runtime that runs for days is also a runtime that holds state for days, and where that state sits is now a design decision rather than an afterthought.
1The runtime arrives with a model and a region
Hosted agents did not ship on their own. The same Foundry announcement carried two other general-availability milestones that decide which model those agents run and where their data is processed.
GPT-5.6 goes GA in Foundry and the Asia-Pacific Data Zone opens
In the same announcement, GPT-5.6 became generally available in Microsoft Foundry, bringing OpenAI's newest frontier family, including the flagship Sol reasoning model with a one-million-token context window, to Foundry Agent Service and the model catalog. Microsoft also made the Asia-Pacific Data Zone generally available, so APAC customers can run frontier OpenAI models while keeping data processing inside the Asia-Pacific regions, with no separate environment to stitch together. Microsoft says everything in the post is live in Foundry today.
Why it matters
A production runtime is only as useful as the model you can point at it and the region you are allowed to run it in, and this week both moved. GPT-5.6 GA means the hosted agent above can call a current frontier model under the same Azure governance as the rest of the stack, rather than routing to an endpoint you assess separately. The Data Zone is the quieter but more consequential half for regulated work: data residency is usually what stands between an agentic proof of concept and a signed deployment, and an APAC zone removes one more reason a compliance team says no. Read the two together, because the model you pick and the zone you run it in are now the same decision.
2The data platform reaches every coding agent
The Dataverse plugin reaches Claude, Cursor, and GitHub Copilot
On July 6, Microsoft expanded the Dataverse plugin into additional coding-agent marketplaces, making it available for Claude, Cursor, and GitHub Copilot. Whichever coding agent a developer uses, they get the same Dataverse expertise: intelligent skill routing, enterprise-grade guardrails, and a consistent natural-language experience. Built on an open-source skill architecture, the plugin routes each request through the right tool, whether the Dataverse MCP server, the Python SDK, the PAC CLI, or the Dataverse CLI, while enforcing least-privilege security and respecting existing Dataverse role-based access control.
Why it matters
Dataverse is making itself the data layer that travels with the developer instead of the destination they have to leave their editor to reach. For a Power Platform practice, this is the week Dataverse stopped being a Microsoft-only story: your governed business data now shows up inside Claude and Cursor with the same RBAC it has in the Power Platform admin center, which is exactly the guardrail that makes a third-party coding agent safe to allow near real records. The strategic read is that @Julie Koesmarno's team is betting the value is not the surface but the data underneath it, and building for whatever agent the developer already opened. Note the primitive: it is a skill, the same portable unit showing up in Agent Framework and Copilot Studio this week, so the thing to standardize on is the skill, not the tool.
3The framework underneath reaches 1.0
The runtime hosts agents from any framework, but Microsoft's own framework had a milestone week too, with two releases that make the orchestration and the reusable-skill layers production-stable.
Agent Framework's orchestration patterns reach 1.0 across Python and .NET
On July 8, Python's agent-framework-orchestrations package reached 1.0.0, which puts Microsoft Agent Framework's orchestration layer at 1.0 across both Python and .NET. Sequential, concurrent, group chat, handoff, and magentic orchestration are now stable in both SDKs, so teams can pick the coordination pattern that fits the problem rather than choosing around SDK maturity. Magentic is the example @Evan Mattson highlights to show why it matters: the least hand-wired pattern, where you give it a goal, a manager, and a set of specialists, and the manager decides how the team works.
Why it matters
Multi-agent orchestration has been the part of the stack people demoed but hesitated to ship, because a preview coordination layer is a risky thing to put under a production workload. A 1.0 across both SDKs removes that hesitation and, paired with the hosted runtime above, closes a real gap: you can now build a multi-agent system with a stable orchestration pattern and run it on managed infrastructure with an SLA, without either half being a preview. If you have been waiting to move an orchestration proof of concept into a client engagement, the maturity argument that was blocking you is gone this week.
Agent Skills for .NET ships as a stable API
On July 7, Agent Skills for .NET moved out of experimental preview in Microsoft Agent Framework. You can now give .NET agents reusable packages of domain expertise, instructions, reference documents, and scripts, that they load only when a task needs them, through a stable, production-ready API with the experimental attribute removed. It brings .NET to parity with the Python skills capability and matches the reusable-instructions model already in Copilot Studio.
Why it matters
Watch what is converging. Copilot Studio added skills as markdown you can import from GitHub Copilot or Claude Code, the Dataverse plugin is built on an open-source skill architecture, and now Agent Framework has skills as a stable .NET API. The same primitive, a reusable, on-demand package of instructions, is becoming the common unit of agent capability across the low-code surface, the data platform, and the pro-code framework. For a team deciding how to package agent logic, the portable answer is emerging: author capability as a skill once, and it moves across surfaces rather than getting locked to whichever tool built it.
4Governance follows the agents to the edges
GitHub makes enterprise-managed OpenTelemetry export generally available
On July 8, GitHub made enterprise-managed OpenTelemetry export generally available for GitHub Copilot in Visual Studio Code and the Copilot CLI. Organizations can now mandate where Copilot sends its OpenTelemetry data, so telemetry flows to an approved collector without each developer setting OTEL_ environment variables by hand. The configuration is delivered centrally through enterprise-managed settings and controls the endpoint, headers, service name, and content-capture behavior for both the VS Code extension and the CLI agent host.
Why it matters
As agents spread into the editor and the terminal, the governance question stops being who can use them and becomes where their activity is recorded, and this closes that gap on the developer surface. Centrally pinned telemetry means an enterprise can route every Copilot agent's traces to its own collector instead of trusting per-developer config, which is what a security team needs before it will sign off on agent mode at scale. It is the same direction as the Foundry side of the week, observability and control moving to a single administered plane, just reaching the IDE. If you run Copilot across an org, the telemetry block in enterprise-managed settings is the control to own before your developers wire their own endpoints.
5One front door for the roadmap
Copilot Studio and the first-party agent roadmaps move to the Microsoft 365 Roadmap
As of July 2, feature updates for Microsoft Copilot Studio, Sales Agent, Finance Agent, and Service Agent are published on the Microsoft 365 Roadmap, creating a single destination for what is coming across Microsoft 365 apps, Copilot, and agents. As part of the move, Release Planner is no longer a source of feature information for these products, so saved Release Planner bookmarks for them should be repointed at the Microsoft 365 Roadmap.
Why it matters
This is a small operational change with a real consequence if you miss it. If your practice tracks Copilot Studio and the first-party agents through Release Planner, that feed stops carrying them, and the way you find out is usually that you stopped seeing updates you used to rely on. Repoint the bookmark now and tell whoever on your team owns roadmap-watching, because for a partner the roadmap is not trivia, it is how you tell a client what to plan for, and this week the source of truth for the agent products moved.
Voices to follow
- Microsoft Principal Group PM - DataverseJulie Koesmarno
Principal Group Product Manager at Microsoft, leading the Dataverse as Agent Data Platform team. Follow her to see where the governed data layer, MCP surface, and coding-agent plugins are heading before they ship.
Microsoft Principal Group PM - Dataverse as Agent Data Platform - Microsoft EVP - Copilot, Agents & PlatformCharles Lamanna
Executive Vice President for Copilot, Agents, and Platform at Microsoft. He owns the strategy behind Copilot Studio, Agent 365, and the Power Platform, so when the agent stack's direction shifts, it usually shifts because of a decision his org made.
Microsoft EVP - Copilot, Agents & Platform - Microsoft Partner Director - Foundry Agent ServiceJeff Hollan
Partner Director of Product at Microsoft, leading the Foundry agent platform: Agent Service, the Agent Framework, and the SDKs. The clearest source on how agents actually go from prototype to a hosted production runtime.
Microsoft Partner Director - Foundry Agent Service + Agent Framework - Microsoft Principal Cloud Advocate - Power Platform + agentsDaniel Laskewitz
Principal Cloud Advocate at Microsoft, ex-Power Platform MVP and co-founder of Forward Forever. One of the clearest voices on multi-agent systems and Power Platform governance - the bridge between the maker community and the product teams.
Microsoft Principal Cloud Advocate - Power Platform governance + agents - Microsoft Principal PM - Power Platform CATReza Dorrani
Principal Program Manager at Microsoft on the Power Platform CAT team. Where the maker community goes to see new Power Apps, Dataverse, and MCP capabilities demoed in practice rather than described in a blog.
Microsoft Principal PM - Power Platform CAT - ~56K followers - Microsoft VP - Product, Microsoft FoundryYina Arenas
Vice President of Product for Microsoft Foundry. She owns the developer surface where hosted agents, the agent catalogue and the Foundry tooling story get decided, and she posts the roadmap thinking behind them.
Microsoft VP - Product, Microsoft Foundry - Microsoft Software Engineer - CoworkBas Brekelmans
Software Engineer at Microsoft, started the Copilot Cowork project and previously CTO of Copilot Studio. The clearest voice on why Microsoft chose multi-model, MCP, and A2A architecture across the agent stack.
Microsoft Software Engineer, Cowork - ex-CTO Copilot Studio - Microsoft Principal PM - Copilot Studio (Power CAT)Henry Jammes
Principal Program Manager for Copilot Studio on the Power CAT team at Microsoft. Deep on agent-building mechanics, governance, and the release roadmap - a first-party source on what Copilot Studio can actually do.
Microsoft Principal PM - Copilot Studio (Power CAT)
Coming up
- July 2026 · SPFx 1.24 enters public preview with SharePoint Copilot Apps, with the SharePoint Framework CLI and general availability following in September 2026. It is the supported path to bring interactive SPFx UI into the Microsoft 365 Copilot canvas.
- Second half of July 2026 · The EU Digital Omnibus on AI is signed and published. The Council gave the text its final green light on June 29; signature and publication in the Official Journal are expected before month end, with entry into force three days after publication.
- August 2, 2026 · Core EU AI Act provisions take effect. The Omnibus postponed the high-risk dates, not these: general-purpose AI, prohibited-practice, and core transparency rules still start on schedule.
- November 10, 2026 · .NET 8 and .NET 9 reach end of support. Plan the move to .NET 10 LTS now, especially for any agent, Agent Framework, or Foundry workload pinned to the older runtimes.
This week's question
Every layer an agent needs to reach production moved to stable this week: the runtime, the model, the data, the orchestration, and the governance. Two questions for Monday. The practical one: now that the infrastructure is no longer yours to run, what is actually left for your team to own on an agent engagement, and is that the part you are charging for? And the deeper one: when the runtime, the data platform, and the framework all converge on the same primitives, the skill and the single control plane, does building on Microsoft's stack become the obvious default, or the moment you decide how much of your agent you want to be portable off it?
Get Agentic Weekly in your inbox
Every Monday morning. Unsubscribe any time.