Microsoft Build 2026, Day 2: Windows Wants to Be the Home for AI Agents

If Day 1 was Microsoft showing off its seven new MAI models, Day 2 answered the obvious follow-up question: okay, where do these agents actually run? The theme was clear and, honestly, a little bold — Microsoft wants Windows and Foundry to be the runtime for AI agents, not just a place AI apps happen to live.

This landed differently for me this week, because I'd just spent two posts wiring up local models and then building a 300-line agent harness from scratch. Watching Microsoft announce the production-grade version of nearly every piece I hand-rolled — the loop, the sandbox, a local tool-calling model — was a bit surreal. Let me walk through the Day 2 developer announcements, with the usual caveat: I've checked these against Microsoft's official Windows Developer and Foundry blogs, and a lot of it is preview, not GA.

Windows as an agent runtime

The Windows Developer team's pitch is that the OS itself should be a first-class, sandboxed place for agents to do work. The concrete pieces:

• Aion 1.0 models (preview, coming months) — Microsoft's local model family for Windows. Two flavors: Aion 1.0 Instruct for on-device text intelligence, and Aion 1.0 Plan, a "reasoning and tool-calling model that enables fully local agentic capabilities." That second one is the headline for me — a model designed specifically to drive an agent loop locally. (More on why that's a big deal below.)
• Microsoft Execution Containers (MXC) (early preview) — a "policy-driven execution layer" giving agents a "composable sandbox spectrum." In plain terms: a controlled box to run agent actions in, with policy over what they can touch.
• WSL Containers (public preview soon) — a built-in way to create and run Linux containers directly on Windows via a familiar CLI and API, no separate VM.
• Intelligent Terminal (experimental preview) — Windows Terminal with context-aware agent integration baked into the terminal experience.
• Windows Development Skills (GA) — lets agents execute the full lifecycle of building a native Windows app, using WinUI3 "skills" and a winapp CLI.
• Windows AI APIs (expanded, public preview) — on-device Speech Recognition (live audio → text), now reaching GPUs and CPUs, not just NPUs.
• Windows 365 for Agents (GA) — Cloud PCs provisioned for agents to run multi-step workflows, not for humans.

The through-line: an agent on Windows should be able to think (Aion), act in a contained sandbox (MXC), spin up Linux when it needs to (WSL containers), and even build and ship a native app (Dev Skills) — with the OS enforcing the guardrails.

Foundry Agent Service: agents at scale

On the cloud side, the Microsoft Foundry Agent Service is the server-side counterpart, and it's the more production-ready story:

• Hosted Agents — reaching GA within ~30 days of Build. Each session runs in its own sandbox with dedicated compute, memory, and filesystem.
• Framework-agnostic runtime — runs the Microsoft Agent Framework, the GitHub Copilot SDK, LangGraph, and others without a rewrite. Two protocols: an OpenAI-compatible Responses API (stateful) and a schema-free Invocations pass-through.
• Routines (public preview) — scheduled / timer-triggered agent runs.
• Procedural memory (public preview) — agents learn how to do tasks across sessions; Microsoft cites +7–14% absolute success-rate gains at near-baseline cost.
• Toolboxes (public preview) — a managed endpoint for tools with unified auth and lifecycle.
• Foundry IQ (GA) — the knowledge layer over Work IQ, Fabric, Azure SQL, file search, and MCP sources.

Why this hit home for me

Here's the part I keep thinking about. My toy agent has three real ideas in it:

1. A loop that lets a model call tools.
2. A sandbox — in my case, a crude "confirm before you run" prompt.
3. A model that can actually do tool-calling — which, on a small local model, barely works (I had to write recovery code because the 7B kept emitting tool calls as plain text).

Day 2 is Microsoft shipping the industrial version of all three:

• My "confirm before run" → MXC and Foundry's per-session sandboxes (real policy-driven isolation).
• My recovery hack for flaky local tool-calling → Aion 1.0 Plan, a model purpose-built for local agentic tool-calling so you don't need the duct tape.
• My single-process loop → Hosted Agents with durable state, procedural memory, and scheduled routines.

That's the value of building the tiny version first: Day 2's announcements stopped being buzzwords and became "oh, that's the grown-up version of the thing I just struggled with." If you've ever hand-rolled an agent loop, the Foundry Agent Service docs will read very differently.

My honest take

Two reactions. First, the strategy is coherent in a way Microsoft's AI messaging often isn't: Day 1 gave you models, Day 2 gave you somewhere to run them, end to end, on Windows or in Foundry. Second, mind the "preview" labels. A lot of the Windows side — Aion 1.0, MXC, WSL containers, Intelligent Terminal — is early preview or "coming months," shipping first to Windows Insiders. The Foundry Agent Service is the nearest-term real thing (Hosted Agents GA within ~30 days).

The one I'll actually watch: Aion 1.0 Plan. A local, tool-calling-native model is exactly what my tiny agent was missing. If it delivers, the "run a real coding agent fully offline" story I've been chasing across these posts gets a lot more believable — without the recovery hacks.

That's a wrap on Build 2026. Day 1: the models. Day 2: the runtime. Now I just need the Insider preview.