Unlocking the next frontier of Local AI on Windows for Telecommunications

At Build 2026, we announced significant new capabilities across our on-device AI platform that expand what’s possible at the edge, in the field, and in the network operations center. This post covers two key areas and what they mean for telecom: new capabilities in Microsoft Foundry on Windows, and the introduction of secure agent execution and governance on Windows.

Before we go further, let’s be clear about one thing: this is not a cloud-versus-device story. Cloud remains essential for training, orchestration, and shared intelligence across the network. What on-device AI does is expand the operating model. It adds a new execution tier that unlocks scenarios that were harder to deliver before because of latency, resiliency, privacy, or runtime constraints. The goal is to place AI where it creates the most value, and for many telecom workloads, that’s closer to the point of action.

What Local AI unlocks for telecom

When you bring AI inference to the device, it opens up scenarios that may have been limited in cloud-only architectures:

• Customer care at the point of interaction. Agents that can respond faster, with richer context, without round-tripping to a data center.
• Field and frontline continuity. Workflows that keep working when connectivity is weak, inconsistent, or unavailable: remote cell sites, underground facilities, rural deployments.
• Time-sensitive network operations. Decisions that need to happen quickly at the edge without cloud latency.
• Privacy and sovereignty by default. Inference on sensitive telemetry and customer data without it leaving the jurisdiction.
• Local agents that act, not just advise. A shift from generic copilots to agents that take action on the device, with better support for long-running execution, tool use, and reliable runtime behavior.

Windows is where much of telecom’s enterprise and operational work already happens. NOC workstations, field technician laptops, back-office systems, retail point-of-sale. That installed base creates an opportunity: make the existing device a better surface for local AI execution without requiring new hardware or new deployment footprints.

The differentiator isn’t just model runtime. It’s the complete environment: model execution, agent runtime, containment, and governance, integrated at the OS level. At Build 2026, we shipped the next wave of platform capabilities that make this concrete.

Microsoft Foundry on Windows: new capabilities at Build 2026

Microsoft Foundry on Windows is our unified local AI platform, first introduced at Build 2025 and generally available since earlier this year. It gives developers and operations teams three complementary ways to run AI on-device, with hardware abstraction across NPU, GPU, and CPU. At Build 2026, we announced new capabilities across each layer of the stack that significantly expand what’s possible for telecom workloads.

 

Windows AI APIs: expanding reach and capability

Windows AI API Header

Windows AI APIs provide the fastest path to integrating local AI into applications. These are ready-to-use, OS-managed capabilities powered by on-device models. These are the same capabilities that power Copilot+ local AI experiences today. Outlook Summarize, Alt Text Generation, and Teams video upscaling all run through these APIs locally on Copilot+ PCs. When you build with Windows AI APIs, you’re tapping into the same proven inference pipeline that millions of Windows users already rely on daily.

New at Build 2026: We are expanding Windows AI APIs beyond NPUs to CPUs and GPUs, bringing local AI experiences to a much broader set of Windows 11 devices. We’re also introducing a new Speech Recognition API (aka.ms/speech-recognition-api) for real-time on-device speech-to-text.

Unlocked potential for telecom:

• Field technicians use on-device OCR to read equipment serial numbers, fiber labels, and antenna configurations offline at remote cell sites. No connectivity, no cloud dependency, no delay.
• NOC analysts run local semantic search across alarm logs and trouble tickets for faster root-cause analysis, without sending sensitive network data off-premises.
• The new Speech Recognition API enables on-device transcription of field calls, dispatch audio, and customer interactions, even without network connectivity. This unlocks new workflows for dictation-enabled maintenance reports and real-time captioning in operations centers.
• With GPU and CPU expansion, these capabilities now reach the broader fleet of Windows devices already deployed across telecom operations, beyond Copilot+ PCs. Learn more at aka.ms/WinAI/APIs.

Foundry Local: flexible local inference on standard enterprise hardware

Foundry Local is Microsoft’s cross-platform local AI runtime that lets developers run AI directly into their applications without cloud dependency and cloud token costs. First previewed at Build 2025 and generally available since April 2026, Foundry Local is designed for scenarios where you need more flexibility than a pre-built API: running open-source language and vision models on-device with full control over inference and acceleration.

Foundry Local supports five SDKs (C#, Python, JavaScript, Rust, and C++) and works on standard enterprise hardware. It is not limited to Copilot+ PCs. It handles model packaging, runtime fragmentation, hardware differences, and deployment complexity so teams can focus on shipping features rather than stitching infrastructure together. With access to the Foundry model catalog, developers can run models for chat completions, embeddings, live audio transcription, and vision-language tasks entirely on-device.

New at Build 2026: The 1.2.0 release expands language support in the Live Transcription API, introduces inference cancellation for cleanly stopping in-flight requests, and upgrades to Windows ML (WinML) 2.0 for NPU and GPU acceleration without extra installation steps. Cross-region catalog routing now delivers faster model downloads for end users. Foundry Local also adds a Responses API for structured agentic interactions including tool calling and multimodal vision-language input.

Foundry Local is already being used across privacy-sensitive, performance-sensitive, and hardware-diverse scenarios. From local assistants and document workflows to multimodal context collection and enterprise AI pipelines, developers are using it to reduce platform complexity and deliver production-ready AI experiences faster. Learn more at devblogs.microsoft.com/foundry.

Unlocked potential for telecom:

• Data sovereignty. Run inference on network telemetry, customer records, and performance data without it leaving your data center or jurisdiction. Critical for regulated markets and government contracts.
• Autonomous network operations. Deploy local models that triage alarms, correlate events across network domains (transport, IP, radio), and recommend remediation actions, all on-prem with enterprise-grade privacy and offline operation.
• Disconnected scenarios. Field crews in rural tower deployments or underground facilities get full AI-assisted workflows without depending on backhaul connectivity.
• Custom model flexibility. Fine-tune models on your proprietary network data (topology, KPIs, fault patterns) and deploy them locally through Foundry without vendor lock-in.

Windows ML: the foundation for local AI at scale

 

Windows ML, generally available since September 2025, is the native ONNX Runtime-based engine for deploying custom AI models across Windows devices. It acts as a hardware abstraction layer to easily distribute models across CPUs, GPUs, and NPUs while ensuring the best on-device performance. Windows ML is also the foundational layer that powers Foundry Local, providing broad silicon support and a consistent deployment experience.

At Build 2026, Windows ML continues to expand its silicon support and serves as the engine delivering unmetered intelligence on Windows, enabling the new Aion models and expanded API reach described above.

Unlocked potential for telecom:

• Predictive maintenance. Deploy custom ONNX models trained on your specific equipment failure data to field devices or edge nodes. Predict faults before they become outages.
• RF optimization. Run propagation models or beamforming optimization algorithms on-device at cell sites for real-time RAN tuning without cloud latency.
• Anomaly detection. Deploy bespoke network anomaly detection models, trained on your traffic baselines, to edge servers for instant threat and fraud identification.
• Bring-your-own-model. CSPs with mature data science teams deploy proprietary models across their Windows fleet without being constrained by a single vendor ecosystem.

Local AI Telecommunications App demo

We’ve built a sample field technician application that combines Windows AI APIs (on-device OCR for reading equipment labels) with Foundry Local (a workflow that diagnoses the fault, recommends a fix, and generates a work order), all running locally with zero cloud dependency.

(Note: This is NOT a Microsoft licensed product or application. This is NOT an officially supported Microsoft offering. Microsoft assumes no responsibility or liability for any use of this code.)

GitHub: https://github.com/opesam/LocalAIDevelopment/tree/telecom-field-ai

Introducing Aion: a new family of models for local AI

At Build 2026, we introduced Aion, a new family of on-device models purpose-built for local execution on Windows. Aion represents a new generation of small language models that are smaller, faster, and more efficient than our previous Windows OS SLMs. Over time, Aion models across multiple parts of the on-device AI stack, though they have not yet been fully productized into specific APIs or features. Try Aion at aka.ms/tryaion

The Aion family includes two models at launch:

• Aion 1.0 Instruct is optimized for instruction-following tasks: summarization, text generation, classification, and general-purpose language understanding. It is smaller and more efficient than our previous Windows OS SLM, delivering improved quality at lower compute cost.
  
  
• Aion 1.0 Plan is a 14-billion parameter reasoning and tool-calling model with 32K context, designed for agentic workflows. It can reason over user intent, invoke tools, manage files, and orchestrate sub-agents, enabling fully agentic execution on-device without cloud dependency.

These models point toward a future where the full local AI stack benefits from purpose-built, efficient on-device intelligence. As they are integrated across APIs and features, they will unlock new classes of experiences for developers building on Windows

Unlocked potential for telecom:

• A path to agentic network operations. As Aion models mature and integrate across the platform, they open the door to local agents that can triage alarms, correlate events across network domains, and recommend remediation actions entirely on-prem.
• On-device planning and orchestration. Aion’s reasoning and tool-calling direction enables multi-step workflows: a field technician’s device diagnosing a fault, looking up parts inventory, generating a work order, and scheduling a follow-up, all locally without waiting for a cloud round-trip.
• Efficient local intelligence. Aion’s smaller footprint and improved efficiency mean these capabilities will run well on the existing Windows hardware already deployed across telecom operations, without requiring top-tier GPU resources.

Secure agent execution and governance on Windows

Running models on-device is one thing. Running agents on-device, agents that take actions, access systems, and operate continuously, is a different challenge entirely. The question every CSP asks is the same: how do we let agents operate with enough autonomy to be useful, while maintaining the governance and security posture our business demands?

At Build 2026, we introduced new capabilities that address this directly.

Introducing Microsoft Execution Containers (MXC)

Microsoft Execution Containers (MXC), introduced at Build 2026, is a policy-driven execution layer integrated into Windows and WSL. Developers declare what an agent can access (files, network, system resources) and MXC enforces those boundaries at runtime. It is not a single isolation technology. It is a composable spectrum: from lightweight process isolation to session isolation to full micro-VMs, dynamically matched to the risk profile of the workload. Get started at github.com/microsoft/mxc.

Every agent running inside MXC is bound to an identity, either local or cloud-provisioned through Entra, so every action is attributable, auditable, and governed at the kernel level. MXC is delivered as an SDK, now available in early preview. OpenAI and NVIDIA are already building on it.

Unlocked potential for telecom:

• OSS/BSS protection. Constrain agents that interact with production network management systems to read-only access. Prevent accidental or malicious configuration changes to live network elements.
• Multi-vendor agent isolation. When you deploy AI agents from multiple vendors (RAN analytics, transport optimization, independent fault correlation), each operates within strict boundaries. No cross-contamination of data or access between vendor agents.
• Regulatory auditability. Every agent action is attributable to a governed identity. Essential for telecom regulatory compliance: data retention, lawful intercept boundaries, GDPR, local privacy regulations.
• Zero-trust agent architecture. MXC enables a zero-trust posture for AI agents: assume breach, verify continuously, limit blast radius. This maps directly to the security frameworks telecom already operates within (3GPP, NIST CSF).
• Edge deployment security. Agents running at cell sites or multi-access edge compute nodes operate within kernel-enforced boundaries, even in physically less secure environments.

Learn more at: Windows Platform Security for AI Agents and aka.ms/BUILD_SecurityBlog 

Windows 365 for Agents: enterprise governance for agent fleets

Windows 365 for Agents, generally available since May 2026, provides computer-using agents with secure, managed Cloud PCs to execute enterprise workflows. It is the enterprise-grade platform for discovering, governing, and securing AI agents at scale, whether those agents are built by Microsoft, third parties, or your own teams.

New at Build 2026: Windows 365 for Agents now integrates natively with MXC on Windows, delivering Defender, Entra, Intune, and Purview protections so that security and IT teams can constrain and secure local agents to prevent enterprise risk. This integration is available in preview starting July 2026.

Windows 365 for Agents provides end-to-end observability across your entire agent estate. It surfaces “shadow AI”: agents that have been deployed across the organization without IT visibility or approval. Agents run in secure, managed Cloud PC environments (learn more), fully separate from user machines, for executing enterprise workflows that require a full desktop context.

Unlocked potential for telecom:

• Agent fleet management at scale. CSPs may operate hundreds or thousands of AI agents across network domains: core, transport, access, customer operations. Windows 365 for Agents provides a single pane of glass for visibility and governance. Think of it as a network management system, but for AI agents.
• Shadow AI discovery. Identify agents that business units or vendors have deployed without IT approval, a growing risk in large telecom organizations where multiple vendor ecosystems operate simultaneously.
• Policy-driven autonomy. Define precisely what each class of agent can do. A network healing agent can restart services but cannot modify routing tables. A customer service agent can access CRM but cannot process billing adjustments above a threshold.
• Compliance and data governance. Purview integration ensures that agents handling customer PII (call detail records, location data, subscriber information) comply with GDPR, local telecom regulations, and data residency requirements.
• Operational continuity. If an autonomous agent misbehaves in a live network, operators can detect, halt, and remediate before customer impact. Mission-critical for the five-nines availability telecom demands.

Why Local AI matters now for Telecommunications

Local AI is not a retreat from cloud. It is an expansion of what AI can do across the telecom operating model.

Build 2026 delivered the next wave of capabilities CSPs need to move from experimentation to execution: expanded local inference that reaches more devices and more scenarios, a new generation of on-device models purpose-built for agentic reasoning, and for the first time, OS-level containment and governance for autonomous agents.

Microsoft Foundry on Windows gives you the inference engine: pre-built APIs for quick wins, an open-source runtime for agentic workflows, and a custom model deployment layer for your proprietary workloads. MXC and Windows 365 for Agents give you the guardrails: containment, identity, policy, and observability for every agent in your fleet.

Telecom has always operated at the intersection of scale, reliability, and trust. The scenarios where on-device AI creates the most value (customer operations, field workflows, network operations, autonomous remediation) are exactly the scenarios where latency, resiliency, privacy, and governance matter most.

The question for CSPs is no longer whether to run AI locally. It’s which workloads benefit most from this new execution tier, and how quickly you can get started.

Get started

• Visit the Microsoft booth at DTW Ignite 2026 in Copenhagen (June 23–25)
• Reach out for a Local AI pitch and envisioning conversation: aka.ms/opesamolowu
• Explore Microsoft Foundry on Windows: learn.microsoft.com/windows/ai
• Get started with MXC: github.com/microsoft/mxc
• Learn more about Windows 365 for Agents: Windows 365 for Agents documentation
• Read the full Build 2026 Windows platform blog: Build 2026: Furthering Windows as the trusted platform for development