Part 2 of 3: CPU economics for agentic AI
I spent a busy 48 hours in the Bay Area this week, moving from DigitalOcean’s Open Intelligence Summit to SEMICON West and OCP.
For investors and engineers, the payoff is deciding where the next dollar belongs: a better model or harness, memory, CPU capacity or networking. The answer starts with the actual bottleneck and the full cost of getting useful AI work finished correctly.
After DigitalOcean’s Open Intelligence Summit on October 13, I asked its team to walk me through the cost of 1,000 successfully completed agent tasks, including failures, retries, evaluation and tool calls.
I did not get a worked bill. The team explained how it wanted its Agent Droplet packages to deliver value and how customers could evaluate satisfactory results. Those answers were useful. They left the cost of the completed work unresolved.
Think of an agent as an assistant that can organize a small team. It plans, uses tools, checks results and tries the next step. Sometimes it delegates jobs that can run together. Each worker needs tools and working notes; some work while others wait, with those notes still available. NVIDIA’s explainer argues that efficient handoffs, reusing work and retained memory matter alongside faster chips. Our test is work finished correctly per dollar and per unit of electricity, within the customer’s response time. Extra workers must earn the resources they consume.
Our CPU thesis starts there: buy the resource that limits accepted work. Retained state may make memory capacity binding. Overlapping tests and tool runs may make execution capacity binding. Necessary transfers may make the connection binding. A processor earns a premium when it helps the same task mix meet the same acceptance rules and deadlines at a better full cost.
That favors provisioning for a demonstrated bottleneck over picking a winner from core counts, memory capacity or token prices alone. Our Part 1 view stands: we favor NVIDIA’s system approach for demanding agent workloads, and Daytona’s vendor-reported throughput lead over EPYC 9755 is a reason to test Vera. Part 1 promised the architecture comparison for this installment. No public, matched result yet runs the same agent work on Vera, Venice, Xeon and Arm under one acceptance standard, so we start with the bill that comparison will have to meet. Part 3 takes the architectures on directly.
Here’s what we’ll dig into
What does each accepted original task cost after failed attempts and retries?
Why can waiting agents keep billing, and when does retained state set capacity?
How do models, context, tools and human decisions change completion economics?
What does the acceleration example from Tim Costa, NVIDIA’s VP and GM of Industrial and Computational Engineering, establish about a validated engineering result?
When would Vera, competing CPUs and connectivity suppliers earn more spending?
Let's get into it...
