On October 27, 2026, at Oracle AI World, Intel and Oracle announced a multi-year collaboration plan covering current and next-generation Xeon processors. The two companies will coordinate product roadmaps and processor supply plans, and Oracle plans to introduce X14, built on the next-generation server CPU "Diamond Rapids," on its cloud platform Oracle Cloud Infrastructure (OCI). According to Intel's announcement, the collaboration emphasizes not only AI model inference but also the performance of the processing that occurs when AI agents call applications and external tools to carry out business tasks. Looking at two instruction set extensions, AMX, which accelerates matrix operations, and APX, which improves the execution efficiency of general-purpose programs, helps clarify what role Intel is trying to strengthen for CPUs in enterprise AI.
From X12 to X14: What Changes?
Oracle has already offered cloud services that support AI processing on Xeon processors. On April 16, 2026, it announced "OCI X12 Standard Acceleron Compute," powered by Xeon 6 P-core products, and said it would begin rolling it out in some regions. X12 makes use of the CPU's built-in matrix operation feature, Advanced Matrix Extensions (AMX), and also offers Flex VMs that allow CPU and memory allocations to be adjusted flexibly. Based on the X12 announcement, the X14 plan is not the first introduction of CPU-based AI inference but an evolution of existing efforts onto a next-generation processor.
The use cases Intel and Oracle envision are broad, ranging from text embedding generation, search result reranking, and small AI model inference to the execution of business applications and external tools used by AI agents. These work together within a single business process, but the nature of the computation each requires differs. The collaboration aims to improve not only the arithmetic performance of AI models but also the application processing surrounding them.
AI Agents Need More Than Inference
Oracle's published SQL agent reference architecture makes it easier to understand what AI agents actually do. The design describes the process of converting a question a user enters in natural language into a SQL query against a database. First, the system searches for candidate tables related to the question, then reassesses their relevance and narrows them down to suitable candidates. Embedding generation, used in this process, is a technique that converts text into numerical vectors so that it can be searched by semantic similarity. Reranking refers to evaluating the candidates from the initial search in more detail and reordering them by relevance.
Even once the right tables are found, the process does not end there. An AI model then generates SQL, its syntax is validated, and it is executed on the database. Functions such as cache management, conversation history storage, REST APIs called from outside, and system monitoring are also required. From the user's perspective, it is just answering one question, but internally a series of different kinds of computation run in sequence, including search, AI model inference, and database operations.
What is particularly important is that the result of one step affects the quality of the next. For example, searching for related tables also determines which information is passed to the model that generates the SQL. Even if search and SQL generation are each sped up individually, overall quality and execution efficiency will not necessarily improve if the right information is not handed over. To evaluate real performance, you need to measure the whole chain, from candidate search through SQL generation, validation, and execution, as a single process.
Similarly, the speed at which an AI model generates text or SQL alone cannot tell you how long a user waits for the final result. Even if inference gets faster, if subsequent database processing takes a long time, the total time for the task may not shrink as much as expected. Storing conversation history and running external tools also consume computing resources different from those used to predict the next token. AI agents also need execution control that manages the order of these steps and calls tools as needed.
However, Oracle's reference architecture only describes a system configuration; it is not a case study running on X14 or a set of performance measurements. It also does not specify which CPU runs each step, how work is divided between CPUs and GPUs, or how processing time is broken down. What the design shows is that a single AI agent combines different kinds of computation to complete a task. The roles of AMX and APX described below are analyses based on their technical characteristics, not confirmation of implementation or performance in any specific OCI service.
AMX Speeds Up Matrix Math, APX Speeds Up General-Purpose Programs
AMX, which Intel has been strengthening for AI processing, is an instruction set extension for efficiently executing matrix operations inside the CPU. According to Intel's technical documentation, it combines two-dimensional tile registers that hold portions of matrix data with an arithmetic mechanism that computes matrix products. Registers are fast working areas inside the CPU, and by holding matrix data as tiles while computing, AMX makes the calculations heavily used in AI inference more efficient. AMX itself has been available since 4th Gen Xeon and is not a technology that debuts with Diamond Rapids.
APX (Advanced Performance Extensions), on the other hand, targets the general-purpose code used to run ordinary applications. Intel's APX technical overview explains, among other things, that the number of general-purpose registers is expanded from 16 to 32. This allows compilers to keep more values needed during program execution inside the CPU, potentially reducing the memory accesses and the saving and restoring of values. Unlike AMX, which specializes in matrix multiplication, APX is a technology for improving the execution efficiency of ordinary programs such as business applications and external tools.
Applied to AI agent workloads, AMX is suited to speeding up the parts that make heavy use of matrix operations, such as embedding generation, reranking, and small-model inference. APX, meanwhile, may help improve the efficiency of processing that uses general-purpose instructions, such as application control and tool execution. These are, however, uses one can infer from the functions of the instruction extensions, and they do not indicate measured X14 performance or application to any specific service. Organizing their characteristics and usage conditions based on Intel's technical materials gives the following.
| Feature | Main mechanism | Expected use in AI agents | Requirements |
|---|---|---|---|
| AMX | Speeds up matrix computation with two-dimensional tile registers and dedicated arithmetic hardware | Embedding generation, search result reranking, small AI model inference, etc. | Supported CPU and OS, plus libraries or frameworks that use AMX instructions |
| APX | Improves execution efficiency of general-purpose code, e.g., by expanding general-purpose registers from 16 to 32 | General-purpose processing such as business applications and external tools | Supported CPU, plus recompilation and runtime-side support |
To take advantage of these two instruction extensions, preparation on the software side matters as well as CPU support itself. To use AMX, in addition to the CPU and OS, you need libraries and frameworks that actually invoke the corresponding instructions. APX likewise does not mean existing executables will automatically start using the new instructions. Compiled programs generally require a rebuild with a supporting compiler, and for dynamic languages, runtime and library support becomes a condition of use. Being able to run existing software without problems is distinct from gaining performance improvements from the new instructions.
Even tasks such as embedding generation and reranking are not composed entirely of matrix operations. Ordinary programs are also used for invoking models, passing data, and processing results, so AMX alone does not necessarily speed up the entire process. APX is an extension for improving the execution efficiency of such general-purpose code. Precisely because a single AI agent includes both kinds of processing, AMX and APX should not be lumped together as "AI features"; it is necessary to determine which part each one benefits.
Preparation on the software side was under way even before this collaboration announcement. Intel's technical explainer on GCC 15, published June 15, 2025, explains that support for Diamond Rapids instructions is being added together with Binutils 2.44, including full APX and AMX-FP8 support. A compiler's ability to generate new instructions is an important prerequisite for developing compatible software. It does not, however, mean that Diamond Rapids has begun shipping or that service on OCI has started.
The X14 plan cites enhanced AMX supporting numerical formats such as FP8, FP16, and BF16, along with APX for general-purpose processing. However, it would not be accurate to interpret FP16 or BF16 support as being introduced for the first time with Diamond Rapids. What matters is whether libraries and runtime environments that support the numerical formats and operations of the models in use are in place, and whether the new instructions can actually be used in real services. Even if hardware features increase, they will not lead to the expected performance gains unless software uses them.
Why Oracle Mixes CPUs and AI Accelerators
On the same day, October 27, as the Intel collaboration announcement, Oracle also said it would further broaden the range of computing resources available on OCI. Oracle's announcement about OCI's future direction mentions E7, which uses AMD's 6th Gen EPYC processors, as well as NVIDIA's Vera Rubin and Vera CPU and Google TPUs. The Intel collaboration can be seen as part of a strategy of letting customers use different computing resources for different purposes, rather than concentrating computation on a particular processor.
Breaking down AI agent processing makes the meaning of this approach clearer. Adding accelerators to run large AI models and adding CPU capacity to run search, databases, and business applications address different problems. Intel's announcement also envisions a configuration in which these resources can be scaled independently. By extending Xeon adoption beyond X12 into future generations, Oracle likely aims to let customers adjust AI model processing capacity and the capacity of the business systems running around it according to their respective demand.
For example, even if the volume of AI model inference stays the same, an increase in the workload of business services the agent calls may require more CPU capacity. Conversely, even if search and database processing have headroom, overall task speed will not improve if AI model inference capacity is insufficient. If computing resources can be scaled independently, investment can be concentrated where the performance bottleneck lies. This is an important idea for operating an AI system efficiently as a whole.
However, when work is divided among different computing resources, the network used to transfer data between systems also becomes important. Oracle's technical explainer on AI networking, published the same day, addresses the challenges of using RDMA on a shared front-end network. RDMA (Remote Direct Memory Access) is a technology that reduces CPU and OS involvement when transferring data between separate machines by accessing memory directly. It can reduce the CPU load associated with data transfer, but its role differs from technologies that raise the CPU's own computational performance.
Even with RDMA, a shared network requires measures against congestion, latency, and packet loss. Increasing CPU computing power does not eliminate the wait for data to arrive from another machine. Oracle's networking explainer, however, does not reveal X14-specific RDMA specifications or availability. The point here is that when evaluating the effect of combining CPUs and accelerators appropriately, one must consider not only computing power but also the load and latency associated with data transfer.
X14's Value Should Be Judged by Whole-Task Time and Cost
In this announcement from Intel and Oracle, X14's specific availability date, supported regions, and pricing were not disclosed. The final system configuration, processor supply volumes, and contract amounts have also not been published, and no performance comparison results using real business workloads have been shown. What has been announced is a future collaboration plan, and Intel states that it does not guarantee the delivery or availability of planned features.
To judge the benefits of adopting X14, it will be important to measure not the inference speed of the AI model alone but the processing time for an agent to complete one task. For a SQL agent, for example, one should use the same set of questions and compare the whole sequence, from related table search through SQL generation, validation, and execution, as a single process. Beyond processing time, it would also be worth checking the proportion of correct results and concurrent execution performance. Including required memory capacity and operating costs would then make it possible to separate the effect of faster model inference from the wait times involved in database and external tool processing. These are the perspectives needed for future performance validation, not measurement results shown in this announcement.
The readiness of libraries that use AMX and of compilers and runtime environments that support APX is also an essential evaluation condition. Even on the same Diamond Rapids hardware, the performance obtained may vary depending on whether an application uses the new instructions. The efficiency of the overall system will also depend on how roles are divided between CPUs and accelerators and on the conditions of data transfer over the network. Once X14's terms of availability are clear and measured results using compatible software are in hand, enterprises should be able to decide whether to allocate computing resources and budget to CPUs or accelerators based on processing time and total cost per business task.