Nobody Has Defined "Faster" Yet
Every silicon vendor at every keynote this year has said some version of the same sentence: the next CPU generation will be built for agentic workloads. Intel talked about CPUs as the orchestration layer for agentic systems, Arm argued that agents are driving a fresh wave of data centre CPU demand, and NVIDIA introduced Vera as a CPU designed for agentic workflows rather than general-purpose compute. The direction is settled. The definition is not.
Because here is the question nobody on those stages answered: faster at what, measured how?
That is not a rhetorical jab. It is the central unsolved problem of the next design cycle, and it is a benchmarking problem before it is a silicon problem.
The old yardsticks don't describe the new work

SPEC CPU is a magnificent instrument for what it measures. SPECrate tells you how many independent copies of a compute kernel a socket can sustain. SPECspeed tells you how fast one runs. Neither describes an agent fleet, where a thousand mostly-blocked control loops wake on an I/O completion, execute a short burst of branchy interpreted code, spawn a sandbox, serialise a payload, and go back to sleep. Utilisation looks low. Latency is terrible. Both facts are true simultaneously and neither shows up in a rate score.
Token throughput doesn't help either. It measures the one step in the agent loop that isn't running on the CPU.
So the industry is about to spend a design generation optimising for a workload it has not yet characterised. That gap is where the interesting work lives.
What agentic code actually looks like to a core

Strip away the AI framing and the orchestration tier is a specific and unfashionable microarchitectural profile:
Front-end bound, badly. Interpreted runtimes, JIT'd code, deep framework stacks, container runtimes. Enormous instruction footprints that blow out the i-cache and iTLB, with branch behaviour that defeats predictors trained on loops. This is the opposite of an HPC kernel, and it is very close to the profile of a web browser, which is why correlated micros derived from browser workloads turn out to be far more relevant to agentic orchestration than anything in a traditional server suite.
Latency-bound, not bandwidth-bound. The STREAM number is not the constraint. Pointer chasing through object graphs, dependent loads, and cross-socket traffic are.
Syscall and context-switch heavy. Every tool call crosses a boundary. Wake-up to first useful instruction becomes a first-class metric, and it appears in no standard benchmark.
Virtualisation-taxed. If every tool invocation lands in a microVM or container, you are paying cold-start cost, stage-2 page walks, and TLB shootdowns thousands of times a second.
Concurrency-pathological. Arm estimates demand moving from about 30 million CPU cores per gigawatt to 120 million in the agent era. Core counts at that scale mean NUMA domains, scheduler pressure, and lock contention become the performance story, not an asterisk on it.
Every one of those is measurable. None of them is currently measured in a way a CPU architect can act on.
From benchmarking to co-design

This is where our discipline changes character, and where we think the value of the work we've been doing for years compounds.
Running a benchmark suite and reporting a number is a service. It is useful, it is honest work, and it is increasingly commoditised. What the agentic era demands is a level above that, and it has three rungs.
Characterisation. Take the real workload and describe it microarchitecturally: top-down analysis, cache and TLB behaviour, memory-level parallelism, where the stalls are and what causes them. We've done this for MLPerf-class inference workloads across vision, language and speech models, and for memory subsystems down to the firmware layer where a missing interconnect node quietly invalidates every bandwidth measurement you thought you had.
Correlation. Real workloads are enormous, non-deterministic, non-portable, and impossible to run in a pre-silicon simulator. Architects designing a 2029 part need small, deterministic kernels that provoke the same microarchitectural behaviour as the real thing. Building those correlated microbenchmarks — and proving the correlation holds — is a specialist craft with a tiny population of practitioners worldwide. It is also the only mechanism by which workload knowledge actually reaches silicon.
Co-design. Once the micros exist, they become the shared language between the people who write agent frameworks and the people who lay out cores. Should the front-end prefetcher be tuned for this instruction footprint? Does this workload justify more TLB entries over more cache? Where does an accelerator for serialisation or sandbox entry pay for itself? Those questions are unanswerable without the first two rungs.
Why the timing matters
Silicon designed today ships in three to four years. Vendors are making agentic-era microarchitecture decisions right now, on the basis of workload evidence that largely does not exist yet. The window for influencing those decisions is open and narrow.
That is the work Whileone is set up for. Microarchitectural performance engineering across Arm, x86 and RISC-V. Correlated microbenchmark construction. Compiler-level tuning against real ISA extensions, including the profile-guided and layout optimisations that huge-instruction-footprint code actually responds to. CPU-only inference stacks built and validated on aarch64. Memory subsystem diagnostics that go past the counter and into the firmware. Workload characterisation is framed so the result is a design input rather than a slide.
For most of the last decade that portfolio described a niche. The niche is now the main road.
Everyone agrees CPUs should be faster for agentic workloads. Somebody has to define the workload first. We'd like that to be us.





Comments