The headline from Microsoft Build 2026 was Satya Nadella’s line that “agents are the new operating system for work.” It travels because it compresses a real shift into a sentence that does not require parsing. What sits underneath the line is the more interesting story, and it is mostly an architectural one. Microsoft did not announce that Windows will host a few new AI features. It announced that the operating system will grow primitives for agents the way it once grew primitives for processes and files.
Read the announcement list at the level of where each piece sits in the stack and the shape of the bet becomes clear.
The OS layer
The Windows Agent Runtime Service is the part that matters most for how agent behavior is shaped. Today, on a normal Windows or macOS install, an agent is a long-running script with whatever scope the credentials it was handed allow. The credentials sit in environment variables or a keychain entry. The scope is whatever the API key happens to permit. There is no operating system concept of “this is an agent, here is its sandbox, here is the policy it is allowed to act under.” The runtime in this sense lives entirely above the OS, in whichever framework the developer chose, and the framework’s enforcement is only as strong as the developer’s care.
Microsoft Execution Containers (MXC) are the structural response to that. They are sandboxed environments at the OS level, with a policy file that describes which actions the contained agent is allowed to perform, which files and network endpoints it may reach, and which categories of operation require an explicit confirmation outside the agent’s own decision. The policy is enforced by the kernel, not by the agent’s framework. The promise is that an agent that tries to write outside its scope is stopped the same way a process trying to access another process’s memory is stopped today.
That is a meaningful claim. We have written before that authorization belongs in the runtime, not in the prompt. The OS layer is one notch deeper than the runtime layer we had in mind. If MXC ships as described, the conversation about agent constraints changes shape. Instead of arguing about prompt discipline, the question becomes: what policy did the operator describe, and what did the OS actually enforce. The audit becomes a thing the kernel knows about, not just a log the agent’s framework chose to write.
Whether the implementation lives up to the description is a separate question. Sandboxes are hard. The history of OS-level isolation is full of side channels and policy holes. The interesting thing about the Build announcement is not that Microsoft has solved that problem. It is that they have picked the OS as the layer where the solution will live.
The platform layer
Microsoft Foundry, Azure Agent Service, and the new in-house MAI models sit one layer up. Foundry is the build-and-govern surface. Azure Agent Service is the runtime that holds state and load-balances across thousands of concurrent agents. MAI ends the implicit story that Microsoft was a distribution channel for OpenAI’s frontier work.
The most consequential piece in that group is Azure Agent Service. The pitch in the keynote was scale. Deploy thousands of agents per second, with state persistence and auto-scale, and pay by the second of agent activity. That is the part that converts agents from “long-running scripts you maintain yourself” to “a class of workload your infrastructure platform knows how to schedule.” It is the difference between hosting a database on a VM and using a managed database service. The economic shape of running a hundred agents continuously is different when the platform handles cold starts, state checkpointing, and identity rotation as a primitive instead of as something you wrote yourself.
The MAI models announcement matters for a different reason. Microsoft is signaling that the Foundry stack will not depend on a single external model provider. For an enterprise buyer who has been holding back because the dependency chain was unclear, that signal closes a question. The choice of model becomes a configuration option inside Foundry rather than a strategic vendor decision made above the stack.
The product layer
Microsoft Scout is the part the keynote spent the most time on, and the part most likely to be misread. Scout is described as the first “Autopilot,” with its own identity and the ability to act continuously across the desktop. The identity claim is the substantive one. From inside the role, an agent without an identity of its own is borrowing the user’s, which means every action is auditable only as “the user did this.” An agent with its own identity is auditable as itself, which is the foundation that makes credential scoping and policy enforcement actually work. Most of what we have written about runtime constraints assumes the agent has a distinct identity that the audit trail can reference. Microsoft shipping that as a default is a quiet but important step.
Office 365 Copilot Agent Mode is the version of this story aimed at the knowledge worker. The rollout window is late June 2026. The model is that a Copilot subscriber can create specialized agents that act across Word, Excel, Outlook, and the rest of the suite, each with a defined scope. The interesting question is not whether the feature works. It is whether the enterprise scopes are configured carefully enough that a Word agent does not casually send mail in a user’s name, or that an Excel agent does not pull from a finance dataset that the user is allowed to read but the agent is not. That is the same scoping question that has been showing up in the breach reports, in a different room.
Project Solara, the adaptive desktop, is the surface piece. Useful for the demo, less load-bearing than the OS and platform changes underneath it.
What is not solved
Two things are missing from the announcement, and both are the parts the next year of incidents will be written about.
The first is liability. An always-on autonomous agent with its own identity, acting under a corporate Microsoft account, will eventually make a costly mistake. The question of whether the responsibility lands with the operator, the enterprise, Microsoft, or the agent’s own identity is not answered by a policy file. It is answered by contracts and case law that have not been written yet. The MXC announcement included no language on liability scope. The Office 365 Agent Mode rollout includes no language on it either. Enterprise buyers in regulated industries will notice that absence within the first quarter.
The second is the propagation of identity across services. Microsoft can ship an agent identity that Windows and Azure understand. The agent will still need to act against systems Microsoft does not own. The token that authorizes a Scout agent to read a Salesforce object or push to a non-Azure git remote is still a credential issued by another vendor, scoped by that vendor’s model, and audited by that vendor’s logging stack. The OS-enforced policy stops at the boundary of the OS. Cross-service identity is the unsolved part, and the Build announcement was quiet about it.
Where this lands
The line that traveled is “agents are the new operating system for work.” Read as marketing it is a slogan. Read as architecture it is a claim about where the constraints should live. The claim is that the OS is the right layer. We think the claim is correct. The interesting work over the next two years is whether the implementation, the policy language, and the cross-vendor identity story catch up to the framing. The keynote was the easy part.