At a glance: Microsoft Build 2026. June 2–3, 2026. Fort Mason Center, San Francisco. Keynote: Satya Nadella. Central thesis: AI agents are infrastructure, not features. Four announcements with direct builder implications: Project Polaris, Copilot Workspace GA, Windows Agent Framework, Azure Agent Mesh. Part of our Builder’s Log.

Microsoft’s Build 2026 keynote had one argument: the AI assistant era is over. In its place is an agent era, where AI doesn’t respond to prompts — it owns workflows. Satya Nadella put it plainly: in 2026, AI is no longer about responding to a prompt. It is about running the work.

For builders, that framing isn’t positioning. It describes what ships in the next 90 days.

Project Polaris: The OpenAI Dependency Ends in August

The most consequential announcement for teams using GitHub Copilot is Project Polaris — Microsoft’s first in-house AI coding model, built specifically to replace GPT-4 Turbo as the default reasoning engine inside Copilot.

Migration timeline: Polaris becomes the Copilot default for all subscribers in August 2026. Automatic migration, no opt-in required. Teams that need stability can activate a three-month fallback period to stay on GPT-4, but that window has a hard end date — not an indefinite grace period.

Architecture

Polaris is a mixture-of-experts (MoE) architecture with specialized sub-modules tuned for different programming languages and frameworks. At inference time, it applies chain-of-thought and tree-of-thought reasoning to handle multi-step, multi-file tasks that flat completion models struggle with.

It runs on Microsoft’s custom Maia AI accelerators inside Azure. The shift to Maia-hosted inference is the technical prerequisite for reducing per-inference cost and latency below what’s achievable when routing through OpenAI’s external endpoints — which is what GitHub Copilot has done until now.

Reported Performance

Microsoft reports Polaris outperforms GPT-4 Turbo on HumanEval and MBPP, with the largest gains in Rust and Haskell — languages where GPT-4 historically underperformed. Pro tier subscribers get multi-file context up to 100,000 lines and autonomous test generation as new defaults.

Note: These are Microsoft’s self-reported benchmarks announced at a product keynote. Independent evaluation will follow. Builders should test Polaris against their specific language and use case before relying on the headline numbers.

What This Means for Builders

If you’re building on the GitHub Copilot SDK or Copilot extensions: your downstream model changes in August. You don’t change a line of API code — but model behavior, output formatting conventions, and latency characteristics will shift. Start testing against Polaris behavior now. The three-month fallback option is your hedge; decide now whether to activate it rather than after forced migration surprises you.

If you’re an Azure ISV with Copilot integrations: the fully Microsoft-controlled model stack removes data-residency complexity and third-party routing risk. For regulated industries, this is a net positive — but review your existing terms of service, because the model now has a different data lineage than GPT-4.

Pricing for direct API access to Polaris has not been disclosed. At GA in August, pricing is expected through Azure AI Foundry alongside the existing MAI model family.

Copilot Workspace Goes GA

GitHub Copilot Workspace exited beta and reached general availability at Build 2026. For builders who have been watching this product, the GA milestone matters because two features that were research previews are now production commitments:

  • Autopilot mode: Copilot Workspace reasons across a full repository, proposes multi-file edits, runs tests, interprets test results, and iterates — autonomously, within a scoped task defined by a GitHub issue or feature description.
  • Fleet mode: Run autopilot across multiple open issues simultaneously. Useful for dependency upgrades, style migrations, or license compliance sweeps across large repos.

The agentic programming model Copilot Workspace represents — describe the goal, get a pull request with tests and documentation — is now a supported production feature, not a beta experiment.

For teams evaluating GitHub Copilot vs. Claude Code or Cursor: Copilot Workspace GA closes a meaningful gap in agentic task completion. The question is no longer whether Copilot can do agentic tasks; it’s whether Workspace’s GitHub-native integration outweighs Claude Code’s model flexibility for your workflow.

Windows Agent Framework: Agents as First-Class Windows Citizens

Microsoft open-sourced the Windows Agent Framework (WAF) under MIT at Build 2026. WAF positions agents as first-class constructs in the Windows runtime — not overlays or automations, but system-level entities with direct access to Windows subsystems.

What WAF Enables

WAF gives agents declarative APIs for interacting with:

  • File manager and file system
  • Task scheduler
  • Hardware sensors
  • System notifications

The model is write-once: an agent built to WAF’s interfaces runs against Windows 11 (with NPU on Copilot+ PCs) and against Windows Server for enterprise deployments.

Connection to Windows AI Foundry

WAF is the agent execution layer. Windows AI Foundry is the on-device inference layer — models running on the PC’s NPU, GPU, or CPU rather than routing to cloud endpoints. Together they define a new developer target: a fully on-device agent runtime that doesn’t require internet connectivity or cloud API calls.

For builders working in regulated industries, air-gapped environments, or consumer apps that can’t assume persistent connectivity, this is a new tier of deployment option that didn’t exist at a platform level before today.

Azure Agent Mesh: Multi-Agent Cloud Infrastructure

Azure Agent Mesh was announced with a Q4 2026 GA target. Mesh is Microsoft’s infrastructure layer for coordinating multiple agents running across Azure services — scheduling, routing, observability, and governance for agent fleets.

The announcement is forward-looking. The six-month window to Q4 2026 GA gives builders time to run preview workloads before committing Mesh as production infrastructure. What’s available now is preview access for Azure customers.

Mesh integrates with Microsoft Agent Framework 1.0, which reached GA earlier this year and provides the A2A (Agent-to-Agent) protocol for .NET and Python. If you’re already building on Agent Framework 1.0, Mesh is the cloud execution layer that scales your agent orchestration without manual infrastructure management.

Microsoft Agent Framework 1.0 Status

This wasn’t a new announcement at Build — Agent Framework 1.0 reached GA in April 2026 — but it was prominently featured across sessions as the foundation for everything else. Key reminders for builders:

  • Language support: .NET and Python
  • Protocol: A2A (Agent-to-Agent) — interoperable with Google’s A2A specification
  • Patterns supported: Sequential, concurrent, and hierarchical agent execution
  • Tool integration: MCP tools natively supported as agent tool providers

Agent Framework 1.0 is the .NET/Python SDK layer. WAF is the Windows runtime layer. Azure Agent Mesh is the cloud orchestration layer. These three are designed to compose: an agent written in Agent Framework 1.0 can target WAF for on-device execution or Mesh for cloud-scale fleet deployment.

MAI Models: Commercial Access Expands

Microsoft made MAI-Voice-1 and MAI-Image-2 broadly available to developers for commercial use at Build. MAI-Transcribe-1 — Microsoft’s speech-to-text model — was announced as a new addition to the family.

We covered the MAI model family in detail in our MAI Transcribe, Voice, and Image multimodal family review. The Build update adds commercial access to previously research-only models. Pricing disclosure for the MAI family on Azure AI Foundry is expected alongside Polaris pricing at August GA.

The Competitive Picture

Microsoft’s Build 2026 narrative was built against a specific competitive backdrop: Claude Code overtook GitHub Copilot in developer adoption among agentic coding workflows over the past six months. Project Polaris is the primary response — a homegrown model Microsoft can iterate without OpenAI’s roadmap constraints.

The competitive angle is relevant for builders evaluating tooling:

Tool Model control Agentic coding Context window IDE integration
GitHub Copilot (post-Polaris) Full (Microsoft) Copilot Workspace GA 100K lines (Pro) VS Code, JetBrains
Claude Code External (Anthropic) Full agent loop Project context Terminal + extensions
Cursor External (multiple) Composer + agent mode Repo-wide Cursor IDE native

No single tool wins on all dimensions. The Polaris migration in August is the variable that changes the Copilot column most significantly — moving from a shared OpenAI dependency to a Microsoft-controlled inference stack.

Action Items for Builders

1. Evaluate Polaris before August — don’t wait for forced migration. Microsoft is offering preview access. Run your highest-priority Copilot use cases against Polaris now. The three-month fallback window is a safety valve, not a reason to delay evaluation. If you build Copilot extensions or integrations, your testing window is this month and next.

2. Set a Copilot Workspace trial scope. Autopilot and fleet modes are GA. Pick one repetitive, scoped engineering task — dependency version bumps, adding type annotations to a module, migrating a component to a new API — and run it through Workspace. The GA designation means you can reference this in internal tooling proposals without the “beta” asterisk.

3. Watch WAF’s NPU targeting if you build on Windows. WAF and Windows AI Foundry together define an on-device agent target. The MIT license means you can fork and build. If your user base includes regulated industries or enterprise deployments with air-gap requirements, on-device agent execution is worth a prototype sprint.