Microsoft Build 2025: agents everywhere, governance nowhere
Build was the agents conference Microsoft has been preparing for. The agents pitch lands. The governance story underneath it is exactly as unfinished as it was a year ago, and the contradiction is starting to show.
Microsoft Build wrapped this week and the framing was unmistakable: this was the agents conference Microsoft has been preparing for. Copilot Studio added enough capability to be a real agent-development platform. Windows AI Foundry shipped as the on-device model runtime story. NLWeb landed as an open-standard pitch for making web content agent-readable. Discoverable agents in Teams turn the chat surface into an agent catalog. The agents pitch lands, in the form Microsoft has been signaling for months.
The thing the keynote didn't address (and didn't have a credible story for in the breakout sessions either) is the governance layer underneath all of this. The contradiction between "agents everywhere" and "we don't have an answer for what they're allowed to do" is exactly as unfinished as it was a year ago, and at agent-everywhere scale the gap is going to start mattering quickly.
What actually shipped
The substance of the announcements, before the marketing layer:
Copilot Studio, meaningful capability additions for building, deploying, and managing custom Copilot agents. Better handoff between agents. Improved evaluation tooling. Tighter integration with Microsoft Graph for accessing organization data. Support for MCP as a connection type for external tools. The most substantive product update of the conference; the thing enterprise customers will actually use.
Windows AI Foundry. Microsoft's local-model runtime for Windows. Includes Phi-class small models, support for ONNX-format third-party models, and a system-level API for app developers to call into the runtime. Aimed squarely at the Apple-Intelligence story but for the Windows installed base. Whether developers actually adopt it is the next year's question.
NLWeb, open-standard proposal for marking up web content so AI agents can read and act on it cleanly. Conceptually similar to schema.org but aimed at the agent use case rather than search. Launched as a Microsoft-led initiative with a few partners on board. Standards adoption is slow; this might land or it might not.
Discoverable Teams agents, a registry/catalog of agents that surface inside Teams, with policy controls for which agents can be deployed in which channels. The shape of "internal agent marketplace" that enterprise IT has been asking for. Useful when the agents themselves are useful; the coming year will tell.
Azure AI Foundry updates, model-deployment improvements, fine-tuning workflow refinements, evaluation tooling. The platform-tier announcements that don't lead with the keynote but do most of the actual work.
That's a real product update. Microsoft is running the agents play with focus and the engineering's behind the marketing. That part is genuine.
The governance gap
Here's the thing that didn't get a real answer in any of the announcements:
When an enterprise deploys a hundred agents across Teams, Copilot, custom-built Studio agents, and external MCP-connected agents, what governs what those agents can do? Who approves their deployment? Who audits their actions? When an agent takes an action that turns out to be wrong, who's responsible? When the agent's permissions need to change because the user's permissions changed, what propagates the change? When an agent should be revoked because the use case it was built for changed, what handles the deprovisioning?
These are the questions IT departments have asked about every new technology category for thirty years. The agent category currently doesn't have credible answers to any of them.
Build had session content on agent management, but the management story is mostly about the deployment side, how to deploy, how to update, how to version. The harder governance questions (what an agent is allowed to do, who decides, what gets audited, how revocation works) are mostly described as "configurable per agent" with the implication that the configuration is the customer's problem.
That's not adequate at scale. The shape of "deploy a hundred agents and let each customer figure out the policy" is the same shape that led to every "shadow IT" problem of the last twenty years, dressed up in 2025 vocabulary.
Why this matters specifically for Microsoft
The governance gap is industry-wide. Anthropic, Google, OpenAI, AWS all have versions of it. What makes Microsoft's specific gap more acute is that Microsoft's agent pitch lands in the most-regulated environments. Enterprises running Microsoft 365 typically have compliance regimes (SOX, HIPAA, GDPR, sector-specific frameworks) that the SaaS-tier consumer-facing AI products don't have to worry about. Those compliance regimes have specific requirements for audit trails, access controls, change management, and human-in-the-loop approval that the current Microsoft agent stack doesn't natively support.
The current pattern is: deploy the agent, add custom logging, write your own audit reports, layer your own access controls on top. That's workable for shops with the resources to build the missing layer themselves. It's not adequate as a default for the small-and-medium-enterprise tier that Microsoft's GTM motion is aimed at.
The contradiction shows up in what the keynote presenters didn't say. The phrase "agents are coming to every workflow" appeared. The phrase "and here's how you'll govern them" did not. That gap is going to get more visible as the agent footprint grows.
What I'd watch for over the next two quarters
A few specific things that would tell you whether Microsoft is taking the governance side seriously:
A native audit-trail surface for agent actions that's queryable in the same way other Microsoft 365 audit trails are. Right now the agent-action logs exist but live in inconsistent places.
A policy framework that lets IT define "what agents are allowed to do this kind of action" without writing Custom Connector logic per agent. The current pattern is bespoke; the right pattern is policy-as-data.
An agent-revocation story that propagates, when an agent is deprovisioned in the catalog, what happens to existing agent instances, in-flight conversations, persisted memory the agent has accumulated? Right now this is a mess.
Better integration between the treat-the-AI-like-an-employee discipline and the actual platform, agent identity that flows through the org structure, performance evaluation surfaces, retirement workflows. The metaphor exists in the marketing; the platform support for it doesn't.
A coherent answer for what gets audited at the agent boundary when the agent calls third-party MCP servers. The current state is "the customer's problem"; the right state is a defined boundary with reportable behavior.
If those land in the next two quarters, the agents-everywhere pitch becomes credible at the scale Microsoft is selling it at. If they don't, the gap between "we shipped a hundred agents" and "we know what they're doing" widens enough to become a real liability.
The bigger frame
Build was the agents conference because Microsoft is playing a specific position. They have the distribution (Microsoft 365 in essentially every enterprise), they have the relationships (every IT department), they have the platform (Azure, Copilot, Teams, the Microsoft Graph). What they don't yet have is the operational discipline that would let "agents everywhere" be a defensible architectural commitment rather than a marketing slogan.
The agents pitch lands. The governance layer that would make it durable hasn't shipped yet. The next quarter or two will tell whether the gap closes faster than the agent footprint grows, or whether the contradiction becomes the story.