Microsoft Build 2026 made one thing pretty clear: the company has decided that the operating system itself is the right place to anchor the next wave of AI agent development. Not the cloud. Not a separate app. Windows. And whether you find that exciting or slightly alarming probably depends on how much time you spend thinking about platform lock-in versus developer convenience.

The centrepiece announcement was the Windows Copilot Runtime — a set of on-device AI APIs that give developers access to locally running models without having to manage inference infrastructure themselves. This is the thing that makes Copilot+ PCs more than just laptops with a Recall feature that keeps getting switched off for privacy reasons. The Runtime exposes text generation, image understanding, embeddings, and speech transcription as native Windows APIs, backed by small models (primarily from Microsoft’s own Phi family) that run on the NPU.

Why Running on the NPU Matters

Here’s the thing about on-device AI: it’s been theoretically available for a while, but getting it to work reliably across different hardware configurations has been a pain. The Copilot Runtime abstracts that away. You call the API, Windows figures out whether to use the NPU, the GPU, or the CPU depending on what’s available and what the current load looks like. For developers building agent workflows, this means you can have a local reasoning step — summarisation, intent classification, entity extraction — that doesn’t require a network round-trip and doesn’t cost you per-token.

That’s genuinely useful for a class of agents that need to operate with low latency or in environments where connectivity isn’t reliable. Think field service agents, enterprise desktop automation, or anything processing sensitive data that can’t leave the device.

NLWeb: Natural Language for the Web’s Data Layer

Alongside the Runtime, Microsoft announced NLWeb — an open protocol that lets websites and services expose their content to AI agents using natural language queries instead of structured APIs. The framing is something like “RSS for the AI era,” and that’s a fair analogy. A service that implements NLWeb can answer questions like “what products do you have in the £50–£100 range that are compatible with X” without the agent having to scrape HTML or reverse-engineer an undocumented API.

For workflow builders, this matters because a lot of agent integration work today is dominated by data-fetching problems. You want your agent to pull information from a SaaS tool, a retailer, or a content platform, and the options are usually a proper API (if one exists), a brittle web scraping setup, or asking a human to copy and paste. NLWeb doesn’t solve this overnight — adoption needs to happen on the provider side — but if it gets traction, it meaningfully lowers the cost of connecting agents to web-based services.

Microsoft has open-sourced the NLWeb spec and a reference implementation. Several large websites have already announced support, and given Microsoft’s distribution leverage, it’s worth keeping an eye on.

The Agent Framework in Windows

The deeper structural change is what Microsoft is calling the Windows Agent Framework — a set of system-level capabilities that let AI agents take actions on the desktop in a more structured way than current approaches. Screen reading, UI automation, application control, and file system access are all surfaced through a consistent interface that’s designed to be observable and auditable.

This is a direct response to one of the real problems with computer-use agents today: they’re often opaque, hard to debug, and can behave unpredictably when the UI they’re operating changes. The Windows framework bakes in an action log, permission controls, and a mechanism for agents to describe what they’re about to do before doing it — which sounds obvious but is missing from most current implementations.

From an enterprise workflow perspective, this is significant. IT administrators get visibility and control over what agents are doing on managed devices. Audit trails matter for compliance. The permission model means agents can be scoped to specific applications rather than given run of the entire desktop.

What This Changes for Developers

If you’re building agentic workflows that need to operate on Windows endpoints — which covers a lot of enterprise automation — the Copilot Runtime and Agent Framework give you a more reliable foundation than cobbling together a solution with accessibility APIs and screen capture. The trade-off is Microsoft’s platform dependency, which is a real consideration for organisations that care about cross-platform portability.

For AI workflow builders using tools like n8n, Zapier, or custom LangChain deployments, the practical near-term impact is probably limited — these tools run server-side rather than on-device. Where things get interesting is for builders of desktop agents: tools like those in the computer-use category that operate on what’s actually displayed on a user’s screen. The Windows framework gives those agents a much cleaner surface to work with.

Microsoft has form for making big platform announcements that take a few years to fully materialise. But the direction of travel is clear: they’re trying to make Windows the most capable platform for running AI agents, and they’re doing it by baking the infrastructure into the OS rather than shipping it as a separate product. Whether that bet pays off depends a lot on whether developers show up — and on whether NLWeb gets the adoption it needs to make the data-access problem actually solvable.