Azure News - 2026-08-26

Whether you are troubleshooting an application issue at 2 a.m., validating a deployment plan before a release, optimizing cloud resources, or improving workload resiliency, the challenge is finding the right expertise quickly enough to act with confidence.

That’s why we are evolving the Azure Copilot experience.

As of August 2026, customers can engage directly with Azure Copilot agents, bringing focused expertise closer to the task at hand. Rather than routing requests through a single chat experience, you can now choose the specific agent best suited to your goal and move more quickly from question to action.

This new capability is a natural evolution of our vision for agentic cloud operations, making it easier for cloud ops teams to engage specialized AI expertise when and where they need it.

Azure Copilot agents

Every day, cloud operations teams balance a wide range of responsibilities from incident response and deployment planning to cost optimization and resiliency improvements. Those responsibilities often require different kinds of expertise.

With this release, users can directly invoke four Azure Copilot agents from the Azure Copilot chat experience:

• Troubleshooting agent
• Deployment agent
• Optimization agent
• Resiliency agent

Two additional agents in the Azure Copilot portfolio will continue to be available through their existing product experiences in the short term:

• Observability agent (generally available) through Azure Monitor
• Migration agent through Azure Migrate

Why direct access matters

Faster paths to answers

When users know which expertise they need, they can now engage that agent directly rather than starting with a generalized experience. This streamlines the path between question and resolution, helping teams spend less time navigating experiences and more time addressing the task at hand. Whether you're investigating an outage, reviewing deployment readiness, or identifying optimization opportunities, direct engagement with a specialized agent helps move from intent to action more quickly.

More focused expertise from the start

Each Azure Copilot agent is purpose-built around a specific operational domain. By selecting the appropriate agent upfront, users establish the right context earlier in the conversation and begin working immediately with the expertise most relevant to their goal. The result is a more focused experience that helps teams stay aligned to the task at hand and receive guidance tailored to their specific operational challenge.

Adopt agents at your own pace

Organizations often want to introduce new AI experiences incrementally. Direct agent access makes that easier by allowing individual agents to be evaluated, enabled, and adopted based on organizational priorities. Teams can begin with the scenarios that matter most to them, validate outcomes, and expand usage over time as confidence grows.

What does this mean in practice?

Direct access to agents is designed around how cloud teams already work.

When investigating a production issue, teams can engage the Troubleshooting Agent immediately rather than beginning in a generalized experience. For deployment planning and rollout activities, the Deployment Agent can provide specialized guidance. Organizations focused on efficiency can work directly with the Optimization Agent, while teams evaluating reliability and business continuity can engage the Resiliency Agent.

By aligning expertise to the task from the outset, Azure Copilot helps teams move more quickly from investigation and planning to action.

Enable adoption with flexible administration

As organizations expand their use of AI-powered experiences, governance matters just as much as capability.

With this update, Azure Copilot is moving away from preview sign-up and allowlisting requirements. Instead, administrators can manage agent availability directly through the Azure Copilot Admin Center. Global administrators can enable or disable individual agents independently, allowing organizations to pilot and validate specific experiences before rolling them out more broadly.

This approach makes it easier to align AI adoption with internal governance, operational requirements, and organizational readiness.

Organizations that have Azure Copilot disabled today will continue to have agents disabled unless Azure Copilot is enabled for their tenant.

Pricing

There are no changes to Azure Copilot pricing as part of this August 2026 release. Enabling Azure Copilot does not require an additional subscription or licensing fee.

Today:

• Troubleshooting Agent, Deployment Agent, Optimization Agent, Resiliency Agent, and Migration Agent are available at no additional charge.
• Observability Agent, which is generally available, continues to use its existing usage-based billing model.

Looking ahead

This release represents the next step in our vision for Azure Copilot: a collection of specialized AI experts that help cloud teams operate more effectively across the entire application and infrastructure lifecycle. Together, these capabilities lay the foundation for a future of agentic cloud operations, where purpose-built agents collaborate with teams across troubleshooting, deployment, optimization, resiliency, observability, and migration workflows.

In the months ahead, customers can expect expanded capabilities across existing agents, and new administrative controls that provide even greater flexibility in how organizations adopt and manage AI-powered assistance.

To learn more about Azure Copilot agents and how to get started, visit the Azure Copilot documentation.

By Sherry Xu, Prashant Ranjan, Torsten Hoefler

As we enter the era of frontier-scale intelligence, the economics of AI are increasingly determined not by peak compute performance but by how efficiently an entire system can generate tokens at scale. Production inference workloads are rapidly expanding beyond interactive chat toward an array of Copilots, coding assistants, deep reasoning, multimodal experiences, agentic workloads, and synthetic data generation. Azure Maia 200, Microsoft’s second-generation AI accelerator, is our latest custom silicon, engineered from the ground up for efficient inference at cloud scale.

At approximately 30% better performance per dollar than the latest-generation GPUs in Microsoft’s fleet, Maia 200 is built on one central principle: that co-optimizing the models, application harnesses, reinforcement learning environments, kernels, communication library, systems, and custom silicon will lead to the best customer outcomes – per token, per watt, and per dollar. 

There is no single specification that can achieve this, and no equation that drives faster math. System-level efficiency emerges from co-optimizing models, software, data placement, communication, and silicon together. At Hot Chips 2026, we are pleased to share the foundation behind that effort: the Software-defined Local Access architecture embodied in Maia 200.

Inference is becoming a systems challenge

Inference is no longer a compute problem alone—it is a systems problem that spans memory, networking, and software. As the range of production inference use cases continues to expand, workloads have also become more diverse and demanding.

Different phases of inference place different stresses on infrastructure: processing an initial prompt often requires substantial compute, while generating tokens over time can become constrained by memory bandwidth and communication. Emerging model architectures, including Mixture-of-Experts designs, sparse execution techniques, and advanced KV-cache strategies, further increase the importance of efficiently moving and managing data. At the same time, the largest models now span many accelerators, making communication between devices a critical factor in overall performance.

Meeting these demands requires optimizing for more than peak operations per second. An effective inference platform must deliver high throughput, low latency, reliability, and model quality while minimizing cost and energy per token. Maia 200 was designed with this broader objective in mind, and approaches this challenge using the architectural principles of Software-defined Local Access—both inside the accelerator and scaling to an all-Ethernet architecture that extends explicit memory orchestration across the system.

Software-defined Local Access: making movement explicit

Software-defined Local Access, or SDLA, is a dataflow architecture that gives software direct control over how data moves between high-bandwidth memory and localized, highly specialized SRAMs. Rather than relying on implicit cache behavior, SDLA separates control from data movement and gives software direct control over both memory movement and placement using Direct Memory Access (DMA) engines, compute engines, network operations, and synchronization. This approach helps the system achieve more predictable execution characteristics, enabling more consistent performance between runs. 

Maia 200 brings the SDLA principles together in a vertically co-designed system-on-chip. Its control, compute, memory, I/O, and synchronization structures are designed to operate concurrently rather than compete for a single control path. The purpose of the architecture is to keep the compute engines productively fed by placing, reshaping, moving, and synchronizing data efficiently.

All-Ethernet networking: extending SDLA beyond the chip

As models span accelerators, networking becomes part of the execution engine. Maia 200’s two-tier scale-up network applies an all-Ethernet approach, combining a standards-based physical and switching foundation with AI-specific endpoint hardware, transport, topology, congestion management, reliability mechanisms, and collective software.

Maia 200 delivers scalable, predictable performance for large AI inference deployments through an advanced two-tier, Ethernet-based scale-up networking architecture. Intelligent load balancing distributes traffic across on-chip resources, while built-in resilience mechanisms quickly adapt to network disruptions. This enables customers to run dense inference workloads more efficiently, maximize cluster utilization, reduce stranded capacity, and lower overall infrastructure costs.

We have contributed this direction to the Ultra Ethernet Consortium (UEC)’s AI base transport profile, helping establish Ethernet as a common foundation for networking across the industry.

Figure 1. Maia 200 uses a unified Ethernet hierarchy based on a variant of the HammingMesh topology: four accelerators form a directly connected quad, 48 accelerators form a rack-scale domain, and a two-tier switched network can scale to 6,144 accelerators.

Sustaining performance across real AI workloads

The value of the SDLA architecture appears in sustained kernel performance rather than peak specifications alone. To evaluate Maia 200 under realistic conditions, we measured performance across 6,143 matrix-multiplication shapes representative of production inference workloads. Across these scenarios, Maia 200 kept compute engines highly utilized, minimizing idle time by coordinating computation, memory, and communication as a single workload. Even as AI workloads shift between heavy computation (e.g., prompt processing), memory access (e.g., token generation), and communication (e.g., collective operations such as Allgather), Maia 200 maintains consistently predictable performance—treating the accelerator, memory, network, and software as one coordinated system.

Figure 2. FP8 matrix-multiplication performance across the same set of inference-relevant shapes, showing high utilization across compute- and memory-bound operating points.

Figure 3. Allgather performance on eight Maia 200 accelerators. Direct exchange minimizes latency for small transfers; ring exchange approaches the network bandwidth limit for larger transfers.

From silicon to useful AI systems

Maia 200 demonstrates Microsoft’s system co-design philosophy for model performance and efficiency. Maia 200 delivers over 40% higher token generation under the same rack power budget throughput when running the MAI-Thinking-1 model than other leading accelerators in the Azure fleet. This efficiency is only possible by co-designing models, application frameworks, reinforcement-learning environments, kernels, communication libraries, systems software, and custom silicon as a unified stack. At the same time, Maia 200 maintains the flexibility to support a broad ecosystem of open models, enabling customers to optimize for both performance and choice.

As Microsoft continues along a path of co-designing models and infrastructure, Maia 200 provides a foundation for improving quality, performance, cost, and energy efficiency for agentic inference workloads. We look forward to advancing these SDLA architectural principles in future generations of Maia system, and invite you to see the full details and data on Maia 200 operations in our latest paper on arXiv:[2608.24664] Maia 200: A Software Defined Dataflow System for Large-scale AI Acceleration.

To learn more, explore our blogs on Maia 200: 

• Maia 200: The AI accelerator built for inference
• Deep dive into the Maia 200 architecture

Today we're introducing Live Reports in Azure SRE Agent, now in public preview. You describe a dashboard in chat; the agent builds it, and it refreshes every time you open it. 

Ops teams ask the same handful of questions every morning: What's burning right now? What landed overnight? Who's on call? The answers usually live across multiple browser tabs, a one-off script only one person can run, or a chat prompt retyped daily and re-read as a fresh wall of text. Live Reports provides the missing piece: somewhere to author a view once and consume it many times.

Frozen structure, live data 

This is the core design decision: the layout is deterministic, and the data is live.

The agent authors the page once, then freezes it. Charts, thresholds, column order, and styling stay put. What refreshes on every open are the tool calls embedded in the page, so the shape is identical each morning, and the numbers are up to date.

That's what separates a Live Report from a dashboard an LLM regenerates on every view. The chart looks consistent every day, and the page loads like a standard web page rather than a streaming chat response because there's no model in the render path.

This leads to a key operational benefit: you only spend tokens when authoring the report. Opening a report built purely on tool calls uses no additional model tokens, no matter how many times you open it. (Reports that opt into AI-powered interpretation are the exception, as explained below.) This makes it practical for your entire team to open the report every morning without incurring ongoing LLM costs.

When you want changes, simply ask the agent. It will edit the page in place and save a new version, preserving earlier revisions so you can always reference previous configurations.

What you can build 

Report data sources include the connectors your agent already has access to: any connected MCP server, logs and metrics, source control, work items, and internal services.

Charts are real visualizations. Reports pull vetted charting and grid libraries from a CDN, giving you interactive, sortable tables and graphics rather than static markdown tables.

Reports can also reason at view time. Alongside tool calls, a report can send a focused prompt to a fast, lightweight model as it renders: classify alerts by severity, group issues by likely root cause, or summarize a discussion thread into a single line. Every reload re-fetches and re-interprets the data, keeping real-time judgment aligned with the latest telemetry.

Note: AI-powered interpretation consumes tokens each time the report loads, which is why it is strictly opt-in per report.

Reports can also take actions, but only the ones you wired in. A button invokes a write tool from a connector your agent is already connected to: acknowledge an incident, post to a discussion thread, assign an owner, open a work item. It cannot call an arbitrary URL or API of its own. Every button is limited to the exact tool names saved with that version of the report, and any tool that would ask for your approval in chat asks the same way when a button fires it. That's what turns a dashboard into something you operate from, without turning it into an open shell. 

The security model 

A model-authored page capable of calling production tools requires strict guardrails. It is constrained across four layers:

• Sandboxed origin: Reports render in an iframe with sandbox="allow-scripts" and deliberately omit allow-same-origin, ensuring the page runs at an opaque origin with no access to session tokens or cookies.
• Restricted network access: Report scripts cannot make direct API calls to arbitrary endpoints. All data requests route through the Live Reports runtime, which validates each call against the approved tool manifest for that specific report version.
• Per-version allowlists: A report can only invoke the exact tools it was configured with. Any unapproved call is rejected server-side at runtime, rather than relying on prompt-level instructions.
• Explicit human approval: When saving a report with connector access, the agent presents the exact tool descriptions provided by each connector. Nothing executes until you explicitly approve the configuration. Reports remain strictly bound to your agent's existing permission boundary.

 Exports are sanitized to a static, offline-safe file, which is safe to attach to a postmortem. 

Getting started 

1. Open the Live Reports tab and select New report.
2. Describe your scenario in chat. The agent will inspect your available connectors, ask clarifying questions if needed, and generate the layout.
3. Review and approve the tool permissions to add the report to your gallery.

What's next 

We're continuing to expand connector support, build richer visualization primitives, and tighten the loop between observability and automated remediation.

The best reports are often the ones we didn't anticipate. What is the operational view your team finds itself rebuilding by hand? Let us know in the comments.

👉 Try Live Reports in Azure SRE Agent

VNet integration for Azure SRE Agent is now generally available. You can route outbound agent traffic through your virtual network to access resources behind private endpoints, including databases, Azure Container Apps, Azure Kubernetes Service (AKS) API servers, and more. Traffic routed through your VNet follows your existing routes, network security group rules, firewall policies, private DNS configuration, and network logging.

How VNet integration fits into Azure SRE Agent security

Azure SRE Agent provides complementary security controls for enterprise workloads:

• VNet integration controls where outbound traffic can go and applies your routing, firewall, DNS, and network logging policies.
• Identity and permissions provide the identity and authorization layer and determine which resources and connected systems the agent can access.
• Tool policies and approvals control which operations the agent can run and when human review is required.

VNet integration controls outbound traffic only, and not all Azure SRE Agent traffic routes through your virtual network.

What's new since preview: inspect network activity

Administrators can now inspect network activity from the Azure SRE Agent portal. Open Settings > Workspace configuration > Inspect.

Run commands in the workspace shell to test which destinations the agent can reach. Use Network audit to review allowed and denied outbound requests and their policy decisions.

Network audit covers agent egress-policy decisions. It isn't a complete network audit trail and doesn't replace logs from your firewall, DNS, proxy, or other network infrastructure.

Inspect network activity in Azure SRE Agent

Enable VNet integration

1. Prepare an empty, dedicated subnet that is /27 or larger, in the same region as the agent, and delegated to Microsoft.App/environments.
2. Create or open an Azure SRE Agent.
3. Select Settings > Workspace configuration.
4. Select Azure VNet, and then select Browse subnets.
5. Choose the virtual network and delegated subnet, select Connect, and then save the configuration.
6. Review the On the infra network settings. If the agent needs a code repository, enable its provider or make sure your VNet allows outbound access to the repository host.
7. Test access to a resource that requires the intended network path.

Note: After you connect a VNet, the agent remains in Azure VNet mode. Disconnect the VNet before switching to Limited or Unrestricted mode.

Learn more

For the original architecture overview and the design decisions behind VNet integration, read the preview announcement blog: VNet integration for Azure SRE Agent (preview).

For current requirements, routing details, limitations, and troubleshooting, see Azure SRE Agent network integration.