Build 2026 for Infra Folks: Agents Need Operators Too

Every year Build has a headline act, and every year it's the developers. They get the keynote demos, the standing ovations, and the t-shirts. This year they got agents that write code, file pull requests, book travel, and reason their way through multi-step tasks while the crowd cheers.

And every year, somewhere in the back of the room, the infrastructure team quietly does the math on what it just inherited: a fresh pile of ops homework wearing a developer label.

Because here's the thing nobody puts on a keynote slide: an agent is just a workload. A weird, chatty, occasionally over-eager workload that needs compute, isolation, identity, networking, observability, a cost ceiling, and someone to call when it does something it shouldn't at 2 a.m. Developers build the agent. You have to operate it. And operating it is an infrastructure job, even when the announcement never says the word "infrastructure" out loud.

Compare this to last year. Build 2025 was a season of quiet infrastructure upgrades that paid real dividends: VM Boost, smarter host maintenance, Compute Fleet, storage and networking improvements, confidential GPUs. Genuinely useful, but unglamorous plumbing. The kind of thing you appreciate on the invoice and in the incident count.

Build 2026 is different, and here's the twist: most of this year's infrastructure didn't get announced as infrastructure. There was no marquee "new VM family" or "new storage tier" moment carrying the show. The plumbing showed up in disguise, dressed as agent features: sandboxes, control planes, identity, tracing, resiliency goals, a leaner base OS. Strip off the branding and you find a new workload category that decided to call itself AI. Microsoft pointed all of it at one question: how do you operate the agentic stack with guardrails and cost discipline? The answer is a stack of new isolation primitives, governance control planes, resiliency tooling, database services, and Foundry agent-platform capabilities, some GA, some preview, and some announced-but-not-yet-GA. Almost none of it is "set it and forget it," and all of it eventually lands on your pager. The infrastructure you are looking at is not optional.

So let's do what we do every year: skip the hype, read the availability labels carefully, and figure out what's worth your time before summer vacation. Eight things. No t-shirts. Let's go.

1. Cobalt 200 and the New Economics of Always-On Agents

What Microsoft announced: Azure Cobalt 200, the next generation of Microsoft's in-house Arm-based VMs, purpose-built for scale-out, cloud-native, Linux-based agentic AI workloads. Microsoft is claiming up to 50% better CPU performance versus Cobalt 100, along with improved storage and networking performance. The pitch is squarely aimed at the kind of continuous, horizontally-scaled reasoning and orchestration work that agents generate.

Why infra/platform/SRE teams should care:

• Always-on agents are a different cost shape than batch jobs. They idle, they spike, they run continuously. Per-core efficiency matters more than it used to.
• Arm-based VMs can meaningfully change your cost-per-task, if your workload and dependencies are Arm-compatible. That "if" is the whole game.
• Better network and storage performance helps the chatty, I/O-heavy coordination layers that sit between agents and their tools.

Business value in plain English: If you're going to run agents that never really go to sleep, the chip underneath them stops being a footnote and starts being a line item your CFO can find without a flashlight. A more efficient core is the difference between "we piloted agents and the bill scared everyone" and "we ran the math and it pencils out." This is the unglamorous economics layer that decides whether agentic projects survive their first budget review.

Try this first: Request early-access/preview access in a listed preview region, then take one Arm-compatible workload you already trust and run it on Cobalt 200 for a full 24 hours next to your current generation. Measure cost, latency, and throughput on both. Don't benchmark a toy. Benchmark something with a real diurnal curve so the always-on economics show up honestly.

Availability status: Early access preview / preview, in listed preview regions. Treat performance numbers as Microsoft's claims until you've measured your own workload. Not production-ready, and not every region or subscription has access.

2. Container Apps Sandboxes and the Case for Isolating Agent Execution

What Microsoft announced: Azure Container Apps Sandboxes: fast, isolated, ephemeral, stateful sandbox environments delivered as a Container Apps resource. They support suspend/resume, snapshots, persistent volumes, lifecycle control, configurable egress policies, and OCI image support. In plain terms: a place to run untrusted or agent-generated code where you control what it can touch and where it can talk.

Why infra/platform/SRE teams should care:

• Agents execute code. Sometimes code they wrote themselves thirty seconds ago (confidence high, test coverage unknown). You do not want that running with ambient access to your network and secrets.
• Ephemeral-but-stateful is the sweet spot for agent sessions: spin up, do work, snapshot, suspend, resume, throw away, without the overhead of standing up a full VM each time.
• Egress policies let you constrain the data-exfiltration paths, which is the risk your security team will ask about first.

Business value in plain English: This is how you say "yes" to a vendor agent or a code-writing agent without betting the company on it behaving. Instead of trusting the agent, you contain it. The business gets to adopt agentic tooling; you get to sleep, because the blast radius is a disposable box you defined the walls of. Nobody is going to file this under "infrastructure announcement." It is one anyway.

Try this first: Stand up two agents in two separate sandboxes and try to make one read the other's filesystem or reach a network endpoint you didn't allow. If isolation holds, you've got a repeatable pattern for running anything you don't fully trust. If it doesn't, you've learned that in a lab instead of in a breach report.

Availability status: Preview. APIs may change, and Microsoft notes preview sandboxes may need to be recreated as the service evolves. Great for building patterns and proofs now; not something to anchor a production tenant-isolation story on yet.

3. Infrastructure Resiliency Manager and Goal-Based Reliability

What Microsoft announced: Azure Infrastructure Resiliency Manager (IRM), a self-serve Azure experience for defining resiliency goals, grouping application resources, assessing zonal posture, getting recommendations, running outage drills, and building recovery plans. It's an attempt to move reliability from tribal knowledge and runbooks toward a structured, goal-based posture you can actually inspect.

Why infra/platform/SRE teams should care:

• Agent workloads are unpredictable and bursty. Chasing reliability by hand across a growing fleet doesn't scale, and it burns out your best people.
• Zonal posture assessment and recommendations turn "we think we're resilient" into "here's specifically where we're not."
• Outage drills and recovery plans give you something to rehearse before the real thing, instead of improvising during it.

Business value in plain English: Resilience usually lives in the heads of three senior engineers and one very long wiki page nobody trusts. IRM tries to make it a property of your environment that you can set goals against, drill, and prove. For leadership, that's the difference between "we hope we'd recover" and "we tested recovery last Tuesday, and here's the report." On-call gets a rehearsed plan instead of a 3 a.m. improvisation, and audit gets evidence instead of assurances.

Try this first: Pick one real application, group its resources in IRM, and let it assess your zonal posture. Then run a single outage drill against a non-production copy and read the recommendations. You'll likely find one uncomfortable gap you didn't know about, which is exactly the point.

Availability status: Preview. Useful for getting ahead of the resilience conversation and shaping your recovery plans now; validate its recommendations against your own architecture rather than taking them as gospel.

4. AKS for AI Workloads: Watch the Status Per Feature, Because It's All Over the Map

What Microsoft announced: A bundle of Build 2026 updates to Azure Kubernetes Service aimed at AI and agent workloads. The notable pieces: managed system node pools in AKS Automatic, Azure Container Linux as a container-optimized OS, AKS on bare metal, Fleet Manager for Arc-enabled clusters, Anyscale on Azure for Ray-based workloads, and model-serving patterns referenced as AI Runway / KAITO.

This is the section where I have to slow you down, because "AKS got AI updates" is true and also nearly useless as a planning statement. The status differs feature by feature, and collapsing them into one label is how teams end up surprised.

Why infra/platform/SRE teams should care:

• Running agents at scale means GPU pooling, flexible node sizing, and orchestration beyond vanilla Kubernetes. These updates target exactly that.
• Bare-metal AKS and Ray/Anyscale matter for the heavy model-serving end of the spectrum, where you want hardware access and distributed compute.
• Fleet Manager reaching Arc-enabled clusters is a real operational win if you're running Kubernetes across more than just Azure.

Business value in plain English: If Kubernetes is already your platform, you don't want a separate, bespoke stack just because the workload says "AI" on it. These updates let your existing AKS muscle memory extend to agent and model-serving workloads: less retraining, fewer one-off platforms, more reuse of the operational practices you already trust.

Try this first: Take the one feature that's actually GA and relevant to you (managed system node pools, Azure Container Linux, or Fleet Manager for Arc) and pilot it on a non-critical cluster. Then, if you have preview access and it's appropriate, deploy a small Ray/Anyscale or KAITO-style model-serving job in a non-production cluster and watch pod scaling and GPU utilization. Validate the orchestration story with your own eyes before you put it on a roadmap slide.

Availability status (per feature, do not generalize):

• Managed system node pools (AKS Automatic): GA
• Azure Container Linux: GA
• Fleet Manager for Arc-enabled clusters: GA
• AKS on bare metal: Public preview
• Anyscale on Azure: Public preview
• KAITO / AI toolchain operator model-serving add-on: Preview.
• AI Runway setup guidance: Service availability status not clearly stated in the source. Verify before relying on it. Treat as unconfirmed until Microsoft documents it explicitly.

5. Databases Are Now Agent Infrastructure Too

What Microsoft announced: A run of database news that does not look like infrastructure until you remember what agents actually do all day. The headliner is Azure HorizonDB, a new fully managed, PostgreSQL-compatible database service aimed at AI-powered apps, now in public preview. Alongside it, HorizonDB's AI and vector capabilities (pgvector-style vector search, DiskANN-based indexing, and in-database AI functions) are in preview, with some pieces in limited preview. Microsoft also previewed GPU-accelerated Fabric Data Warehouse, where eligible SQL query work can run on NVIDIA GPUs while the rest keeps running on CPUs. Add a batch of Azure Database for PostgreSQL Flexible Server updates for security, maintenance, and analytics at mixed maturity, plus Database Hub in Fabric, now in early access, for managing databases from one control plane.

Why infra/platform/SRE teams should care:

• Agents do not only call model endpoints. They hammer operational databases, vector indexes, and analytics warehouses, and they do it in bursty, highly concurrent, hard-to-predict patterns. That is a workload profile your DBAs will recognize and your capacity plan might not.
• A PostgreSQL-compatible managed service with vector search built in means your retrieval layer and operational data can live in an engine your team already knows, instead of one more bespoke vector store to run and patch.
• GPU acceleration for eligible warehouse queries changes the math on the analytics agents will trigger on your behalf. The careful part: it accelerates the query work that qualifies, it does not swap CPUs out wholesale.
• The Flexible Server updates are the unglamorous lane for the Postgres estate you already operate.

Business value in plain English: The data layer just joined the agent operations story. When an agent answers a question, it is usually reading from a database, searching a vector index, or scanning a warehouse, and the latency, cost, and governance of that data layer decide whether the feature feels instant or falls over under load. Managed Postgres with vectors in the box means fewer moving parts to operate. GPU-accelerated analytics means a heavy query can finish before the user gives up. None of it shipped with the word "infrastructure" on the box. All of it lands on the team that keeps the data layer healthy.

Try this first: Stand up an Azure HorizonDB preview instance, load a dataset shaped like your real one, turn on vector search, and run the exact retrieval pattern an agent would use. Measure p95 latency with realistic concurrency, not a single tidy query. If GPU-accelerated Fabric Data Warehouse reaches early access in your tenant, take one genuinely heavy analytical query and compare it with and without acceleration on representative data. Write the numbers down before anyone promises a roadmap.

Availability status (per item, mixed maturity):

• Azure HorizonDB: Public preview. AI and vector capabilities are preview, with some items in limited preview. Treat it as something to prototype on, not to anchor production data-tier commitments on yet.
• GPU-accelerated Fabric Data Warehouse: Early access preview, available soon. Eligible query work accelerates on GPUs while other work stays on CPUs.
• Azure Database for PostgreSQL Flexible Server (Build 2026 updates): Mixed GA, public preview, and private preview. Check the status of each specific feature before you lean on it.
• Database Hub in Fabric: Early access. Worth watching as a control-plane direction, not something to build on today.

6. Agent 365, Entra, Defender, and Purview: The Governance Problem Gets a Control Plane

What Microsoft announced: Agent 365, a control plane for inventorying, observing, governing, and securing agents, anchored in Entra for identity, Defender for threat protection, and Purview for data governance. Microsoft positions it for agents built across clouds, apps, and frameworks. Around it, a constellation of security capabilities landed at different maturity levels: Defender integration with GitHub Code Security, Purview risk signals in Foundry, Defender AI model scanning, and expanded preview access to secure code-agent tooling (MDASH).

There's also a Windows/local-agent story here: announced Agent 365 extensions for local-agent governance, plus early-preview OS-enforced containment via MXC. That's an endpoint and Windows governance announcement, not Azure cloud infrastructure. I'm calling it out explicitly so you don't quote a local-agent capability to justify a cloud architecture decision later. We've seen that mistake derail good conversations.

Why infra/platform/SRE teams should care:

• An agent acting on a user's behalf needs an identity, scoped access, and an audit trail. "It used a shared service principal" is not an answer your auditor will accept.
• Threat detection and data-loss controls for agents are the difference between "an agent touched sensitive data" being a logged, governed event versus an incident.
• Status is genuinely mixed here. Some of this is GA you can lean on; some is preview you should pilot quietly.

Business value in plain English: Agents that touch M365 data or act for employees are a compliance frontier. Identity and audit aren't nice-to-haves. They're the entry fee for regulated workloads. Agent 365 is Microsoft saying "here's where you wire in the governance," which is what lets your risk and compliance teams say "yes" instead of "absolutely not." Agent identity and audit never get a VM-sized headline, but they become load-bearing infrastructure the second an agent acts on someone's behalf.

Try this first: In a tenant that has access, register or deploy a low-stakes agent with an Entra-backed agent identity, give it narrowly scoped access, and confirm two things: it can do only what you granted, and every action shows up in an audit trail you can actually retrieve. Treat the audit trail as the deliverable. If you can't reconstruct who did what, you don't have governance. You have hope.

Availability status (split by lane):

• Microsoft Agent 365 control plane: GA for Commercial per Microsoft Learn; the Agent 365 SDK is called out as GA at Build.
• Defender + GitHub Code Security: GA.
• Purview risk signals in Foundry: GA; runtime DLP with Agent 365: preview.
• Defender AI model scanning: Preview.
• MDASH secure code agents: Expanded preview for eligible orgs, not open to everyone.
• Windows/local-agent expansions (local agent governance, MXC OS-enforced containment): MXC SDK is early preview; several local-agent Defender/Purview capabilities are coming soon. Again: Windows/endpoint story, not Azure infrastructure.

7. Microsoft Foundry as the Agent Platform, With Caveats

What Microsoft announced: Microsoft Foundry positioned as a place to move agents from prototype toward production as individual capabilities become available: hosted agents with a managed runtime (per-session sandbox, filesystem, memory, and elastic scale), Toolboxes for managing the tools agents can call, tracing and evaluations for observability and quality, a prompt/agent optimizer, and the ability to publish agents to Teams and Microsoft 365 Copilot.

This is the most "platform-shaped" announcement of the bunch, and, predictably, it's also the one where availability is scattered across GA, public preview, private preview, and "coming next month." Read this section slowly.

Why infra/platform/SRE teams should care:

• Agents need an operated home with a managed runtime, not a clever script someone runs from a laptop. Per-session sandboxing and elastic scale are operational table stakes once the relevant capability is available in your tenant.
• Tracing and evals are how you debug and prove quality. Without them, "the agent gave a bad answer" is unfalsifiable folklore.
• Publishing into Teams/M365 is where adoption actually happens, and also where your governance and change-management questions get real.

Business value in plain English: Foundry is Microsoft trying to give agents more of the boring operational maturity we expect from operated services: a managed runtime, tool governance, tracing, and evaluations. For the business, that's the bridge between "the AI team has a cool prototype" and "we can run the GA pieces with accountability." The closer an agent gets to real users, the more that boring maturity is worth.

Try this first: In a project where the relevant Foundry features are available, create one trivial agent, invoke it, and (this is the part that matters) open the execution traces if tracing is enabled for your tenant. Can you see what the agent did, what tools it called, and where it spent time? If you can't observe it in a lab, you'll never operate it in production. Make traceability your acceptance test.

Availability status (per capability, this one's a minefield, so be precise):

• Hosted agents (managed runtime): Announced as GA in the coming weeks / next 30 days, so treat as imminent GA, not GA-today.
• Routines: Public preview.
• Toolboxes: Public preview; skills / tool search: preview.
• Tracing and evaluations: GA later in June 2026, not yet at the time of writing.
• Rubric-based evals: Public preview.
• Optimizer: Public preview announced within the next 30 days, with private preview signup available now.
• Publishing to Teams / Microsoft 365 Copilot: Here's the careful one. The Foundry blog says this is going GA next month, but current Microsoft Learn docs still label it Early Access Preview and subject to Azure preview terms. So: announced as GA next month; current docs still mark it Early Access Preview. Don't build a production commitment on it until the GA docs actually update. Autopilot agents: public preview.

8. Azure Linux 4.0: The Boring Baseline That Quietly Matters

What Microsoft announced: Azure Linux 4.0, Microsoft's Fedora-derived, RPM-based Linux distribution optimized for Azure, now in public preview. Separately, Azure Container Linux is the immutable, container-optimized GA path. The pitch is a lean, hardened, Azure-tuned base OS for VMs now, with container and Kubernetes paths handled separately by Azure Container Linux or later Azure Linux 4.0 support.

Why infra/platform/SRE teams should care:

• Agents still depend on Linux somewhere: VMs, node images, container hosts, or base images. OS size, startup time, and patch cadence quietly tax every workload above it.
• An immutable, container-optimized OS shrinks your attack surface and your supply-chain risk: fewer packages, fewer CVEs to chase, fewer 3 a.m. patch scrambles.
• FIPS 140-3 work is in progress and expected at GA, which matters if you're in a regulated shop.

Business value in plain English: Nobody gets promoted for picking a good base OS, and nobody notices it, until a bloated image adds latency to every pod or a sprawling package list turns into a supply-chain incident. A lean, Azure-tuned baseline is compounding interest: a little efficiency and a little less risk on every single workload, paid out continuously. The least glamorous item on this list might be the one with the broadest reach.

Try this first: Take one representative VM workload and compare boot time, package footprint, patch cadence, and app compatibility on Azure Linux 4.0 versus your current general-purpose distro. For Kubernetes, test Azure Container Linux separately. Share the delta with your team. If the numbers are good, you've found a low-drama optimization that scales across your whole fleet.

Availability status: Azure Linux 4.0 is public preview for Azure VMs and VM Scale Sets. AKS, WSL, and runtime-image support are not available at preview, coming later. FIPS 140-3 is in progress, expected at GA. Meanwhile, Azure Container Linux is GA (per the AKS Build source). Don't conflate the two: different names, different status, different jobs.

The Whole Thing at a Glance

If your eyes glazed at the status column, good: that was the point. The single most useful skill in agentic infrastructure right now is reading availability labels like your incident budget depends on it. It does. Don't collapse mixed statuses into a single statement like "AKS is ready for agents." Each feature has its own maturity, and conflating them is how pilots turn into surprise incidents.

Next Actions Before Summer Vacation

You don't need a six-month migration to get smarter about this. You need a dev subscription, a couple of afternoons, and the willingness to write down real numbers. Pick a few:

1. Cobalt economics check. Request Cobalt 200 preview access and run one Arm-compatible workload for 24 hours against your current generation. Calculate cost per task and latency. Bring the delta to your next capacity conversation.
2. Prove the sandbox holds. Stand up two Container Apps Sandboxes and try to make one agent reach the other's files or network. If isolation holds, you've got a reusable pattern for running anything you don't trust. Write it up.
3. Run one outage drill. Group a single real app in Infrastructure Resiliency Manager, let it assess zonal posture, and run one outage drill against a non-prod copy. Find the one gap you didn't know about.
4. Demand a trace. In a Foundry project with tracing access, create a trivial agent, invoke it, and open the execution traces. If you can't see what it did, treat that as a blocking finding, not a detail. Observability is the acceptance test.
5. Weigh your baseline. Compare VM boot time and package footprint on Azure Linux 4.0 versus your current distro. Share the number with your team. Boring optimizations that scale across the fleet are the best kind.

None of these require you to commit to agents in production. They just make sure that when your developers inevitably show up with one, you already know how you'd run it with guardrails, observably, and without surprising the CFO.

Agentic ops wins compound faster when everyone can see the scoreboard. Run an experiment, write down what you found, and share it with the next infra team over. That's how this stuff actually gets good.

See you after vacation.

Sources & Availability Notes

All availability labels reflect official Microsoft sources as of 2026-06-07. Preview features should be tested in non-production only, and "announced as GA next month" is not the same as GA today. Verify current status in official docs before making production commitments.

• Azure Cobalt 200 VMs (early access preview / preview): New Azure Cobalt 200 VMs deliver 50% performance improvement, optimized for modern agentic AI workloads
• Azure Container Apps Sandboxes (preview): Container Apps Sandboxes overview - Microsoft Learn
• Azure Infrastructure Resiliency Manager (preview): Resiliency goals and recommendations - Microsoft Learn
• Azure Resiliency updates (IRM drills and recovery plans): What's new in Azure Resiliency - Microsoft Learn
• AKS at Build 2026 (mixed status per feature): What's new in Azure Kubernetes Service at Microsoft Build 2026 - Tech Community
• Anyscale on Azure (public preview): Quickstart: Create an Azure environment with gateway and Envoy - Microsoft Learn
• KAITO / AI toolchain operator (preview): Deploy AI toolchain operator add-on from the Azure portal - Microsoft Learn
• AI Runway AKS setup guidance (availability status not established by setup guidance alone): Set up AKS for AI Runway - Microsoft Learn
• Azure Linux 4.0 (public preview): Announcing Azure Linux 4.0, purpose-built for Azure, now in public preview - Tech Community
• Azure HorizonDB (public preview; PostgreSQL-compatible managed service for AI-powered apps): Azure HorizonDB overview - Microsoft Learn, Microsoft Build 2026: Building agentic apps with Microsoft Fabric and Microsoft databases - Azure Blog
• Azure HorizonDB AI and vector capabilities (preview, with some items in limited preview): HorizonDB AI overview - Microsoft Learn, Scalable Vector Indexing with DiskANN - Microsoft Learn, AI Functions in the azure_ai Extension - Microsoft Learn, HorizonDB release notes - Microsoft Learn
• GPU-accelerated Fabric Data Warehouse (early access preview, available soon; eligible SQL query work accelerated on NVIDIA GPUs while other work continues on CPUs): A new analytics frontier: GPU-accelerated Fabric Data Warehouse - Fabric Updates Blog
• Azure Database for PostgreSQL Flexible Server at Build 2026 (mixed GA / public preview / private preview, per feature): Announcing new security, maintenance, and analytics features for PostgreSQL at Microsoft Build 2026 - Tech Community
• Database Hub in Fabric (early access; control-plane direction): Advancing Databases for the Next Generation of Applications - Fabric Updates Blog
• Microsoft Agent 365 (GA for Commercial per Learn; SDK GA at Build): Microsoft Agent 365 overview - Microsoft Learn
• Microsoft Agent 365 FastTrack guidance (tenant onboarding/governance planning): Microsoft Agent 365 - Microsoft FastTrack
• Windows platform security for AI agents (local/endpoint story; MXC SDK early preview; several capabilities coming soon): Windows platform security for AI agents - Windows Developer Blog
• Securing code agents and models (Defender+GitHub GA; Purview signals GA; model scanning preview; MDASH expanded preview): Microsoft Build 2026: Securing code agents and models across the development lifecycle - Microsoft Security Blog
• Microsoft Foundry agent platform (hosted agents GA imminent; Toolboxes/routines public preview; tracing/evals GA later June 2026; optimizer public preview/private preview signup; Teams/M365 publishing announced GA next month but docs still Early Access Preview): Agent Service at Build 2026 - Microsoft Foundry DevBlog
• Microsoft Foundry availability and publishing docs (feature-specific GA/preview labels; Teams/M365 publishing currently Early Access Preview in Learn): Azure AI Foundry general availability - Microsoft Learn, Publish agents to Microsoft 365 Copilot and Teams - Microsoft Learn
• Azure preview terms: Supplemental Terms of Use for Microsoft Azure Previews

Build 2026 context and source map (event navigation, not capability-availability proof)

These links map the event and provide context. They do not, on their own, establish availability, production readiness, pricing, performance, or access status. Use the feature-specific official docs above for that.

• Microsoft Build 2026 hub: news.microsoft.com/build-2026
• Build 2026 Live blog: Microsoft Build 2026 Live
• Official Microsoft Blog - Build 2026: Microsoft Build 2026: Be yourself at work
• Keynote transcript: Microsoft Build 2026: MAI keynote transcript

Comparison reference (voice/style only): the 2025 Azure411 Build recap on quiet infrastructure upgrades - Boost, host maintenance, Compute Fleet, storage/networking, confidential GPUs.