AMD Series · Part 2 of 3
The industry conversation is moving from AI models to AI systems, and what gets measured is moving with it, from a single inference request to a complete workflow that includes reasoning, retrieval, orchestration, tool execution, memory, and security. Agentic AI, in which software agents plan and carry out tasks on their own, is driving that change.
We think agentic AI gives AMD's years of data center investment a broader use. It brings the CPU and the front-end network into the workflow alongside the GPU and its scale-up and scale-out fabrics, and it calls for more than one CPU profile: hosts for the accelerators, sandboxes for agent tools, and the general-purpose servers that run the enterprise systems agents call into. AMD's portfolio spans those roles, and it offers customers a choice between integrated designs developed with partners and individual components for systems they build themselves.
This paper makes four arguments. First, agentic AI changes the IT operating model. Enterprises designed their systems to support employees, processes, and applications, and they now have to support software agents that generate additional model calls and execute work across those same systems. Sustained growth beyond existing capacity creates demand for more infrastructure. Second, the infrastructure requirement is a system. Agent workflows span CPUs, GPUs, DPUs, networking, memory, and software, and their economics depend on utilization and execution across all of them. Third, AMD's portfolio maps to the workflow. EPYC serves the host, sandbox, and general-purpose roles; Instinct serves inference and training; Pensando supports networking and infrastructure services; and Helios brings compute and networking together in a rack design for model workloads, with separate execution and application servers completing the wider deployment. [1] Fourth, the metric customers use is changing. Token speed is still part of it, but buyers will increasingly judge systems on how quickly they turn tokens into completed business actions, measured through tokens per watt, agents per watt, utilization, and total cost per business outcome.
1. Agentic AI changes the IT operating model
A chatbot answers a question. An agent is given a task and is expected to finish it, and that difference changes what infrastructure an enterprise has to build. When an enterprise deploys a chatbot, the operational question is how quickly and how well the model responds. When it deploys agents, the question becomes whether the system can execute. An agent given a task will plan, call one or more models, retrieve enterprise data, run code, query databases, invoke APIs, check policies, and often spawn sub-agents for subtasks, and each of those steps touches infrastructure that a single inference request never would.
An enterprise designs its IT systems around its employees, its processes, and its applications. Agentic AI adds software that can use those systems repeatedly within a single task. An agent working a prospect list may query the CRM, gather information, draft a response, and update a record, which creates inference demand as well as work for the general-purpose servers behind the applications. The purchases that follow depend on how much of that activity becomes sustained work and how much existing capacity can absorb.
The pattern repeats across the enterprise. In sales and customer workflows, an agent researches a prospect, retrieves account context, updates the CRM, drafts a follow-up, and schedules the next action, and most of the value comes from coordinating work across data, applications, and APIs, with the email itself the smallest part. In IT operations, agents interpret requests or incidents, query knowledge bases and databases, invoke applications, carry out permitted actions, verify outcomes, and maintain the controls and audit trail that production environments require, which makes orchestration, tool execution, policy enforcement, and compliance full parts of the AI workload. In software development and testing, agents move beyond writing code to interpreting test specifications, operating software and browsers, running tests, and feeding results into CI/CD pipelines; AMD Enterprise AI includes an agentic testing blueprint built around this multi-step execution model. In finance and back-office processes, agents retrieve documents and enterprise data, perform calculations, work with business applications, apply permission and approval policies, and validate results.
The model call is one step among many in every one of these workflows. The GPU remains essential, but cost and speed also depend on orchestration, general-purpose compute, front-end services, networking, and memory movement. Our thesis is that inference becomes the main recurring AI workload as agents make repeated use of models in production, and that the infrastructure around the model grows with it.
2. From AI models to AI systems
AMD has argued for some time that the future of AI would depend on the entire infrastructure stack. Agentic AI makes that systems view more relevant, and it favors open, heterogeneous architectures in which CPUs, GPUs, networking, memory, and software work as one compute fabric. AMD describes itself as a full-stack AI solutions provider, and the portfolio supports the description (Exhibit 2).
Exhibit 2: AMD's portfolio mapped to the agentic deployment
| Portfolio element | Role in an agentic deployment |
|---|---|
| EPYC CPUs | Every CPU role the deployment needs: host nodes feeding GPUs, sandboxes running agent code, and the general-purpose servers behind enterprise applications |
| Instinct GPUs | The acceleration layer, with the memory capacity and bandwidth enterprises need to serve models and retain context for active sessions |
| Pensando DPUs | A programmable services layer for the front-end network, offloading security, load balancing, and storage services from CPUs |
| Networking | Ultra Accelerator Link over Ethernet (UALoE) for scale-up inside the rack; Pollara 400 and Vulcano 800 AI NICs for scale-out across the cluster |
| Helios | A partner rack design combining compute and networking for large-scale training and inference; the wider agent workflow also uses servers and services outside that rack [1] |
| Open software | ROCm plus support for familiar frameworks and serving tools, helping customers deploy supported workloads across cloud, on-premises, and hybrid environments |
Source: AMD product documentation [1, 3, 4, 6]; Creative Strategies.
AMD pairs that breadth with a merchant CPU portfolio serving all three CPU roles and an ecosystem of system and software partners. We take each layer in turn and then tie them to the economics that decide agentic deployments.
3. The CPU foundation: host, agent sandbox, and general purpose
Agentic AI expands the CPU work around model serving. CPUs host accelerators, execute tools, and run the enterprise systems agents call. We describe those as three workload roles, which do not necessarily map to three separate CPU architectures or to a fixed number of servers.
Host CPUs feed and coordinate accelerators. Per-core performance, memory, and I/O become the constraint whenever request handling or input preparation limits GPU output, and the serving software must also be able to use the CPU capacity that is available. [2]
Agent sandbox CPUs run tools and code in controlled environments. More cores help when many independent jobs are ready to run, while faster cores shorten dependent steps such as a build or a test, and memory, isolation, and scheduling determine how much of that capacity is usable. An agent waiting on a remote service need not occupy a physical core, and a demanding tool may use several, so thread count is not a count of productive agents. [2]
General-purpose CPUs run the systems agents call into: databases, ERP, CRM, web services, and the rest of the enterprise estate. Persistent enterprise tool execution, such as database calls, happens on these servers, and agentic traffic adds load to systems that were sized for people.
AMD's EPYC portfolio offers performance and density choices for this mix of work. The 6th Gen EPYC family reaches up to 256 cores and 512 hardware threads, but those specifications describe execution resources rather than a guaranteed agent count. Customers need to match core performance, memory capacity and bandwidth, and the power setting to the work each pool runs. [3]
Core speed is not only a host question. A tool result on the critical path holds up the next step of an agent's task, so faster execution can improve completion time even when parallel capacity is plentiful. Many independent tasks, by contrast, benefit from more workers, provided memory keeps pace. This is the wide-versus-fast question, many slower cores against fewer fast ones, and Exhibit 4 shows how two configurations with the same aggregate capacity can produce materially different response times under a burst of work. Both requirements often show up in the same pool, so we would measure the complete tool operation under load instead of picking one CPU metric for every sandbox. [2]
EPYC also brings an established enterprise software environment and a broad OEM base. Agents will call databases and business services that already run on x86 servers, which lets companies keep their existing applications and much of their operating practice. Extending that environment to new execution pools can reduce the work of adoption, although new deployments still need their own capacity and security planning.
4. Instinct GPUs and enterprise inference
The GPU still generates the tokens. AMD's Instinct MI350 series (MI355X, MI350X, and MI350P) and the MI450 series, led by the MI455X, carry the company's acceleration roadmap into the agentic era. What changes with agentic AI is what enterprises need from the accelerator.
Enterprise agentic workloads rarely look like one very large model serving one very large queue. They look more like fleets of specialized models: small language models tuned to a task, retrieval models, safety models, and an occasional frontier-class model for difficult reasoning steps. Serving that mix efficiently rewards two things AMD has prioritized, memory capacity and flexible partitioning.
Instinct's chiplet package integrates compute dies, I/O, and high-bandwidth memory. The MI350X and MI355X, for example, combine 288 GB of HBM3E with up to 8 TB/s of peak theoretical memory bandwidth. More memory can hold larger working sets or additional model sessions, and supported GPU partitioning gives customers another way to divide capacity. How much that is worth depends on the model, the concurrency, and the isolation requirements, not on memory capacity alone. [4]
The token economics depend on the application. A smaller model tuned or selected for a defined task can reduce serving cost when it meets the required quality, although it does not necessarily use fewer tokens, and any retries or human correction belong in the comparison. The target is a lower cost per correctly completed task.
Right-sizing the model is half the opportunity, and routing between models is the other half. An enterprise can send routine, permitted work to a privately hosted model and use a frontier service for harder requests. The router has to weigh answer quality, data policy, and response time alongside price, and the enterprise then has to measure whether that choice actually lowers the cost of the completed workflow.
The Instinct roadmap serves training as well, but we weight this paper toward inference because that is where agentic demand concentrates. Enterprises will train and fine-tune specialized models occasionally and serve them continuously.
5. Helios: rack-scale co-design
Helios is the most complete example of AMD's rack-scale approach to model workloads. It brings EPYC CPUs, Instinct GPUs, Pensando networking, and ROCm into a reference design that OEM and ODM partners can use to build their own systems, and it supports large-scale inference and training. Tool execution, enterprise applications, and parts of the front-end network remain outside that model-serving rack and need their own infrastructure. [1]
Rack-scale integration reduces the number of hardware and software combinations a partner has to assemble for the model workload. That can make deployment and support more manageable, and it gives AMD and its partners room to optimize communication and power across the rack. The customer still has to connect that capacity to the rest of its agent workflow, including the systems that hold data and execute actions.
Helios also shows how AMD combines integration with customer choice. Partners can build from the rack reference design, while other customers use individual AMD components in systems shaped around their own requirements. AMD and HPE have described scale-up Ethernet work with Broadcom using UALoE, alongside the wider open ecosystem. Open interfaces give partners more room for design and interoperability, although any particular configuration still needs support and qualification, and openness does not guarantee that every component can be upgraded independently. [1, 5]
Across the rack, the objective is utilization, resilience, and cost efficiency.
6. Networking: scale-up and scale-out
Networking connects every layer of the agentic system, and it divides into three distinct paths: the front-end network that connects agents to enterprise systems and users, the scale-up fabric inside the rack, and the scale-out network across racks.
Inside the rack, the scale-up links connecting GPUs within a model-serving system reduce the time spent moving data and coordinating work. AMD and its partners have described UALoE for Helios scale-up. The supported protocol and topology determine memory access and synchronization, and a connected rack should not be assumed to be one universally cache-coherent memory space. [5]
Across the cluster, the Pollara 400 and Vulcano 800 AI NICs address scale-out communication at different product generations. The gain from more network bandwidth depends on the model and on how work is distributed, so communication overhead, congestion, and recovery from failures need to be measured in the deployed topology rather than inferred from a NIC's peak link rate.
The value of scale-out bandwidth depends on the model architecture (Exhibit 7). Dense models process every token through the entire model, so inference performance is driven primarily by compute and memory bandwidth, and networking helps mainly when a model spans multiple systems. Mixture-of-experts models work differently. Each token is routed to a subset of experts that may be distributed across many GPUs or servers, so network bandwidth and latency become binding. Faster scale-out networks reduce expert-routing overhead, improve utilization, and keep responses fast. As enterprise-grade reasoning models increasingly adopt mixture-of-experts architectures, scale-out networking moves from a training concern to an inference concern, which is where agentic demand is growing.
The front-end network is the third path, and it is where agent traffic grows fastest.
7. Pensando and the programmable front end
The DPU sits on the agentic execution path, where agents reach enterprise systems, and traffic on that path grows with every agent an enterprise puts to work. Every agent action that touches an enterprise system, whether a database query, an API call, or a workflow trigger, crosses the front-end network and crosses a policy boundary. At enterprise scale, the front-end network has to enforce security, segmentation, and load balancing on a very large number of machine-generated, multi-tenant flows at line rate. Doing that enforcement on host CPUs consumes the same cycles the enterprise wants to spend running agents.
AMD's Pensando Salina 400 DPU is built for this layer, with 400G throughput, PCIe Gen 5, dual 400GE ports, a P4-programmable data plane, Arm cores, and DDR5 memory. Salina offloads SDN, stateful firewalling, encryption, load balancing, NAT, and NVMe-over-Fabrics storage services from the host, which keeps infrastructure services at line rate and returns CPU cycles to agent execution.
The more interesting part is programmability. Agentic infrastructure requirements are still forming, and a programmable data plane lets operators adapt supported packet processing and infrastructure policies without replacing the silicon for every change. Application identity and permission decisions still require software above that data plane, so programmability does not substitute for governing what an agent is allowed to do.
More agent activity can increase front-end traffic and infrastructure services work, which gives operators a reason to consider offload where it frees useful CPU capacity. We would base that decision on traffic, security requirements, and the cost of running those services on the host, rather than on an assumed DPU attach rate.
8. Open ecosystem and software
Enterprises will not deploy agentic AI through one uniform architecture. They will deploy across public cloud, on-premises, and hybrid environments, with software stacks assembled from open-source frameworks, ISV platforms, and internal tooling. AMD's open approach fits that mix.
AMD's enterprise software stack spans ROCm, supported AI frameworks and serving software, and tools for container deployment. Many developers use PyTorch or vLLM rather than programming directly against the underlying GPU runtime, so familiar frameworks and common APIs reduce the application changes required, while partners help enterprises use their existing virtualization and container environments. Support remains specific to the model, the software version, and the hardware configuration. [6]
An integrated platform reduces deployment work, and open interfaces give customers more options for connecting applications and choosing suppliers. A customer can have both. Software licensing and support costs belong in the system comparison. Openness alone does not prove a lower bill or eliminate migration work. The benefit we would point to is that customers keep their options as applications, models, and capacity needs change.
9. The economics: tokens per watt, agents per watt, and total cost
Customers will judge the architecture by what it does to their economics, and agentic AI puts four efficiencies in play at once: token efficiency in the GPUs, agent efficiency in the CPUs, power efficiency across the system, and utilization across the cluster. Buying the fastest accelerator optimizes one of the four.
Token throughput per watt measures the serving side under stated conditions. For the CPU side, useful task throughput and energy per completed task are more informative than the number of configured agents, and waiting sessions, retries, and jobs that miss response-time targets should not make a system look more productive than it is. The full comparison includes the supporting servers and network as well as the accelerator. [2] Each layer of the AMD system maps to a customer metric (Exhibit 10).
Exhibit 10: Architecture capabilities and the customer results to measure
| Architecture benefit | Customer metric |
|---|---|
| GPU memory capacity | Supported model and session capacity at the required latency |
| Scale-out communication | Time spent exchanging data, and useful model throughput |
| CPU performance and concurrency | Tool completion time, and successful tasks per unit of energy |
| Rack integration | Deployment effort, and supported system performance |
| Recovery and resilience | Failed work, and time to restore service |
| Full system operation | Cost per correctly completed business task |
Source: Creative Strategies.
The table connects engineering measurements to the business result. More capacity is valuable when it produces additional accepted work within the required response time, and lower power has value when it reduces operating cost or allows more work within a fixed site limit. We would measure those results across the task rather than infer them from a component specification.
AMD's portfolio gives customers several ways to improve that result: CPU execution for tools and applications, GPU capacity for model serving, and networking for the data moving between them. Helios integrates the model-serving rack, while AMD components and partners serve the surrounding systems. For any buyer, the test is how well those choices fit its complete deployment.
Conclusion
We think of agentic AI as a new population of workers inside enterprise IT: software that plans, executes, and completes work across the systems the enterprise already runs. Supporting that population changes the IT operating model, and it changes what enterprises need to buy. The fastest chip is one input to that decision. The larger question is which system completes the most work across the whole workflow for each dollar and each watt.
AMD has been investing across the requirements that agentic AI brings together. EPYC serves hosts, agent execution, and enterprise applications; Instinct supplies model compute and memory; and Pensando supports networking and infrastructure services. Helios adds a rack-scale design for model workloads, and an open software and partner ecosystem connects AMD's components to the wider deployment.
Our view is that the rise of agentic AI supports the direction of AMD's investments. Enterprises planning deployments should measure token throughput, CPU execution, power, utilization, and response time against the cost per correctly completed business task, and they should buy for the whole workflow, whether that means an integrated rack, individual components, or a mix of suppliers. Paper 3 turns to the software layer and the economics of choosing where that work runs.
Sources
[1] AMD, Helios overview and FAQ, accessed September 29, 2026. https://www.amd.com/en/products/rackscale-solutions/helios.html
[2] Creative Strategies, Agentic CPU Guidebook V5, September 28, 2026; vLLM 0.25.1, Optimization and Tuning. https://docs.vllm.ai/en/v0.25.1/configuration/optimization/
[3] AMD, "The Agentic Era Runs on a CPU Foundation," July 2026. Thread resources are not measured agent throughput. https://www.amd.com/en/blogs/2026/the-agentic-era-runs-on-a-cpu-foundation-and-it-s-called.html
[4] AMD, Instinct MI350 microarchitecture. Specifications quoted for MI350X and MI355X, not all family members. https://rocmdocs.amd.com/en/latest/reference/gpu-arch/mi350.html
[5] AMD and HPE, expanded collaboration on open rack-scale infrastructure. https://newsroom.amd.com/news/amd-and-hpe-expand-collaboration-to-advance-open-r/
[6] AMD, "The Importance of Open Ecosystems for Agentic AI Deployment," July 30, 2026. https://www.amd.com/en/blogs/2026/the-importance-of-open-ecosystems-for-agentic-ai-development.html
AMD architecture and ecosystem illustrations (Exhibits 5, 8, and 9) are reproduced from AMD materials. They show the proposed architecture and partner coverage, not independently measured performance. Creative Strategies diagrams explain workload and network roles. Exhibit 4 is an illustration built on hypothetical inputs. Unconfirmed customer savings and comparative benchmark claims are excluded from this paper.
© 2026 Creative Strategies. Forecasts are Creative Strategies outlooks, not AMD guidance. Product capabilities are described from public AMD documentation and are not claims of universal performance or measured customer savings.