Microsoft Wants Your PC to Work While You Sleep, Surface Laptop Ultra Pre-Orders Open

New Windows agent containers, local AI models, intelligent routing, and NVIDIA-powered PCs point toward a computer that can keep working long after you close the chat window.

Most computers have spent their lives waiting for us.

Waiting for a click. Waiting for a document to open. Waiting for someone to remember which folder contains the spreadsheet that somehow became essential to the entire business.

Microsoft’s latest Windows announcements assume that relationship is changing. Your computer will increasingly have work to do even when you aren’t actively operating it.

On October 7, Microsoft outlined a broad expansion of what it calls hybrid intelligence: AI systems that combine models running on your own hardware with models in the cloud. The announcement spans local coding models, automatic task routing, new Copilot capabilities, security infrastructure for agents, and Windows machines ranging from small desktops to deskside AI supercomputers.

Surface Laptop Ultra and other NVIDIA RTX Spark laptops are opening for preorders. Microsoft Execution Containers, or MXC, are becoming generally available. GitHub’s HydraFusion routing technology is expanding to local Windows models. Copilot is getting access, with permission, to more of the files and actions on your PC.

That is a lot of product news. But the bigger story is what happens when those pieces work together.

Microsoft is building toward a PC that can accept an assignment, break it into tasks, decide which intelligence each task needs, and carry out the work inside boundaries you or your organization set.

In interviews with The Neuron ahead of the announcements, Microsoft’s Windows platform and AI teams described both the opportunity and the unfinished engineering underneath it.

Logan Iyer, who leads Microsoft’s Windows platform team, put the economic argument particularly well: “save your frontier tokens for frontier problems.”

Vivek Pradeep, who works on AI and Windows in Microsoft’s applied sciences organization, posed a question that gets at the change in the computer itself: “what does a computer do when you sleep?”

Increasingly, Microsoft’s answer is: something useful.

The next AI PC needs more than an AI chip

For the last few years, the AI PC conversation has often revolved around a specification: how much AI compute a machine has, which accelerator it uses, or whether it can run a particular model.

Those details matter. But an agent needs a whole working environment.

A model might understand a request to update a website. Completing that request requires access to source files, development tools, commands, and possibly a browser. It may also require multiple attempts, tests, and decisions about what to do when something fails.

That creates two practical questions.

First, how much of that work really needs a premium cloud model?

Second, how do you let an agent work independently without giving it authority over everything on your computer?

Microsoft’s October announcements address those questions together. More capable local models make it possible to move some work onto the device. Intelligent routing decides which tasks belong there. Containment restricts the files, networks, and interfaces an agent can access.

The hardware supplies the capacity to make that arrangement useful.

This develops the direction Microsoft showed at Build earlier this year, when Windows, local models, agent tools, and new devices appeared as parts of a larger system. Our Microsoft Build breakdown covered that initial picture. October brings more concrete availability dates and a clearer explanation of how the pieces are supposed to cooperate.

The distinction matters because buying an AI-capable laptop and getting a useful autonomous workflow are still different things.

Microsoft is trying to close the distance between them.

Hybrid intelligence changes which tasks need the cloud

The simplest way to understand hybrid intelligence is to imagine one assignment that contains several kinds of work.

You ask a coding agent to add a feature. It needs to understand the request, inspect the repository, develop a plan, change files, write tests, and evaluate the result.

Some of those steps may benefit from the strongest available reasoning model. Others are narrower and more repetitive. Searching a repository for relevant files does not always require the same intelligence as making an architectural decision.

Iyer framed the opportunity around a problem heavy AI users already recognize: the meter keeps running, even when an agent is doing relatively ordinary work.

“Everybody’s token cost is like ballooning dramatically,” he said. Microsoft’s approach is to “save your frontier tokens for frontier problems.”

That means reserving the strongest cloud models for the decisions that benefit from them, while capable local models handle more of the supporting work. As agents split assignments into parallel subtasks, those choices become increasingly consequential.

Iyer described local models taking on simpler coding tasks and repository analysis, while more demanding work continues to use cloud models.

The benefit becomes more substantial as agents delegate. A single request can produce many subtasks, sometimes running in parallel. If every subtask calls an expensive cloud model, the cost grows with the agent’s activity.

Microsoft wants capable local models to absorb more of that work.

Pradeep described a related approach: use a small local model to identify which files are likely to matter before a larger model searches or reasons over them. That could reduce how much irrelevant material reaches the more expensive part of the system.

The important measure is the completed assignment. A cheaper individual model call is useful only if it contributes to a reliable result.

Good routing should account for the cost of retries, the time a task takes, and whether the local model can actually handle it. If offloading creates a stream of mistakes that a cloud model must repair, the savings become much less convincing.

That makes the router a major part of the product.

GitHub HydraFusion is expanding onto Windows devices

Microsoft says GitHub’s HydraFusion will extend its model-routing capabilities to models running locally on Windows.

The Windows hybrid experience is scheduled to arrive in experimental preview later in October in the GitHub Copilot app, GitHub Copilot CLI, and Visual Studio Code.

The intended experience is straightforward: give the agent a task, and let the system determine which subtasks should use local models and which should use cloud models.

Jatinder Mann, who runs product for the Windows Platform Developer Team, described the router looking at a task, breaking it down, and assigning the parts to appropriate models. That reduces the manual model selection developers otherwise have to do, and that many end-users won't want to do.

But automatic routing also creates a need for visibility.

Iyer described usage reporting that would show what happened locally, alongside work on enterprise financial reporting. He also discussed frontier-token budgets that could influence how aggressively the system routes tasks onto the device.

Those interview descriptions explain the direction of the experience; they should not be read as a promise that every reporting or budget control will ship in the first experimental release.

Still, the idea is useful. A developer could delegate a long assignment while retaining a way to inspect where the work ran and what it consumed.

Pradeep said different users will want different degrees of control. Some developers want to choose their models explicitly. Others want local execution or cloud execution for particular reasons. Others will prefer automatic selection.

A successful hybrid system needs room for those preferences.

It also needs to earn trust. Developers will quickly notice if automatic routing saves tokens but makes their work worse.

Microsoft is fitting much larger models onto PCs

The routing story depends on local models being capable enough to do meaningful work.

Microsoft says it is bringing MAI Code 1.1 Flash onto devices using 3-bit precision. The model has 137 billion total parameters and 6.8 billion active parameters, and the local version supports a 256K context window.

The written announcement says the optimization reduces model size by nearly 80% while preserving coding quality.

There are two useful distinctions in those numbers.

The total parameter count describes the model’s overall size. The active parameter count describes how much of it is used during computation. A model with 137 billion total parameters and 6.8 billion active parameters therefore has different compute demands from a dense model that activates all 137 billion.

Memory remains essential, however. The model’s weights still need somewhere to live, along with working memory, context, and the other software on the machine.

Quantization helps by storing model values at lower numerical precision, reducing their memory footprint. The engineering challenge is preserving useful behavior after that compression.

Pradeep described the team’s work at very low precision, including mixed 2- and 3-bit approaches, and contrasted today’s local context capacity with an earlier period when holding just 512 tokens in memory was worth celebrating internally.

Microsoft is also bringing DeepSeek v4 Flash, described in the written announcement as a 280-billion-parameter model, to local execution on RTX Spark.

Those are substantial claims about what local hardware can support. They also need to be interpreted carefully.

Parameter counts alone do not establish model quality. A large context window does not guarantee that a model will use every part of a long input reliably. And a model fitting into memory does not tell you how quickly it will complete a real assignment.

The useful test is whether an optimized local model can perform its assigned work accurately enough, quickly enough, and without monopolizing the computer.

Pradeep was clear that the strongest cloud models are continuing to advance.

“The frontier is not waiting to be caught by anyone,” he said.

That is why hybrid intelligence has a durable role. Local models can become more useful even while cloud models keep getting stronger.

Smaller models are improving, too

The largest local models make the headlines, but the smaller ones may handle much of the everyday work.

Pradeep described productivity tasks such as organizing files and creating documents as workloads that can be served effectively by models far smaller than the largest coding systems.

He also described his team replacing a roughly 4-billion-parameter model with a 2.3-billion-parameter model that delivered better quality and faster throughput.

That is a useful reminder that progress does not always mean adding parameters.

Better training, specialization, and optimization can make a smaller model more valuable than its predecessor. Faster execution can also allow a system to try, evaluate, and refine an approach more efficiently.

That could change how people experience the useful life of a computer. If compatible models improve without requiring more memory or compute, existing hardware may gain capabilities through software.

There are limits. A model that needs 128GB of unified memory will not become available on a modest laptop simply because Windows receives an update.

But the direction is encouraging: some improvements can come from using the hardware more effectively, rather than replacing it.

Windows ML is becoming part of the plumbing

Microsoft is also announcing llama.cpp support in Windows ML, expanding the runtime’s options for open-source models.

A runtime is the software layer that gets a model executing on available hardware. For Windows, that means accommodating a broad ecosystem of CPUs, GPUs, and neural processing units, or NPUs.

Mann described three layers developers can use.

Windows AI APIs provide access to built-in capabilities. Foundry Local offers a way to obtain models from a catalog, with versions selected for the device’s capabilities. Windows ML sits underneath as the execution layer for developers working more directly with models.

The goal is to make local AI easier to deploy across machines with different hardware.

But simplifying the developer experience creates a tension. Hide too much of the hardware, and you can lose the optimizations that make it perform well.

Pradeep acknowledged that Microsoft had learned from earlier work that emphasized abstraction and developer ease without sufficiently preserving low-level performance.

His team now thinks across the whole machine.

“The entire computer, the silicon is compute real estate,” he said.

An agent uses more than an AI accelerator. Its tools and coordination software consume CPU resources. Models use memory. Multiple workloads may compete for the GPU or NPU.

That means useful local AI requires operating-system work as well as model work.

Your background agent still has to share the computer

There is an obvious problem with turning your laptop into an agent workstation: you probably still want to use the laptop.

A background coding task should not make a video call unusable. An agent generating tokens should not starve the AI features handling your camera or audio.

Pradeep described prioritization and preemption mechanisms that let more urgent workloads receive compute before a background model.

For example, an NPU running a language model may need to pause that work so a camera or audio process can execute on time. The language model takes longer, but the interactive experience remains responsive.

He also described the possibility of using different accelerators for different phases of model execution. Processing a large prompt can demand substantial compute, while generating the response in the background creates a different power and performance problem.

“I don't want to consume power and drain your battery. So I want the decode to run on the NPU,” he said.

That is the sort of detail that rarely makes a launch headline but can determine whether people actually use a feature.

A useful background agent must coexist with meetings, browsing, games, and the other things the owner expects the machine to do.

Pradeep acknowledged that “by no means we are at the end of the journey.”

More concurrent AI workloads create more scheduling problems. Microsoft has made progress on the underlying platform, but it still has work ahead.

MXC puts a boundary around an agent’s work

Local compute answers where work can run. Microsoft Execution Containers address what that work is allowed to touch.

Microsoft says MXC is now generally available on Windows 11, providing a policy-driven execution layer for untrusted code and dynamically generated workloads.

An agent developer can use it to contain generated code, tools, plugins, the agent’s coordination software, or the entire agent.

Iyer described containment as something that can be tailored to the assignment, rather than granting an agent every permission it might conceivably need.

“So you can actually construct policy and like sandboxes on the fly that limit it to just the thing that it’s supposed to do and not anything else,” he said.

The written announcement uses a website update as an example.

An agent may need permission to read and modify a repository. It may also need to read production server configuration to understand deployment. That does not mean it should be able to change the production configuration.

The agent might decide that changing it is the easiest way to finish. A containment boundary is designed to prevent that operation regardless of what the model decides.

The policy sits outside the agent workload’s control. The agent cannot simply give itself more access.

That principle becomes more important as people delegate longer tasks.

A prompt can explain the user’s intent, but the execution environment needs to enforce the authority actually granted. Otherwise, a model’s interpretation of an assignment can turn into permission to affect unrelated systems.

MXC gives developers and organizations a way to define access to files, network destinations, and other resources, then enforce those limits during execution.

Microsoft’s September Windows Insider release notes had already documented MXC process isolation and preview support for identifying agentic processes. The October announcement advances that broader platform direction.

Different agents need different kinds of isolation

MXC is designed around several containment options.

“It's a spectrum of isolation and you can decide,” Mann said.

The options described in Microsoft’s announcement include:

• Process container: Lightweight containment for responsive workloads, generated code, and tool execution on Windows 11, macOS, and Linux.
• Session container: A separate Windows account and session for agents needing their own desktop, clipboard, and input environment.
• WSL container: A Linux environment on Windows for Linux-oriented tools and development workflows.
• MicroVM: An experimental option on Windows 11 and Linux for workloads benefiting from a hardware-backed virtualization boundary.

These have different security properties. A process sandbox and a virtual machine should not be treated as interchangeable simply because both appear under the MXC umbrella.

For developers, Microsoft’s approach separates the workload’s declared requirements from the details of the operating system’s containment mechanism.

Process containers use AppContainer on Windows, Seatbelt on macOS, and Bubblewrap on Linux. Developers integrate through a common configuration schema and SDK, while MXC maps the requested controls to the relevant backend.

Microsoft also says Windows 365 support for MXC is generally available, extending the approach to agents running on Cloud PCs.

The strategic benefit is consistency: an agent developer can describe what a workload needs without rebuilding every containment decision independently for each environment.

The limits still matter. Cross-platform support does not mean every backend is available on every operating system.

A separate agent desktop could solve an everyday annoyance

One of the most immediately understandable features is the Windows session container.

Anyone who has used a computer-control agent knows the awkward moment when it needs the same screen, mouse, or keyboard you are using.

You move something. The agent loses its place. It clicks somewhere unexpected. Your attempt to keep working becomes part of its problem.

Mann described a Windows session container as giving an agent a workspace separate from the person using the computer.

“This is like another user logs into your PC,” he said. “So it has its own local agent identity, isolated desktop, clipboard, UI, input boundary.”

That addresses an everyday frustration with computer-use agents: competing with them for control of your own machine.

“One of the challenges with computer use is it often uses input,” Mann said. “And so it can take your input away, but in a separate session, it has its own input.”

Iyer gave a concrete example: “the agent can have its own instance of Chrome and Edge and it can do its own set of things.”

The intended result is an agent that can carry out its assignment while you continue working in your own session.

That does not resolve every reliability problem in computer automation. An agent can still misunderstand an interface or carry out the wrong sequence.

But it addresses a practical obstacle to using these systems regularly: sharing one interactive workspace.

Giving an agent its own session could make computer-use tasks much easier to run alongside ordinary work.

Observing an agent is different from restricting it

Writing a good permissions policy can be difficult when you do not know which resources a workload will require.

Microsoft describes three MXC operating modes to help with that process.

Enforcement mode blocks operations outside the granted boundary.

Learning mode also blocks ungranted operations, while recording them in an activity report so developers or administrators can diagnose what happened.

Permissive mode records access that the policy would have denied but allows the operation to continue. Other applicable operating-system and organizational restrictions still apply.

The distinction is important. Permissive mode is useful for observing activity and developing policy; it does not enforce the same MXC restrictions as Enforcement or Learning mode.

Microsoft says Windows MXC process containers can generate activity reports to help authors build policies that grant only the access a workload requires.

An organization could observe a workflow, understand which files and destinations it needs, and refine the boundary accordingly.

But an activity report has to become something people can understand.

Iyer discussed the challenge of exposing detailed logs to power users while making the information useful to people who will never examine a large technical trace.

That is an important product problem. Most users want to know which files changed, which services were contacted, and whether the agent stayed within its assignment.

The reporting system must turn technical evidence into answers people can act on.

Agents are getting identities separate from their users

Containment determines what an agent may do. Identity helps establish which agent performed an action.

Microsoft says Windows will soon enable Microsoft Entra to distinguish agent activity from human activity in Microsoft Agent 365.

That could let organizations assess an agent’s behavior and restrict its access independently of the employee who uses it.

Mann explained why distinguishing an agent from its user matters when something goes wrong. If an agent performs a risky action, organizations should be able to restrict that agent without automatically interrupting the employee’s access.

“So its access to corporate resources will be blocked, not yours,” he said.

That separation becomes more important as people use multiple agents. Security teams need to identify which agent caused a problem and respond to that activity specifically, instead of treating every action on the device as the employee’s own behavior.

Microsoft also says Intune policy for managing MXC process containers is coming soon. The broader Agent 365 controls for local agents are likewise described as forthcoming.

Those capabilities should be distinguished from the MXC availability announced today.

The intended governance model has three connected parts: contain the workload, identify the agent, and manage its access through organizational tools.

This extends beyond Microsoft’s own agents

Microsoft names a broad set of agents and frameworks already supporting MXC: OpenAI Codex, GitHub Copilot, OpenClaw, Replit, LM Studio, NVIDIA OpenShell, and Unsloth AI.

It says support is forthcoming from Anthropic Claude Code, Box, Egnyte, Heidi Health, Hermes Agent by Nous Research, Manus, Perplexity, Raycast, and Simular, among others.

Microsoft also says Muse for Windows, a personal AI agent from Meta, is coming soon as a native Windows application with MXC integration.

Existing support and announced future support are different milestones. Nor should support be taken to mean every product uses identical policies or containment options.

Even so, the breadth of the ecosystem is strategically significant.

Microsoft wants Windows to provide infrastructure for agents people choose, including products from other companies. That expands the operating system’s role even when Microsoft’s own assistant is not the application handling the task.

It also makes the quality of those platform controls consequential far beyond Copilot.

Copilot is getting local context, actions, and models

Microsoft’s own Copilot experience is part of the hybrid strategy.

The company says Copilot’s Home, Code, and Autopilot experiences will gain hybrid capabilities on Copilot+ PCs, with rollout expected to begin over the coming months.

Microsoft groups those capabilities into three areas.

Local context lets Copilot use relevant files on the PC with permission.

Local actions let it perform tasks on the machine, such as moving files, changing settings, or helping with troubleshooting.

Local models provide an option to delegate work onto the device when local execution or cost matters.

Home is intended to use local files to create useful working artifacts. Code is expected to gain local model support, MXC containment, and the ability to create native Windows applications from a prompt. Autopilot is expected to gain offline capabilities using local models and context.

The permissions and data flow matter here.

An agent running on a PC does not necessarily mean its model runs locally. An agent using local files may still use cloud inference if the user has consented.

Pradeep specifically discussed that distinction. Hybrid intelligence encompasses where tools run and where context resides, as well as where the model executes.

For users, the interface needs to make those choices understandable.

A new range of PCs supplies the compute

Microsoft’s hardware announcements cover several levels of local AI use.

At the smaller end, the company is introducing easier setup for popular agents on mini desktop PCs. OpenClaw is getting a native Windows gateway and MXC integration.

That could reduce the technical work required to establish an always-on agent machine.

For everyday laptops, Microsoft positions Copilot+ PCs as the broad platform for built-in AI experiences and forthcoming hybrid Copilot features. The company says these PCs collectively perform more than 2 trillion local inferences per month, and that more than 40% of laptops being built for business are Copilot+ PCs.

Those are Microsoft’s aggregate figures. They should not be interpreted as measures of how many people are running autonomous agents.

The more demanding category is Builder PCs, designed for developers, creators, and others working with larger local models and AI workloads.

The RTX Spark laptops opening for preorders include:

• ASUS ProArt P16 and P14
• Dell XPS 16 Creator Edition
• HP OmniBook Ultra 16
• Lenovo Yoga 9n 2-in-1
• MSI Prestige N16 Flip AI+
• Microsoft Surface Laptop Ultra

Microsoft says shipping begins October 16.

Surface Laptop Ultra offers up to 128GB of unified memory, a 15-inch touchscreen, and the ability to run models exceeding 120 billion parameters locally.

The Surface RTX Spark Dev Box also opens for preorders, with U.S. shipments scheduled for November 24.

Unified memory is central to the pitch because large models require substantial memory capacity. But buyers will still need to consider sustained performance, battery life, thermal behavior, software compatibility, and how well the machine handles their actual workloads.

Microsoft has not supplied a complete purchase-value equation in these briefing materials.

The benchmark claims are specific

Microsoft says tested RTX Spark Windows PCs delivered up to:

• 2.1 times faster time to first token
• 4.3 times faster AI image generation
• 6.2 times faster AI video generation

The comparison was against a 16-inch MacBook Pro with M5 Pro and 64GB of memory.

Those figures describe particular tests.

The first-token result came from Microsoft-commissioned testing using Qwen3.5 27B in llama.cpp with a fixed 8,192-token prompt. The image and video results came from NVIDIA testing using specified FLUX.2 Klein and LTX 2.3 configurations in ComfyUI.

The tested Windows systems were preproduction devices.

These results are useful evidence for the workloads measured. They do not establish that every application, model, or agent workflow will run several times faster.

Time to first token also measures something different from sustained generation speed or the time required to complete a project.

Independent testing will be particularly valuable once the machines ship.

DGX Station brings another scale of AI to Windows

At the top of the range, Microsoft is bringing Windows to systems powered by NVIDIA DGX Station and the GB300 Grace Blackwell Ultra Desktop Superchip.

The announcement describes systems with up to 748GB of coherent memory and 20 petaflops of FP4 AI compute, supporting models up to roughly 1 trillion parameters, according to its hardware footnote.

Microsoft identifies two uses.

One is a personal AI supercomputer for demanding engineering, research, and scientific workloads.

The other is a shared resource for teams, described as a Windows token factory supporting 32 or more simultaneous agents.

The named systems include the Dell Pro Precision with GB300 and HP ZGX Fury AI Station, expected later this year.

For an organization, that creates another deployment option: local inference on shared hardware managed within its own environment.

It may offer more control over sensitive data and reduce some cloud consumption. Whether it saves money depends on utilization, hardware cost, power, maintenance, and the workloads involved.

A heavily used shared system has a different economic case from an expensive machine that spends most of its time idle.

Local AI changes the cost structure. It still needs to justify its cost.

Search and gaming get changes, too

Microsoft is also introducing actions directly in Windows Search.

The examples include switching to dark mode, enabling Do Not Disturb, adjusting brightness, muting audio, arranging windows, and sending a message.

Microsoft says the actions begin rolling out to Windows Insiders in the experimental channel on October 7.

An optional Copilot integration will also bring quick answers into Search, with a path into the full application for longer conversations.

That creates an accessible entry point for the larger shift: users can express an outcome instead of navigating through settings or applications to produce it.

Gaming is another part of the RTX Spark announcement.

Microsoft highlights support for DirectX raytracing, variable rate shading, and DirectStorage, with Gears of War: E-Day showcasing the platform. It says expanded Advanced Shader Delivery support will reduce initial shader compilation time and help reduce stutter.

The company also says Call of Duty is coming to RTX Spark in 2027.

That matters because these are still personal computers. An AI workstation’s appeal improves if it can also handle the other things its owner wants to do.

The everyday examples make the vision more convincing

The most relatable example from the interviews involved school email.

Pradeep described his wife building an application that reads messages from their daughter’s school and creates a dashboard for curriculum information and important dates.

“So my wife built like an app, which just reads her e-mail and then creates a little dashboard and she gets all her information there,” he said.

That example helps explain the potential audience.

Many people will never identify as developers. They still have recurring information problems that software could solve: tracking school updates, organizing documents, preparing reports, or keeping a small business’s administrative work moving.

For them, the interesting question is whether the system completes the job at an acceptable cost and handles their information appropriately.

They may care much less about which accelerator processed the request.

Our earlier look at personal AI computers and local control explored this direction. The interviews add a clearer account of the engineering required to make it routine.

The opportunity is a computer that can support useful, recurring work without asking its owner to become an expert in model deployment.

What the PC does overnight is becoming a product question

When Pradeep asked what a computer does while its owner sleeps, he described an example of a local coding workload running overnight, such as converting a C library to Rust.

That should be understood as an illustration of a possible workflow, rather than a guarantee that an unattended migration will be correct.

But it gets at a meaningful change in how time can be used.

Some assignments do not need an immediate response. They can make progress while the owner is asleep, in a meeting, or away from the desk.

Local hardware could supply useful work during those periods, with cloud models contributing when the task requires them.

Pradeep also discussed the possibility of using other compute around a household. That was a future-looking conversation, not an announcement of a universal system that pools PCs and consoles into one agent platform.

Microsoft is building amid considerable uncertainty.

“But we're not designing anything out because it's hard to predict,” he said.

The October announcements establish several concrete pieces: generally available containment, upcoming local routing, optimized models, and hardware with shipping dates. Other parts remain previews or plans.

What will determine the value is how reliably those pieces work together.

Can the router choose well? Can the local model perform useful work? Can the agent operate within a sensible boundary? Can you inspect the result without supervising every step? Can the computer keep doing its background assignment while you use it?

Those are the tests that matter after the preorder page and benchmark chart.

Microsoft is making a substantial bet that the PC has more work ahead of it. The next reason to leave yours switched on may be an assignment you expect it to finish before morning.

Related reading

• Everything Microsoft announced at Build 2026 — The broader agent platform strategy that preceded these October announcements.
• The Personal AI Computer Will Move Agents From Cloud Tolls to Local Control — An earlier examination of the economics and implications of personal agent hardware.
• Your guide to running powerful AI models on your own laptop — Practical background for readers who want to understand local model execution.