Microsoft Build 2026 frames Azure, GitHub, Foundry, Fabric, Windows, Security, and Microsoft 365 as one enterprise agent system.
One system instead of seven products
The framing at Microsoft Build 2026 is that Azure, GitHub, Foundry, Fabric, Windows, Security, and Microsoft 365 are no longer separate destinations you stitch together by hand. They are presented as parts of a single enterprise agent system, where an agent built in one place is expected to reach data, identity, and controls that live in the others. For teams, the practical shift is that "which product does this belong to" matters less than "how does an agent move across all of them safely."
This matters because most real enterprise work does not respect product boundaries. A useful agent has to read from a data platform, act through developer tooling, run somewhere, sign in as someone, and stay inside security policy. Treating those as one system is an attempt to remove the integration glue that usually eats the project.
What each layer contributes
It helps to read the lineup by the job each part does for an agent, rather than as a list of brands. The value of the "system" claim is only real if these roles connect without custom plumbing between every pair.
- Foundry — where you build, configure, and operate the agents themselves.
- Azure — the compute and hosting the agents run on.
- Fabric — the data the agents read from and reason over.
- GitHub — the developer workflow that produces and versions agent code.
- Microsoft 365 — the everyday surface where people meet the agents.
- Windows — the endpoint the agents show up on.
- Security — the identity and policy layer that governs every step above.
Why the "system" framing changes how you plan
If you accept the premise, your architecture decisions move up a level. Instead of choosing a hosting service and separately choosing a data connector and separately wiring identity, you decide how an agent should behave across the whole estate, then let each layer implement its part. The tradeoff is coupling: a tightly integrated system reduces glue code but ties you more closely to one vendor's assumptions about how agents, data, and identity fit together.
The upside is that governance stops being an afterthought. When security and identity are treated as shared layers rather than per-app add-ons, an agent that reads from the data platform and acts through the developer tools inherits the same access rules everywhere. That is the hard part of enterprise agents, and it is the part that usually gets skipped in demos.
How to evaluate it for your own stack
Treat the announcement as a claim to test, not a finished result. Pick one workflow that genuinely spans layers — say, an agent that reads from your data platform, proposes a code change, and needs a human to approve it under existing policy — and see how much wiring the system actually removes versus how much you still write yourself.
Ask concrete questions before committing: where does the agent's identity come from, how are its permissions scoped, what is logged when it acts, and how do you roll back a bad action. If those answers are consistent across the layers, the "one system" framing is doing real work. If each layer still answers them differently, you are looking at the same products with a shared slide, and you should plan your integration accordingly.