Copilot is a distribution channel, not an architecture.

I read Microsoft Build the way I read any enterprise keynote: ignore the demo reel, follow the identity arrows. Copilot is a distribution channel, not an architecture. That sentence is the whole conference for anyone who has to sign off on audit logs, not just wire up a LangGraph node. Build 2026 did ship real agent infrastructure, hosted runtimes, an optimizer loop, framework-agnostic hosting. But the enterprise story is who gets to call which tool, under whose tenant, with what policy attached, and whether you can find every agent your company already has.

Official Microsoft Foundry blog image from Build 2026 showing the agent service announcement visual with Build branding. — Microsoft's own Build 2026 agent service still. Source: Microsoft Foundry blog, Build and run agents at scale. The slide looked like a finished platform. The ship calendar underneath it was more cautious.

I followed Build from Seattle on the livestream and the Foundry blog posts that landed the same afternoon, so treat this as an architect's triage, not a partner win. The pattern that mattered to me was not "Microsoft has agents now." It was that Microsoft drew a full stack from GitHub harness to employee inbox, then hung governance on every hop in between.

Build 2026 · Day 1 keynote

Three layers, one platform story

The cleanest map in the coverage is the three-layer frame from the Foundry agent service post: Build (the harness), Deploy (hosted agents in Foundry), Operate (tracing, evaluation, Agent Optimizer). A fourth beat, reach, shows up in the "what's new" post as publishing into Teams and M365 Copilot with identity, permissions, and policy flowing through automatically, GA planned June 2026.

Deck-style diagram of the Microsoft Agent Platform at Build 2026: BUILD with MAF 1.0 and SDK integrations, DEPLOY with Foundry hosted agents across 20 regions, OPERATE with tracing eval and Agent Optimizer, REACH with Teams and M365 Copilot publishing. — Build → Deploy → Operate → Reach, rebuilt from product names in the Foundry Build 2026 posts. Hosted agents are public preview across 20 Azure regions with GA targeted end of June 2026.

That stack is coherent. It is also a commitment device. Once your harness, runtime, observability, and employee-facing surface all share one control plane, "framework-agnostic hosting" stops being a kindness and starts being a funnel. You can bring LangGraph or the Claude Agent SDK, but the registry, policy, and audit trail live in Foundry either way.

Official Microsoft Foundry blog slide from Build 2026 showing the agent platform stack and product integrations. — Another official Foundry slide from Build week. Source: What's new in Microsoft Foundry, Build edition.

Who owns the registry?

The line that stuck with me from the Foundry coverage is almost boring on purpose: "Production agents shouldn't force a framework choice up front. Microsoft Foundry treats the agent harness as a flex point, not a lock-in." Fair. But flex at the harness layer only helps if someone upstream owns the inventory of what is running, who published it, and which tools each agent may call. That inventory is the registry problem, and Build answered it by making Foundry the default place agents land before they reach Copilot.

Figure 1 · Identity flow-through

Publish path: harness → Foundry → employee surface

The interesting arrow is identity flow-through. Microsoft is betting that the hard part of enterprise agents is not picking LangGraph versus MAF. It is publishing an agent into Teams without rebuilding authz from scratch every time a line-of-business team ships something new.

If you are comparing harnesses, the MAF and AutoGen migration story is worth a look for where Microsoft wants greenfield builds to land. My read is narrower: treat Copilot as the inbox, Foundry as the control plane, and every agent as a governed service before it is a demo.

Operate layer

Optimizer loops are governance, not a feature slide

The Agent Optimizer announcement is easy to dismiss as another "AI fixes AI" slide. In an enterprise context it is closer to a change-management workflow: production failures become ranked, reviewable proposals instead of silent prompt tweaks in someone's private fork. That is the same instinct as a proper eval gate, just sold as a managed loop.

CodeAct and Hyperlight sandboxing (preview) push in the same direction from the execution side: fewer model turns, approvals at execute_code granularity. For teams already nervous about agents running tools, that granularity is the part to watch, not the benchmark chart.

Figure 2 · Registry ownership

Without a registry, "framework-agnostic" just means invisible sprawl

Framework-agnostic hosting helps day one. A registry you control helps year two, when legal asks for a list of every agent that can touch customer data.

On the tool boundary specifically, the production patterns in the MCP production server guide are an interesting read for how authz and audit should look once agents leave the demo laptop. Build is selling the Azure-shaped version of the same problem.

MondayWhat I would do with this announcement

Pilot checklist

Separate the June 2026 GA dates from today's preview status before anyone puts "Copilot agent" on a roadmap slide. Run one harness (MAF or your existing LangGraph service) through Foundry hosted agents in a single region, with Entra groups mapped explicitly, and require a registry entry before any Teams publish. Treat Agent Optimizer output as a human-reviewed change queue, not auto-deploy. Write down who owns the registry on your side, because Microsoft's default answer is Foundry.

Build 2026 did not solve enterprise agents. It did name the right control points: identity flow-through, hosted runtime, optimizer loop, inbox distribution. For a season-level read across I/O, Cloud Next, and Interrupt, the 2026 conference roundup is worth a look once those pieces are live.

Copilot is where employees meet the agent. Foundry is where you prove you knew what it would do before it got there. Build spent its agent keynotes connecting those two sentences.

Comments (3)

Join the discussion

Mateo LeeUnproven5/26/2026

Copilot is a distribution channel, not an architecture, is the line that cuts through the keynote. For enterprise the interesting questions are identity, audit, and who owns the agent registry, and Build mostly answered those by wrapping things in Copilot and Foundry. The capability was never the question. The governance and ownership story is.

Grace KimUnproven5/27/2026

Agreed completely. The registry ownership question is the one my security team asked within five minutes of the announcement and the keynote did not really answer. Who can publish an agent, who approves it, and what identity does it act as. Until that is crisp, the Copilot distribution is a liability surface, not just a channel.

Pavel HernandezAwakened5/27/2026

Solid governance lens. I would add that the Foundry and Agent Framework convergence is the part developers should track, because that is where the actual building happens once the Copilot demo wears off. The governance story sells the deal, but the framework story is what your engineers live in afterward.