NVIDIA rebuilt its stack for agents. Here's what that means.

TL;DR: NVIDIA’s GTC Taipei keynote introduced a CPU built for agent orchestration, a kernel-level sandbox for agent security, and a $4M rack designed as an AI factory. The real story isn’t the hardware. It’s the declaration that agent compute needs a fundamentally different stack than human compute.

I tuned into Jensen Huang’s GTC Taipei keynote expecting faster GPUs. Every NVIDIA keynote delivers faster GPUs. It’s the law of gravity. Forbes called it “the age of agents.”

The first 15 minutes were about a CPU.

Not a faster CPU. A different kind of CPU. The Vera has 88 cores that NVIDIA designed from scratch. The Olympus core, ARM v9.2-compatible but not a licensed Neoverse design. And the reason Huang gave was not about FLOPS or memory bandwidth. It was about agents. “Billions of agents will run continuously,” he said. “They need lower latency than people do.”

That sentence stopped me. NVIDIA isn’t building faster versions of the same thing. It’s rebuilding the entire stack on the assumption that the dominant compute workload of the next decade isn’t chatbots answering questions. It’s agents running continuously, autonomously, across thousands of concurrent sessions.

Key takeaways:

• NVIDIA redesigned its keynote around agents, not GPUs. The Vera CPU, OpenShell, and Vera Rubin all target agent workloads specifically
• The Vera CPU with Spatial Multithreading is the first processor designed for agent-orchestration isolation, not general-purpose throughput
• OpenShell provides kernel-level sandboxing for long-running agents. It’s the first serious infrastructure answer to the agent security problem
• Vera Rubin claims 10x improvements across agent throughput, cost, and efficiency, but independent benchmarks haven’t replicated these numbers
• For developers today, OpenShell’s isolation patterns matter more than the hardware. They use Linux primitives available right now

Why would NVIDIA build a CPU for agents?

A single chat completion barely taxes a CPU. The prompt arrives, the GPU generates tokens, the response goes back. The CPU sits between calls doing almost nothing.

An agent is different.

Every turn of a long-running agent involves a sequence of CPU-bound operations: plan the next step, call a tool, receive the result, check the context window, decide whether to call another tool or produce a final response. Each step gates GPU utilisation. If the CPU is slow, the GPU waits.

This is the bottleneck NVIDIA identified. Not GPU throughput. CPU orchestration latency. In a multi-agent system with dozens of concurrent sessions, the CPU time compounds across every step of every agent loop. Huang’s framing was blunt: the processor market for agents barely exists today, and it’s about to be enormous.

What makes the Vera CPU different?

Three things, and only one of them is about speed.

First: the core design. Vera carries 88 Olympus cores, NVIDIA’s first in-house CPU core. It’s not a faster version of the Grace CPU’s Neoverse cores. It’s a ground-up design optimised for the control-heavy, data-movement-intensive work that agent orchestration generates. Planning, tool dispatch, sandbox concurrency, retrieval aggregation. Phoronix benchmarks place it approximately 11% faster than AMD EPYC and 55% faster than Intel Xeon in the geometric mean of curated workloads. AMD has pushed back, claiming its 256-core Zen 6 Venice will deliver 3.3x better rack-level performance.

Second: Spatial Multithreading. This is the genuinely novel idea. Traditional simultaneous multithreading (SMT) time-slices core resources between threads. SMT-X physically partitions them. In a multi-tenant AI factory running thousands of agent sandboxes on a single socket, isolation matters more than raw throughput. You don’t want one agent’s memory access pattern to degrade another agent’s latency. SMT-X guarantees that separation at the hardware level.

Third: the memory system. 1.2 TB/s of memory bandwidth and 1.5 TB of capacity per socket. This isn’t for loading models. The GPU handles that. It’s for the fast retrieval, cache, and state management that agents need across hundreds of concurrent turns. NVIDIA tuned the memory subsystem for the access pattern agents generate: many small, rapid reads rather than the large sequential reads of training workloads.

Kitchen analogy: The Vera CPU is the head chef at the pass. The head chef doesn’t cook. They orchestrate. They know what every station is doing, whether the garnish is ready, and whether the pass is clear for the next ticket. The GPU is the line cook. The line cook is fast, but only when the head chef keeps tickets coming. Vera makes sure the tickets never stop.

What does OpenShell fix about agent security?

NVIDIA buried the most important announcement in a developer blog post that most coverage missed.

OpenShell is an open-source runtime that sits between the agent and the infrastructure. It’s Apache 2.0, available now on GitHub, and it addresses the single biggest operational risk in long-running agents: the agent with root access. The NVIDIA developer blog lays out the threat model explicitly.

The problem isn’t theoretical. A stateless chatbot has almost no attack surface. An agent with persistent shell access, live credentials, the ability to rewrite its own tooling, and six hours of accumulated context running against your internal APIs is a different category of risk. Every prompt injection is a potential credential leak. Every third-party skill the agent installs is an unreviewed binary with filesystem access. Every subagent it spawns can inherit permissions it was never meant to have.

OpenShell solves this with three mechanisms:

Landlock LSM restricts which filesystem paths the sandbox can read or write, enforced at the kernel level. The agent can’t escape even if the model hallucinates a command that tries.

Seccomp BPF filters the system calls the agent can make. The agent can call open(), read(), and write() on permitted paths. It can’t call mount(), reboot(), or ptrace().

Network namespace isolation creates a separate network stack per sandbox. The agent can reach only the endpoints you define. No lateral movement inside your infrastructure.

The key design choice is out-of-process enforcement. The security policy lives outside the model’s process. The agent can’t override it, rewrite it, or talk its way around it, because the agent doesn’t control the process that enforces it.

NVIDIA’s developer blog makes the tradeoff explicit:

“If safe and autonomous but without access to the tools and data it needs, the agent can’t finish the job. If capable and safe but gated on constant approvals, you’re babysitting it. If capable and autonomous with full access, you have a long-running process policing itself — guardrails living inside the same process they’re supposed to be guarding.”

NemoClaw wraps OpenShell around OpenClaw in a single command: openshell sandbox create --remote spark --from openclaw. Any coding agent, from Claude Code to Codex to Hermes, can run unmodified inside the sandbox.

Isolation layer	What it stops	Linux primitive
Filesystem	Writes to /etc, /home, ~/.ssh	Landlock LSM
System calls	mount, reboot, ptrace, kernel modules	Seccomp BPF
Network	Lateral movement, data exfiltration	Network namespaces
Credentials	Access to host secrets	Out-of-process policy engine

What is Vera Rubin and who is it for?

Vera Rubin is the full platform. The rack that packages Vera CPUs, Rubin GPUs, NVLink gen-6 switching, and Spectrum-X photonic networking into a single system that NVIDIA treats as one computer.

The specs are impressive on paper. 3,600 PFLOPS NVFP4 inference per NVL72 rack. 20.7 TB of HBM4 memory. Cable-free, liquid-cooled design with five-minute assembly per compute tray. $3.5 to 4 million per rack based on industry estimates.

NVIDIA claims 10x agent throughput, 10x lower cost per token, and 10x better power efficiency versus the Grace Blackwell generation at pod scale. The official press release frames it as “the most extensive POD-scale platform” NVIDIA has built. These numbers trace to NVIDIA’s own benchmarks and haven’t been independently replicated. They’re directional, not verified.

The supply chain story is worth noting separately. Vera Rubin involves 150 partners in Taiwan and more than 350 factories across 30 countries. NVIDIA says the supply chain is twice the size of the Grace Blackwell effort. First shipments begin fall 2026. Cloud providers CoreWeave, Lambda, and Oracle Cloud Infrastructure are among the early adopters.

Who is this not for?

If you run single-turn chatbots or batch inference workloads, none of this changes what you build today. The GPU improvements eventually reach every tier. But the architectural thesis targets a workload that most production systems don’t yet have: CPUs redesigned for agent orchestration, secure runtimes for agent sandboxes, and networking built for agent-scale coordination.

If you deploy long-running agents that make tool calls, access data, spawn sub-agents, and persist across sessions, the security architecture matters now. OpenShell uses Linux primitives you can deploy on any infrastructure. The isolation patterns don’t require NVIDIA hardware.

The 10x performance claims should be treated with healthy skepticism until independent benchmarks replicate them. AMD isn’t staying still. The Vera CPU benchmarks were run on NVIDIA-curated workloads that excluded general-purpose and legacy applications. The real comparison begins when these systems ship and the community tests them on real agent workloads.

Tradeoff: NVIDIA’s announcements are strategically important and practically irrelevant at the same time. The architectural direction tells you where the industry is heading. The products themselves ship in fall 2026. What you do today with agent security and isolation. Those decisions are immediately useful and don’t require any hardware from NVIDIA.

What should you do about it?

Three things, in order of immediacy.

First, understand the agent loop bottleneck. The insight that agent workloads are CPU-bound in ways that chat workloads aren’t is true regardless of whose hardware you use. Profile your agent pipelines. If the GPU is waiting on the CPU between turns, you have hit this bottleneck. The fix isn’t necessarily a new CPU. Batch parallelism, async tool calls, and context caching can help today.

Second, evaluate OpenShell’s isolation model. The Landlock-seccomp-namespace pattern isn’t NVIDIA-specific. If you run agents that have filesystem access, network access, or credential exposure, apply the same principle: out-of-process policy enforcement, not in-loop guardrails that the agent can talk its way around.

Third, watch the fall 2026 timeline. When Vera Rubin ships and independent benchmarks land, the real assessment begins. Until then, NVIDIA’s GTC Taipei keynote is most valuable as a signal of where the industry is heading, not a procurement recommendation.

FAQ

What is the Vera CPU and why is it different? The Vera CPU is NVIDIA’s first in-house data center processor, built with 88 custom Olympus cores. It’s designed specifically for agent orchestration: planning, tool dispatch, sandbox concurrency rather than general-purpose server workloads. Its key innovation is Spatial Multithreading (SMT-X), which partitions core resources between threads at a physical level instead of time-slicing, providing strong isolation for multi-tenant agent deployments.

What is OpenShell and how does it secure AI agents? OpenShell is an open-source secure runtime (Apache 2.0) that sits between the agent and the infrastructure. It uses Landlock LSM for filesystem access control, seccomp BPF for system call filtering, and network namespace isolation to prevent long-running agents from accessing resources beyond their defined permissions. It addresses the threat model where an agent with persistent shell access, live credentials, and the ability to rewrite its own tooling operates unsupervised.

Does Vera Rubin actually deliver 10x better performance? NVIDIA claims 10x agent throughput, 10x lower cost per token, and 10x better power efficiency versus the Grace Blackwell generation. These are vendor-stated and not independently replicated. Phoronix benchmarks on the Vera CPU show it approximately 11% faster than AMD EPYC in curated workloads. AMD has challenged the methodology, claiming its 256-core Zen 6 Venice will beat Vera 3.3x at rack level.

How does this affect developers building agents today? The most immediately useful piece is OpenShell’s security approach. The problem of long-running agents with broad system access is the same whether you deploy on NVIDIA hardware or a laptop. The isolation patterns — Landlock, seccomp, network namespaces — are Linux primitives you can use today. Vera Rubin availability is fall 2026, so hardware decisions should not be gated on it.

Who should care about these announcements? If you deploy long-running agents in production — agents that call tools, access data, spawn sub-agents, or persist across sessions — the security architecture matters now. If you run batch inference or single-turn chatbots, the GPU improvements are relevant but the architectural thesis doesn’t change what you build today.

Related Posts

• AI agent cost optimization tips. Practical cost strategies that matter more than hardware announcements for most teams.
• Model-agnostic agents: when the same architecture works across 7 providers. How to build agents that aren’t locked to a single hardware stack.
• Loop engineering: production agent loop patterns. The 8 canonical patterns for agent orchestration. Vera CPU is the argument that these patterns deserve dedicated hardware.

---

This article was published on Agentic Up (https://agenticup.dev): practical guides for developers and founders building with AI agents. Reach me at [email protected]