Arm introduces CPU benchmarks for AI agents, claiming nearly 2x work per rack

Arm introduced a CPU evaluation methodology for AI agents on October 13, 2026, with support from Fujitsu, Meta and OpenAI. Its aim is to measure how well processors sustain the work behind an agent’s actions—not just their theoretical capacity—and check whether component-level gains translate into better results for a completed task.

Arm describes an agent as a virtual user with a persistent computing environment. It retains information, retrieves context, calls tools and services, executes work and evaluates the results until a task is finished. Those activities place demands on the CPU, or central processing unit, alongside memory, storage and the connections that move data through a system.

The CPU also helps coordinate work. At the AI head node, which schedules tasks, it prepares and moves data so accelerators can stay busy. When an agent searches, runs code or calls a service, it adds work for the cloud infrastructure beneath it. Arm says that activity adds to demand rather than replacing it.

That makes sustained performance central to Arm’s approach: how much work can run at once while the system remains responsive. The methodology has three parts:

• Representative agent use cases: evaluate the kinds of work agents perform, rather than rely on a measure of theoretical processor capacity.
• Repeatable CPU measurements: isolate processor performance from other variables, including model inference—the work of running a model—and networking.
• End-to-end validation: check whether improvements in those individual measurements produce better outcomes when the complete task is evaluated.

Alongside the methodology, Arm published results for its AGI CPU against AMD EPYC Turin processors. Arm says Signal65 independently verified the results using the same benchmark scripts on both platforms. The tests covered tool use, orchestration—the coordination of agent workflows—and reasoning and planning. Measured server-level performance then supplied the basis for rack-level modeling.

The headline result is an average 1.99x modeled performance per rack against AMD EPYC 9755 across seven workloads. Arm attributes that advantage to higher compute density and power efficiency. It is a rack-capacity estimate built from server measurements, not a directly measured result from running two complete racks side by side.

1.7xTooling

For workloads using agent tools, Arm’s model shows this average rack-level performance advantage.

2.0xWorkflows and orchestration

The model also shows this average advantage for agentic workflows and their coordination.

2.2xReasoning and planning

For reasoning and planning workloads, Arm’s model shows this average rack-level advantage.

A separate result addresses how quickly agents can begin executing work. Arm reports up to 45% lower sandbox creation latency against AMD EPYC 9965. A sandbox is an isolated execution environment; creating it faster reduces startup overhead for agent operations. This comparison uses a different AMD processor from the seven-workload rack average.

Arm emphasizes racks because data centers face fixed limits on power, heat and space. Operators need to know how much useful work can fit within those limits as more tasks run at once. Arm says it designed its AGI CPU with many cores per chip, dedicated memory for each core and fast data connections to support sustained work.

The supporting companies focused on how to measure performance, not on a specific result. Fujitsu’s Toshio Yoshida called for evaluation that is transparent, reproducible and representative. Meta software engineer Abhishek Dhanotia said a more consistent basis for comparison could show how different workloads use the underlying infrastructure. Their comments support the benchmarking effort but do not independently confirm Arm’s reported advantage.

OpenAI’s Colin Jarvis likewise highlighted orchestration and tool execution as areas requiring industry collaboration on representative benchmarks. Arm acknowledges that the methodology will need to evolve as agent architectures and software change. The framework therefore sets out a way to evaluate emerging workloads, rather than treating today’s tests as a permanent definition of agent performance.