NVIDIA Built a PC for AI Agents. The Agents Can't Run on It Yet.
NVIDIA's RTX Spark promises a full permission sandbox for autonomous AI agents. Weeks before launch, pre-production units can't finish basic CUDA jobs.
NVIDIA wants to sell you a PC built for AI agents that work while you're not looking.
The pitch is specific: a chip that runs a 120-billion-parameter model locally, with a million-token context window, no cloud round trip, no data leaving the machine. On top of it, a security framework called OpenShell that sandboxes what an autonomous agent can touch on your primary computer — files, processes, network calls, all gated by policy.
That's RTX Spark. It's a real product, from a real company, with real OEM partners lined up. And this week, the first hands-on numbers leaked. The CUDA workloads didn't finish.
NVIDIA Bet the PC on AI Agents
RTX Spark isn't a graphics card. It's a full system-on-chip — a Blackwell GPU, a 20-core Arm CPU, up to 128GB of unified memory, built on a 3nm process. Microsoft, Dell, HP, Lenovo, and Asus all have laptops and desktops built around it, shipping this fall.
The framing NVIDIA is using is not "faster PC." It's "a teammate that runs in the background." An agent that keeps working on your machine after you close the laptop lid, the same category of thing I've been writing about since Claude Code Routines started running my PRs overnight. NVIDIA is betting the entire next generation of Windows hardware on that use case becoming normal.
I want that future. I run agents unattended already — n8n workflows on my own server, scheduled routines that touch real repos while I sleep. The idea of that running locally, on a chip built for exactly this, should be an easy yes for me.
It's not, yet. And the reason why is the part nobody's marketing deck is showing you.
The Permission Framework Nobody Asked to Trust Yet
OpenShell is the piece that's supposed to make unattended agents on your primary PC safe. Kernel-level isolation for filesystem, network, and process access. A YAML policy engine that lets you say exactly what a given agent binary can touch, down to the destination and method. Built on Windows security primitives Microsoft shipped specifically for this.
On paper, that's the right design. Permissions should live below the model, not inside the prompt. I'd rather trust a kernel boundary than trust an agent to just behave because I asked it nicely in the system prompt.
But a permission framework is only as trustworthy as the thing it's fencing in. And that's where RTX Spark runs into a problem that has nothing to do with security policy.
The Chip Can't Run CUDA Yet
A pre-production Surface Laptop Ultra with the top-tier RTX Spark N1X configuration turned up in a reviewer's hands weeks ahead of NVIDIA's own launch. Full specs: 20-core Arm CPU, 6,144 CUDA cores, 24GB of unified memory.
The CUDA workloads in the test suite didn't complete. Not "ran slow" — didn't finish. A newer developer driver with CUDA 13.4 support didn't fully fix it either. GPU clock rates fluctuated between 1.5 and 2.3 GHz mid-game. Stuttering showed up in workloads that had nothing to do with AI at all.
As of September 3rd, NVIDIA still hasn't published final pricing, a confirmed retail date, or a single independently verified benchmark. Shipping is now pointing at October. That's a chip being marketed as the foundation for autonomous agents on your PC, and the layer underneath the agent — the compute itself — is the part that isn't reliable yet.
I've shipped enough half-baked infrastructure to know what that combination means in practice: the permission system will get all the attention in the launch keynote, and the actual failure mode will be the runtime underneath it quietly falling over.
Reviewers found the unit on the side of the road, not in a briefing NVIDIA scheduled. That's not how you'd choose to introduce your flagship agent chip to the world. It's how the world found out anyway.
The Uncomfortable Part
Here's the take that's going to sound harsh: OpenShell is solving a problem NVIDIA doesn't have yet.
Building an elaborate trust and permission framework for autonomous agents is the fun part. It's demoable. It's the slide that gets applause. What's not demoable is "our CUDA driver crashes on the exact workload we're telling you to trust an agent with." So that part gets a footnote, and the permission architecture gets the keynote.
I've watched this pattern before, just at smaller scale. I've had client automations where the access control was airtight — scoped API keys, least-privilege everything — while the underlying job itself failed silently three times a week because nobody stress-tested the actual execution path. Permissions were never the risk. Reliability was.
Nobody buying an RTX Spark machine this October is going to read a policy YAML file and feel safe running an agent unattended. They're going to feel safe once the thing has run correctly a hundred times in a row without them checking on it. That's not a security property. That's an uptime property, and right now, this hardware doesn't have it.
What Actually Makes Background Agents Trustworthy
I run agents I don't watch. Not because I trust a permission file — because I've watched them succeed on the same job, unattended, enough times that I stopped checking every run. That trust was earned by Claude Code Routines running clean overnight for weeks, not by a config that promises good behavior on paper.
Sandboxing still matters. I'm not arguing against OpenShell's design — the isolation model is closer to how agent access inside a firewall should actually work than most vendors bother with. But sandboxing is the seatbelt, not the engine. A perfectly scoped permission policy around a GPU that can't finish a CUDA job doesn't produce a trustworthy agent. It produces a well-fenced failure.
The order matters. Make the execution boring and repeatable first. Layer the permission model on top of that once it's actually true. Ship them in the reverse order and you get exactly what leaked this week: an impressive policy engine wrapped around silicon that can't yet do the job it's being sold for.
Wait for the Reviews, Not the Keynote
RTX Spark might be genuinely great hardware by the time it ships. Pre-production engineering samples fail things that final silicon and shipping drivers fix all the time. That's not the point.
The point is what gets marketed first. Every AI hardware launch this year is leading with the trust layer — the permissions, the sandboxing, the "safe by design" language — because that's what makes buyers comfortable handing an agent the keys. But trust isn't a feature you ship. It's a track record you build after the thing underneath it actually works.
I'll believe RTX Spark is ready for unattended agents the same way I believe any of my own automations are ready: after it's run the job correctly a hundred times without me watching, not after I've read the policy file promising it will.
Don't buy the permission model. Buy the uptime, once someone's actually measured it.
