The agentic stack that finally runs where your users are
For two years the running joke inside agent shops was that "production-ready AI agents" meant a polished demo video and a Notion roadmap. Microsoft and Nvidia just compressed that gap at Microsoft Build 2026, held June 1-3, with a unified accelerated computing stack that lets developers build, run, and scale agents across Windows devices, Azure cloud, and local setups — on one toolchain. That part is genuinely impressive. One stack, three deployment targets, no rewrite.
The pain this addresses is concrete. An "agentic app" usually means an LLM call wrapped in a thin orchestrator, hosted in one cloud region, talking to a UI that was rebuilt three times because the agent's tool surface kept changing. Every model upgrade broke an integration. Every time the team wanted to run locally for latency or data-residency reasons, the inference path was rewritten. The new Microsoft-Nvidia stack is an explicit attempt to standardize that path so the agent — not the plumbing — is the unit of work.
The collaboration reportedly spans three years of GPU-acceleration work between the two companies. The scope this week is what shifted: from co-marketing individual GPUs to co-shipping a vertical stack with named hardware, named runtimes, and named developer surfaces.
What the unified stack actually is
It is a three-layer agreement. Hardware acceleration on Nvidia RTX-class silicon. A security and runtime layer — Nvidia OpenShell and Microsoft's MXC eXecution Containers — that sandboxes agents. And developer wiring through GitHub Copilot, Microsoft Foundry, and GPU-accelerated Microsoft Fabric. The piece worth calling out is that all three layers shipped under one announcement, demoed together on the same keynote stage with both Jensen Huang and Satya Nadella present. Co-marketing is cheap. Co-shipping a stack that targets Windows, Azure, and local from one SDK is not.
[[DIAGRAM: RTX Spark and DGX Station hardware at the bottom; OpenShell and MXC runtime isolating the agent in the middle; Foundry Agent Service, GitHub Copilot authoring, and GPU-accelerated Fabric as the developer surface on top; user-facing apps on Windows, Azure, and local as the outer ring]]
Hardware: RTX Spark and DGX Station
The RTX Spark lineup is the headline. A new generation of laptops and desktops that deliver 2x faster agentic inference on Windows. For most agentic workflows — sub-second tool calls, JSON validation, retrieval over a small knowledge base — that tier is enough. RTX Spark is also the signal worth watching: Nvidia is now marketing a discrete "agentic inference" SKU, which means the hardware vendor has accepted agent workloads as a category worth optimizing for. That is a real tailwind for builders betting on local-first agents.
The DGX Station for Windows is the upper branch. It supports AI models with up to 1 trillion parameters and offers up to 1 petaflop of AI computing power, which the source piece notes was "reserved for national labs not long ago." That is the box you reach for when the agent has to reason over a long context window or run a frontier model locally for compliance reasons. A workstation that hits a petaflop and holds a trillion-parameter model in memory is not a toy — it changes which workloads are worth shipping on-prem.
The honest read on the 2x number: it is meaningful but not generational. What is generational is that Nvidia is segmenting agent inference as a workload at all. Until this announcement, agentic workloads were a footnote inside "AI inference." Now they get their own box on the spec sheet.
Runtime: OpenShell and MXC
Agent security is the part most stacks quietly punt on. Run an agent with tool access and you have handed an LLM a shell. OpenShell is Nvidia's secure runtime for AI agents; MXC, Microsoft's eXecution Containers, provides sandboxing. Together they create isolated environments where an agent can read files, call tools, and write outputs without compromising the host. This is the slice of the announcement that enterprise security teams will care about most, because it gives them a named boundary to audit instead of "the agent runs in a container, trust us."
The honest read: this is real progress. It is not a complete answer to prompt injection or exfiltration — no sandbox is. But it is the first time a vendor stack ships a named security boundary specifically for agentic workloads rather than bolting containers on as an afterthought.
Developer wiring: Copilot, Foundry, Fabric
Three integrations matter. GitHub Copilot integration makes agent authoring a first-class IDE action — the developer writes the agent next to the code it will call. Microsoft Foundry Agent Service, first introduced at GTC 2026 and now reaching general availability per the article, is the deployment surface: the layer that turns a Copilot-shaped prototype into a managed agent you can hit from production traffic. GPU-accelerated Microsoft Fabric targets the data side — the pipelines that feed agents context without bottlenecking on ETL. The three-year collaboration shows here. This is the layer with the most iteration under the hood.
How to actually use this today
The how-to depends on which layer you are touching. Below is the shape of the loop, with the exact SDK names and method shapes left to verify against current docs at ship time.
Local agentic inference on RTX-class hardware:
# confirm the hardware tier
nvidia-smi
# any existing agent harness (LangGraph, CrewAI, hand-rolled) will pick up
# the 2x agentic-inference speedup automatically on RTX Spark silicon.
Authoring an agent:
<!-- .github/copilot-instructions.md -->
When the user asks for a refund status, call the `get_refund` tool and
return the formatted response. Do not invent order IDs. If the tool
errors, surface the message verbatim.
Deploying through Foundry Agent Service (now GA):
// ILLUSTRATIVE — verify exact import path and method shape against the
// current Foundry Agent Service docs before shipping.
import { FoundryAgentClient } from "@azure/ai-agents";
const agent = await client.agents.create({
name: "refund-triage",
model: "gpt-5", // replace with the current Foundry-supported model
instructions: "Triage refund requests and route to the right queue.",
tools: [/* your tool definitions */],
});
Isolating the agent with MXC:
# ILLUSTRATIVE — confirm flag set against the current MXC reference.
mxctl build --manifest ./agent.mxc.yaml --tag refund-triage:0.1
mxctl run --isolate fs=ro,net=deny -- refund-triage:0.1
That is the loop. Author in Copilot, deploy via Foundry, isolate with MXC, accelerate on RTX Spark or DGX Station. The layers compose, which is the entire point of shipping them as a stack rather than as four separate blog posts.
What this enables
Three things become plausible that were awkward before. First, latency-sensitive agentic UX — real-time copilots in IDEs, in-product assistants that respond fast enough to feel native without a cloud hop every turn. Second, data-residency-constrained deployments where the model and the agent both have to stay on-device for regulated industries. Third, an actual production CI loop for agents, where Foundry Agent Service general availability means a versioned, observable, rollback-able agent rather than a script in a Lambda.
Where this leaves the UI surface
Agents ship inside apps. Every time the agent infrastructure layer shifts — new SDK, new sandbox model, new inference vendor — the UI surface that hosts the agent is the part that should not churn. That is the durable layer. The same chat panel, the same tool-call card, the same streaming response renderer, the same offline fallback, the same accessibility tree — on web, iOS, and Android — invoked by a thin call into whichever agent runtime shipped this quarter.
The OTF pitch is not "skip the new stack." Use it. Ship agents on RTX Spark. Isolate them with MXC. Deploy them through Foundry Agent Service. Then host them in a UI that is the same on every platform your users actually touch — web, iOS, Android — without rewriting the chat surface every time the inference vendor rotates. The agentic stack is the churn layer, and the cross-platform UI is the foundation underneath it. Build on the new stack, and stop rebuilding the app shell with it.
The Microsoft-Nvidia announcement is good news for builders who have been waiting for agent infrastructure to grow up. Use it today. The UI layer you put it behind is the part that decides whether the next stack rotation costs you a sprint or an afternoon.
Top comments (0)