Microsoft Build is a developer conference. That’s technically accurate. It may or may not be where I end up on June 2.

The trip was last-minute — the kind of decision that lands on your calendar ten days out and still doesn’t have final sign-off as I write this. But the questions are already written. I run enterprise architecture, and the architectural decisions Microsoft is making right now about how AI agents are composed, how they communicate across organizational boundaries, and where the intelligence actually sits in a Copilot Studio versus Foundry architecture — those decisions shape what’s buildable on Azure for the next 18 months. I’m already designing against these capabilities. If I make it to Fort Mason, here’s what I’m walking in to find out.

Why This Build Specifically

Build 2026 is a format shift from prior years in ways that matter to me specifically. Microsoft capped in-person attendance at roughly 2,500 — down from 5,000-plus. The event moved to San Francisco for the first time since 2016. They explicitly positioned it for “AI developers, technical leaders, and enterprise developers.” Not consumers. Not general business users. Not the innovation-theater crowd that attends to absorb conference energy and report back to leadership that AI is coming.

The audience narrowing was deliberate. It tells you something about where Microsoft thinks the real adoption problems are — and they’re right. The challenge for enterprise AI in 2026 is not awareness. It’s not tooling access. It’s architectural maturity: how do the pieces — Copilot Studio, Azure AI Foundry, Purview, A2A, Agent 365 — actually assemble into something you can build production systems on top of? That’s an engineering question, not a marketing question. It requires a different kind of event.

Microsoft also announced this as a “no-fluff” event. I’ll find out if that’s true by June 3. What it means structurally: sessions run L-200 through L-400, there are in-person-only 15-minute lightning talks, and the format is organized around hands-on labs and engineering team access rather than announcement-driven product theater. That’s the right structure for what I’m actually trying to learn.

The AI agent architecture story has been building in fragments across Microsoft’s surface area — Copilot Studio, Azure AI Foundry, Purview, Microsoft Entra, the A2A protocol, and now Microsoft Agent 365. Each piece announced separately. Build 2026 is where Microsoft is supposed to show the assembled picture. That’s what I’m there to evaluate.

The Four Questions I’m Bringing

I’ve been writing about the agent architecture gaps from the outside — the NHI identity problem, the Entra Agent ID gaps, the layers below the network proxy that governance tools can’t reach. These are real structural problems that affect every engineering team building on top of Microsoft’s agent platform right now.

Build is the room where Microsoft will either show the answers or demonstrate they haven’t finished building them yet.

Is Microsoft Agent 365 Control, or Is It Visibility?

Microsoft announced Agent 365 as the centralized control plane for managing agents across your environment — a unified surface for agent inventory, permissions, behavior, and activity. That description covers a wide range, and the range matters.

Visibility means I can see what agents exist, what they’ve done, what they’re connected to. That’s table stakes. It’s also the part vendors always ship first because it requires no enforcement architecture.

Control means I can revoke an agent’s permissions, restrict its data access, suspend it without deleting it, and see that enforcement reflected consistently across the Microsoft surface it operates on. That’s what production systems need. That’s also the part that requires solving a much harder distributed permissions problem.

The graduated trust model I wrote about in the agent identity federation gap post assumes control, not just visibility. Read-only access for a new agent. Graduated write access as it proves reliable behavior. Production-facing access only after explicit approval with documented rationale. That ladder only works if the revoking mechanism is real and consistent.

The question I’m bringing to the Agent 365 sessions: when an agent is decommissioned, what happens to the Entra service principal it operated under? Who owns the cleanup? Is that automated, or is it another entry in the identity debt backlog? If Agent 365 creates agents and doesn’t clean up their identity artifacts on decommission, I’ve moved the identity sprawl problem from humans to machines and scaled it by an order of magnitude. That’s not a governance problem to hand off — that’s an architectural constraint I need to design around.

Where Does the Build Surface Actually End and the Governance Surface Begin?

The Copilot Studio versus Azure AI Foundry distinction is real but often framed wrong. Low-code versus pro-code is how vendors describe the split. The question that matters architecturally is different: where does the governance layer sit, and can I apply consistent policy across both surfaces?

The April 2026 Copilot Studio updates introduced granular agent-level permissions through Purview integration — per-agent grants that restrict what data a specific agent can access, independent of the surface that built it. An agent built in Foundry and an agent built in Studio can theoretically both be governed through the same Purview policy plane.

In theory. The question I’m testing at Build: can I build agent A in Copilot Studio, agent B in Azure AI Foundry, give each a different data access boundary, and enforce that declaratively from a single governance surface without wiring up two separate policy systems?

That’s the architecture I want to build: one governance surface, multiple build surfaces. If that’s real, it changes the design space significantly. If it’s not real yet, the architecture looks different — more defensive, more redundant, more manually maintained than I’d want. I need to know which one I’m building toward.

The A2A Protocol Trust Question

Agent-to-Agent communication is the infrastructure story that hasn’t gotten enough attention relative to the agent feature story. A2A is how Microsoft agents talk to each other and how they talk to third-party agents on different platforms.

The cross-organizational scenario is where the architecture gets genuinely hard. Your agent initiates a request to a partner organization’s agent. Both operate under different tenant configurations, different Entra setups, different permission models. The A2A protocol is supposed to handle that handoff. What “handle” actually means at the trust boundary is what I’m there to find out.

Three scenarios I want the session engineers to walk through:

The permission inheritance question. Your agent has read-only access to a data repository. The partner’s agent requests that data as part of a workflow. Does A2A enforce your agent’s access boundary on the outbound request, or does the partner’s agent inherit whatever trust level your agent has established?

The compromise containment question. The partner’s agent is compromised. What is the blast radius on your tenant? Does the A2A trust chain contain the compromise at the boundary, or does it propagate inward?

The trust assertion validity question. A2A uses a specific trust assertion mechanism for cross-tenant calls. What happens when a downstream agent’s trust assertion is stale, expired, or fabricated? Where does the protocol fail, and what does that failure look like to the receiving system?

I’m not looking for the architecture diagram — that’s published. I’m looking for the constraint. The scenario where A2A’s current implementation breaks first. That’s what determines whether I can build cross-organizational agent workflows on this protocol today, or whether I’m designing a stub that I’ll replace in 12 months.

This connects directly to the coverage gap I described in the witness.ai analysis: knowing what a protocol governs isn’t the same as knowing what it doesn’t. Both questions shape the architecture.

The No-Fluff Test

Microsoft announced a no-fluff event. That claim deserves a calibrated prior.

Build announcements historically describe platform capabilities at roughly 80% of their production-ready state. The gap between announcement and general availability is real. The gap between general availability and production-ready-at-scale is larger and less documented.

The sessions that reveal this gap are not the keynote and not the standard breakouts. They’re the L-400 tracks where Microsoft engineers are working through harder questions with an audience sophisticated enough to push back. They’re the post-session Q&A where someone asks “but what about the scenario where…” and the answer is either a clean “here’s how we handle that” or a moment of genuine uncertainty. They’re the 15-minute lightning talks — in-person only — where shorter format and a technical audience tends to surface honest constraints.

The distinction I’m calibrating against: “generally available” versus “works in production at thousands of enterprise tenants.” Microsoft’s historical track record here is mixed. Some platform capabilities are further along than the announcement cycle suggests — the boring infrastructure work (policy enforcement, clean permission revocation, audit trail completeness) sometimes ships ahead of the marketing. Other capabilities take 18 months after GA to close the gap between what the keynote showed and what the platform can actually deliver under real-world load and configuration complexity.

I don’t know where the agent architecture suite falls on that spectrum. Build is where I’ll collect enough signal to calibrate.

---

---

Why the Room Matters

The keynote will be streamed. Most sessions will be recorded. The Book of News will list every announcement. If I’m there only for the content available online, I’m paying $1,099 for ambient conference energy, which is not a useful investment.

The reason to be physically at Fort Mason is the access that doesn’t stream.

Hallway conversations with Microsoft engineers who aren’t scripted. Post-session Q&A where the follow-up question pushes past the prepared answer. The in-person lightning talks where format constraints produce more candid reasoning. The ability to compare notes with other architects making the same platform bets.

Press releases describe capabilities. Engineering sessions describe constraints. The constraints are what shape the next 18 months of architecture decisions. That’s the read I’m going to Fort Mason to get.

Enterprise architects don’t attend developer conferences to learn what’s been built. They attend to understand what the vendor’s engineering teams have actually committed to — and where they’re still figuring it out.

What I Don’t Know Yet

Some things will be further along than the announcements imply. Microsoft’s engineering teams often have more depth than the announcement cycle surfaces, particularly in infrastructure features that don’t make for compelling keynote moments.

Other things won’t survive contact with real-world scale and complexity. The gap between “this works in the demo” and “this works across thousands of tenants with years of identity configuration debt” is real, and it rarely makes it into the conference content.

The follow-up post after June 3 will have the synthesis. What the agent architecture story looks like assembled versus what it looked like in fragments. Where the gaps are closing. Where they’re still open. And whether the no-fluff claim held up past day one.

If you’re at Fort Mason working through the same architecture questions — agent identity, cross-surface policy, A2A trust models — I want to compare notes. The useful knowledge is in the room with people building on these platforms, not just in the sessions.

Find me on X @orestesgarcia or LinkedIn. The follow-up post with what I actually found will be here after June 3.