# Oracle Cloud Infrastructure (OCI) AI Infrastructure — 4+1 Layer AI Infrastructure Assessment

> Mapped to the 4+1 Layer AI Infrastructure Model  
> Version: v1.0 — Draft, Editorial Review Pending · Date: May 23, 2026  
> Source: Oracle AI World 2025, GTC 2026, OCI Enterprise AI GA (Mar 2026), Fusion Agentic Applications (Mar 2026), Oracle AI Database 26ai, Stargate/OpenAI partnership, NVIDIA/AMD partnerships, analyst coverage, Oracle Q3 FY2026 earnings  
> Published by: The CTO Advisor LLC · thectoadvisor.com  
> Author: Keith Townsend

[Full interactive assessment](https://layer2c.web.app/assessment/oci) · [Methodology](https://layer2c.web.app/methodology) · [What Is Layer 2C?](https://layer2c.web.app/what-is-layer-2c)

## Executive Summary

OCI occupies a structurally unique position in this assessment series: it is the only hyperscaler whose AI infrastructure strategy is anchored by a database franchise. AWS builds down from managed services. Google builds out from a frontier model. OCI builds up from the enterprise data layer — Oracle AI Database 26ai, Autonomous AI Database, and the Fusion Applications estate that runs 97% of the Fortune 100. Every other hyperscaler treats the database as one service among many. Oracle treats the database as the gravitational center around which AI infrastructure orbits.

The infrastructure story is more aggressive than the enterprise positioning suggests. OCI Zettascale10 connects up to 800,000 NVIDIA GPUs across multi-gigawatt clusters delivering 16 zettaFLOPS — the fabric underpinning the Stargate supercluster built with OpenAI in Abilene, Texas. Oracle Acceleron, a custom RoCE networking architecture with 2.5–9.1 microsecond latency, is genuine Layer 0 IP that positions OCI alongside AWS (Nitro/EFA/SRD) and Google (Virgo) as hyperscalers with proprietary networking stacks. The AMD partnership (50,000 MI450 GPUs, Q3 2026) makes OCI one of two hyperscalers with meaningful multi-vendor GPU strategy alongside AWS.

The DAPM profile is heavily Ceded — structurally identical to AWS and Google Cloud in that the enterprise consumes managed services without controlling underlying architecture. But OCI adds a distinctive wrinkle: the database layer creates a gravitational pull that concentrates not just infrastructure authority but data authority. An enterprise running Fusion Applications on Autonomous AI Database on OCI Superclusters has Ceded compute, networking, database, application runtime, AND business logic to a single vendor. This is deeper vertical integration than AWS (which doesn't own the application layer) and comparable to Google's model-integrated stack — but achieved through the application and data layers rather than through a frontier model.

OCI Enterprise AI (GA March 2026) is a credible but late entry to the agentic platform space. OpenAI Responses-compatible API, managed agent hosting, vector stores, MCP support, guardrails, and observability — the capabilities parallel AWS Bedrock AgentCore and Google's Gemini Enterprise Agent Platform. The differentiator is database-native AI: Select AI for natural language to SQL, AI Vector Search inside the database engine, and the Private Agent Factory pattern that keeps agent reasoning co-located with enterprise data. Whether 'AI at the database layer' is a structural advantage or an architectural constraint is the central DAPM question for OCI.

The Stargate partnership and $553B RPO validate infrastructure demand. The Fusion Agentic Applications validate the application-layer strategy. The multicloud database deployments (Oracle Database@AWS, @Azure, @Google Cloud) validate the data-gravity thesis. But the 4+1 framework asks a different question: where does authority reside, and has the enterprise made that placement explicit? For OCI, the answer is that authority concentrates in the database — and the database concentrates in Oracle.

## Layer Status

| Layer | Status | Classification |
|---|---|---|
| Layer 0 | ● Ceded to Oracle | Compute & Network Fabric |
| Layer 1A | ● Ceded to Oracle — Database-Anchored | Data Storage & Governance |
| Layer 1B | ● Ceded — Database-Native | Context Management & Retrieval |
| Layer 1C | ◑ Ceded — Database-Centric, Gaps in ML Pipeline Orchestration | Data Movement & Pipelines |
| Layer 2A | ◑ Ceded — OKE + NVIDIA GPU Scheduling | Infrastructure Orchestration |
| Layer 2B | ● Ceded — OCI Enterprise AI Platform | Application Runtime & Execution |
| Layer 2C | ◑ Intelligence 2C: Emerging | Infra 2C: Implicit | Agentic Infrastructure — The Reasoning Plane |
| Layer 3 (+1) | ● Strongest Application-Layer Authority | AI Application Layer — The Value Plane |

## DAPM Profile

| Classification | Count | Meaning |
|---|---|---|
| Retained | 0 | Enterprise owns and controls this capability |
| Delegated | 1 | Provided by substitutable partner; enterprise retains swap authority |
| Ceded | 26 | Vendor controls this; enterprise has no governance authority |
| Absent | 0 | No capability at this layer |

## Strongest Layers

- **Layer 0** (Compute & Network Fabric) — Ceded to Oracle
- **Layer 1A** (Data Storage & Governance) — Ceded to Oracle — Database-Anchored
- **Layer 1B** (Context Management & Retrieval) — Ceded — Database-Native
- **Layer 2B** (Application Runtime & Execution) — Ceded — OCI Enterprise AI Platform
- **Layer 3 (+1)** (AI Application Layer — The Value Plane) — Strongest Application-Layer Authority

## Layer-by-Layer Detail

### ● Layer 0: Compute & Network Fabric

*Raw compute, networking, and acceleration fabric*  
**Status:** Ceded to Oracle

**OCI Superclusters + Zettascale10** [DAPM: Ceded]  
Up to 800,000 NVIDIA GPUs across multi-gigawatt clusters. 16 zettaFLOPS peak performance. Underpins Stargate (OpenAI). Scales from 8 GPUs to 131,072 B200 GPUs, 100,000+ GB200 Superchips per cluster. Bare metal GPU instances with RDMA cluster networking.

**Oracle Acceleron Networking** [DAPM: Ceded]  
Custom-designed RDMA over Converged Ethernet (RoCE v2). 2.5–9.1 microsecond GPU-to-GPU latency. Multiplanar network architecture with dedicated RoCE fabrics. Congestion-control-first (not PFC-dependent). Zero-Trust Packet Routing (ZPR) at the physical layer. Up to 3,200 Gb/s cluster network bandwidth. Oracle-owned networking IP.

**NVIDIA GPU Fleet** [DAPM: Ceded]  
GB200 NVL72, B200/B300, H200, H100, A100, L40S bare metal instances. 1M+ GPUs. NIXL support for disaggregated inference. BlueField-4 integration for next-gen Superclusters (GTC 2026). DGX Cloud hosted on OCI.

**AMD GPU Fleet (Q3 2026)** [DAPM: Ceded]  
50,000 AMD Instinct MI450 Series GPUs. Helios rack architecture: 72 liquid-cooled GPUs per rack, AMD EPYC Venice CPUs, Pensando Vulcano DPUs. UALink/UALoE fabric. ROCm software stack. Up to 432 GB HBM4, 20 TB/s memory bandwidth per GPU. First hyperscaler with publicly available AMD AI supercluster at this scale.

**OCI Dedicated Region25 + Oracle Alloy** [DAPM: Ceded]  
Full OCI stack (200+ services including SaaS) in customer data center, starting at 3 racks. 60+ Dedicated Region/Alloy regions live. EU Sovereign Cloud (Frankfurt, Madrid). Isolated Cloud Regions for classified workloads. Oracle Alloy enables partner-operated OCI. Fujitsu, SoftBank, Vodafone as anchor customers.

**Gap Analysis:** OCI's Layer 0 is the most surprising story in this assessment series. A vendor perceived as a database company has built one of the largest GPU cloud fabrics in the world — the Stargate supercluster alone targets 800,000 GPUs. Oracle Acceleron is genuine networking IP: custom RoCE with congestion-control-first design (not PFC-dependent), multiplanar architecture, Zero-Trust Packet Routing at the physical layer. This is not leased NVIDIA networking — it's Oracle-designed fabric.

The multi-accelerator strategy is more advanced than any hyperscaler except AWS. NVIDIA (Blackwell, Rubin), AMD (MI450 with Helios rack architecture, 50,000 GPUs Q3 2026), and Intel Xeon 6 processors. The AMD Helios rack — 72 liquid-cooled GPUs with Venice CPUs and Pensando Vulcano DPUs — is a fully integrated system comparable to NVIDIA DGX but from AMD's ecosystem. No other hyperscaler has committed to AMD at this scale.

The Dedicated Region25 (full OCI in 3 racks, customer data center) and Oracle Alloy (partner-operated OCI) create a distributed cloud model with 60+ dedicated/Alloy regions live. This parallels AWS AI Factories, Azure Local, and Google Distributed Cloud — but Oracle's model delivers the full 200+ service stack, including SaaS, which none of the other hyperscalers match in dedicated form.

The structural tension: OCI's GPU customers include OpenAI, xAI, Meta, and other frontier model trainers. These are not traditional Oracle enterprise customers. OCI is simultaneously serving the world's largest AI training workloads AND the world's most conservative enterprise database customers — two audiences with fundamentally different risk profiles and authority expectations.

**Borrowed Judgment:** The enterprise Cedes Layer 0 entirely to Oracle — GPU selection, networking topology, cluster design, physical infrastructure. Oracle Acceleron is Oracle IP, reducing NVIDIA networking dependency compared to hyperscalers using NVIDIA Spectrum-X. But the GPU silicon dependency on NVIDIA (and increasingly AMD) is structural and shared with every vendor in this assessment.

The Stargate partnership creates a unique borrowed judgment dynamic: Oracle operates infrastructure for OpenAI's training workloads. The operational lessons from running the world's largest AI training cluster feed back into OCI's infrastructure decisions — but those decisions are made for frontier training requirements, not necessarily for enterprise inference workloads.

### ● Layer 1A: Data Storage & Governance

*Durable, governed data foundation — the Governance Catalog that Layer 2C queries*  
**Status:** Ceded to Oracle — Database-Anchored

**Oracle Autonomous AI Database** [DAPM: Ceded]  
Self-managing, self-securing, self-patching database built on Oracle AI Database 26ai engine. AI Vector Search (native vector data type, HNSW/IVF indexes, SQL-based similarity search), Select AI (natural language to SQL), ONNX embedding models, Private AI Services Container integration, NVIDIA NIM container support. Autonomous AI Lakehouse with Apache Iceberg support for open multi-vendor data lakehouse. RAFT-based replication, JSON Relational Duality, quantum-resistant encryption, in-database SQL firewall. Platinum and Diamond-tier availability (Apr 2026). Anomaly detection, auto-indexing, auto-tuning. Autonomous AI Vector Database variant in Limited Availability (March 2026). Available on OCI, AWS, Azure, Google Cloud via multicloud deployments.

**OCI Object Storage** [DAPM: Ceded]  
Standard object storage for unstructured data, embeddings, model artifacts. S3-compatible API. Regional and cross-region replication. Storage Classes for cost optimization.

**Oracle Database@AWS / @Azure / @Google Cloud** [DAPM: Ceded]  
Oracle AI Database running inside other hyperscalers' infrastructure with private interconnects. Multicloud Universal Credits for cross-cloud procurement. Teams use familiar AWS/Azure/Google tools and billing while running Oracle AI Database on OCI infrastructure within the hyperscaler. Oracle-AWS Interconnect expanded April 2026.

**Gap Analysis:** Layer 1A is where OCI's structural differentiation is sharpest. Every other hyperscaler treats storage and governance as separate services composed by the customer. Oracle treats the database AS the governance layer — AI Vector Search, Select AI, data classification, audit, encryption, and access control are database-native capabilities, not services bolted on top.

Oracle AI Database 26ai is the most significant Layer 1A product in this assessment because it collapses traditionally separate functions: relational storage + vector storage + semantic search + natural language querying + governance + encryption + lakehouse (Apache Iceberg) into a single authority boundary. AWS achieves comparable breadth by composing S3 + Glue + Lake Formation + OpenSearch — four services, four governance surfaces. Oracle delivers it in one.

The Autonomous AI Lakehouse extends this to open formats: Apache Iceberg read/write in object store, enabling cross-cloud analytics without data movement. Oracle Database@AWS, @Azure, and @Google Cloud place Oracle's data authority inside other hyperscalers' infrastructure — a multicloud data-gravity strategy no other vendor in this series attempts.

The DAPM implication: collapsing Layer 1A into a single database authority is simultaneously Oracle's greatest strength and greatest lock-in risk. The enterprise gains architectural simplicity and eliminates inter-service governance gaps. But substituting away from Oracle AI Database means losing vector search, semantic querying, governance, and the lakehouse capability simultaneously — a higher switching cost than any other hyperscaler's Layer 1A.

**Borrowed Judgment:** Low for database governance — Oracle AI Database 26ai governance (encryption, access control, audit, classification) is Oracle IP with 40+ years of enterprise hardening. The enterprise defines policies; Oracle enforces them inside the database.

Moderate for AI-specific capabilities — Select AI and AI Vector Search embed model judgment (embedding quality, chunking strategy, SQL generation accuracy) inside the database layer. When Select AI generates SQL from natural language, the enterprise inherits the model's interpretation of business logic — the same borrowed judgment pattern identified in Google's LookML Agent, but at the database layer rather than the analytics layer.

### ● Layer 1B: Context Management & Retrieval

*Low-latency retrieval for RAG — vector/hybrid search, context windows*  
**Status:** Ceded — Database-Native

**AI Vector Search (Oracle Autonomous AI Database)** [DAPM: Ceded]  
Native vector data type, HNSW and IVF vector indexes, SQL-based similarity search. Hybrid search combining vector similarity with relational predicates. Permission-aware retrieval through database access control. No separate vector database required.

**OCI Enterprise AI — Managed Vector Store** [DAPM: Ceded]  
Managed vector storage with file ingestion, semantic search, and metadata filtering for RAG and NL2SQL use cases. Schema enrichment into semantic vector store for natural language queries that produce and execute SQL against customer databases with permission control.

**Select AI + SQL Search (NL2SQL)** [DAPM: Ceded]  
Natural language to SQL generation and execution. Applications and analytics use LLMs to understand natural language questions and generate Oracle SQL. Bridges unstructured (vector) and structured (SQL) retrieval in a single query surface.

**OCI Generative AI — Embeddings + Rerank** [DAPM: Ceded]  
Managed embedding and reranking services. Supports Cohere, NVIDIA Nemotron, and other embedding models. OpenAI-compatible APIs. Dedicated AI clusters for consistent latency.

**Gap Analysis:** OCI's Layer 1B collapses into Layer 1A — and that's the architectural point. AI Vector Search lives inside Oracle AI Database, not as a separate vector database service. RAG queries execute as SQL against the same database that holds the enterprise's transactional data. Permission-aware retrieval inherits the database's existing access control model without a separate security overlay.

This is the same architectural pattern as VAST (InsightEngine inside the data platform) but at the database level rather than the storage level. The comparison to AWS is instructive: Bedrock Knowledge Bases composes OpenSearch + S3 + embedding models across service boundaries. Oracle eliminates those boundaries by making vector search a database capability.

The SQL Search (NL2SQL) capability adds a dimension no other vendor's Layer 1B provides: agents can retrieve structured enterprise data through natural language queries that generate and execute SQL. This bridges unstructured retrieval (vector search for documents) and structured retrieval (SQL for business data) in a single query surface — a genuine differentiation.

The gap: Oracle's Layer 1B is database-bounded. Data outside Oracle AI Database isn't retrievable through AI Vector Search. AWS's Bedrock Knowledge Bases can index data from any S3-accessible source. Google's BigQuery can federate queries across storage boundaries. Oracle's retrieval requires data to be IN the database or accessible through database links. SyncEngine-like capabilities for ingesting external enterprise data (Google Drive, Jira, Confluence) are not evident in Oracle's published materials.

**Borrowed Judgment:** Low for vector search infrastructure — AI Vector Search, indexing, and SQL-based retrieval are Oracle IP inside the database engine. No external retrieval service dependency.

Moderate for embedding quality — embedding models are either ONNX (customer-provided), NVIDIA NIM containers, or third-party models through OCI Generative AI. The quality of retrieval depends on embedding model choice, which the enterprise controls but doesn't build.

The NL2SQL capability introduces a specific borrowed judgment: when Select AI generates SQL from natural language, the accuracy of retrieval depends on the model's understanding of the database schema. Schema enrichment into a semantic vector store (announced in OCI Enterprise AI) mitigates this — but the enterprise inherits the model's interpretation of table relationships and business logic.

### ◑ Layer 1C: Data Movement & Pipelines

*Move/transform data — ETL/ELT, lineage, governed data preparation*  
**Status:** Ceded — Database-Centric, Gaps in ML Pipeline Orchestration

**OCI GoldenGate** [DAPM: Ceded]  
Real-time data replication, transformation, and streaming across heterogeneous sources. Continuous data availability. Database migration, disaster recovery, real-time analytics. The deepest database connector ecosystem of any cloud data movement service.

**OCI Data Integration + Data Flow** [DAPM: Ceded]  
Data Integration: managed ETL/ELT service with visual design. Data Flow: managed Apache Spark for large-scale data processing and ML data preparation. Integration with Autonomous AI Database and OCI Object Storage.

**OCI Data Science** [DAPM: Ceded]  
Managed ML platform: JupyterLab notebooks, model training, model catalog, model deployment. AI Quick Actions for one-click model operations. GPU-enabled compute shapes. Separate service surface from OCI Enterprise AI.

**Multicloud Database Connectivity** [DAPM: Ceded]  
Oracle Interconnect + AWS Interconnect for managed private high-performance connectivity (April 2026). Oracle Database@AWS, @Azure, @Google Cloud. Multicloud Universal Credits for cross-cloud procurement. Data stays in Oracle's governance model regardless of which cloud hosts the compute.

**Gap Analysis:** Layer 1C reveals the database-centric trade-off. Oracle's data movement capabilities are strong for database-to-database flows (GoldenGate) and analytics pipelines (OCI Data Integration, OCI Data Flow). But the ML-specific pipeline orchestration that Dell (Dataloop), HPE (Ezmeral Unified Analytics), VAST (DataEngine), and AWS (Glue + SageMaker Unified Studio) provide is less integrated.

OCI Data Science provides notebooks, model training, and deployment but is a separate service from OCI Enterprise AI — creating a multi-surface problem similar to AWS's pre-Unified Studio fragmentation. There is no single governed environment that collapses data engineering, model training, and agent development the way SageMaker Unified Studio or Google's BigQuery ML attempt.

GoldenGate is the most mature real-time data replication service in the assessment series — purpose-built for heterogeneous data movement across on-premises and cloud. No other hyperscaler has an equivalent with Oracle's depth of database connector support.

The multicloud data movement story is strong: Oracle Database@AWS/@Azure/@Google Cloud moves the database layer to the customer's cloud of choice. But this is database replication, not general-purpose data pipeline orchestration. An enterprise needing Airflow-style DAG orchestration for ML workflows must deploy it on OKE — which is possible but not Oracle-managed.

**Borrowed Judgment:** Low to moderate. GoldenGate and OCI Data Integration are Oracle IP. Data Flow (managed Spark) and OCI Data Science (managed notebooks) are Oracle-managed wrappers around open-source technology (Apache Spark, JupyterLab). The enterprise retains pipeline logic but Cedes execution infrastructure.

The pipeline gap means enterprises often bring third-party orchestration (Airflow, Kubeflow) to OCI — introducing borrowed judgment from those communities and creating governance boundaries that don't exist when using Oracle-native services.

### ◑ Layer 2A: Infrastructure Orchestration

*GPU scheduling, capacity management, autoscaling*  
**Status:** Ceded — OKE + NVIDIA GPU Scheduling

**OCI Kubernetes Engine (OKE)** [DAPM: Ceded]  
Managed Kubernetes with GPU-aware node pools. Bare metal and virtual machine compute shapes. RDMA cluster networking for training workloads. MIG support for fractional GPU allocation. Autoscaling at pod level with GPU Device Plugin metrics. Karpenter support for node autoprovisioning. Free managed control plane.

**OCI Compute Management** [DAPM: Ceded]  
Instance pools, cluster networks, capacity reservations, preemptible instances. GPU shape selection across NVIDIA and AMD (Q3 2026). OCI Resource Manager (Terraform-based) for infrastructure as code.

**GPU Node Manager + Monitoring** [DAPM: Ceded]  
Kubernetes-native GPU, networking, and infrastructure monitoring for OKE clusters. NVIDIA DCGM integration. Health monitoring, utilization metrics, and alerting. Actively developing additional capabilities.

**Gap Analysis:** OCI's Layer 2A follows the same pattern as AWS: Kubernetes-based GPU orchestration through a managed service (OKE) with NVIDIA GPU scheduling underneath. OKE provides managed Kubernetes with GPU-aware node pools, autoscaling, bare-metal RDMA networking, and MIG support for fractional GPU allocation.

The distinction from AWS: OCI's bare-metal GPU instances give customers more direct hardware control than AWS's virtualized GPU instances. OKE autoscaling operates at the pod level using NVIDIA GPU Device Plugin metrics, and the Karpenter Provider for OCI (GA April 2026) brings flexible node autoprovisioning — matching AWS's Karpenter capability for just-in-time compute shape selection based on workload requirements.

GPU scheduling authority follows the same pattern as Dell and HPE: NVIDIA controls GPU scheduling through the GPU Operator and Device Plugin. Oracle controls infrastructure orchestration through OKE. Policy-driven GPU scheduling (which workload gets which GPU based on cost, compliance, and performance) is not an OCI-native function — the same gap every vendor shares.

The Dedicated Region model adds a Layer 2A dimension other hyperscalers don't match: OCI orchestrates infrastructure across public cloud, 60+ dedicated regions, isolated regions, and Alloy partner regions from a single control plane. The orchestration scope is broader than AWS (Outposts, AI Factories) or Google (GDC) in terms of the number and variety of deployment targets.

**Borrowed Judgment:** GPU scheduling: NVIDIA-controlled, same as every other vendor except AWS (Karpenter) and Google (TPU scheduling). Infrastructure orchestration: Oracle-controlled through OKE and the OCI control plane. The enterprise Cedes orchestration authority but retains Kubernetes-native configuration control.

The bare-metal model creates a subtly different borrowed judgment profile: with bare metal, the enterprise has more direct GPU control (no hypervisor overhead, direct RDMA access) but also more operational responsibility. The judgment about GPU sharing, isolation, and scheduling is partially Retained by the customer — a more favorable DAPM position than fully managed GPU instances.

### ● Layer 2B: Application Runtime & Execution

*Model serving, agent execution, inference APIs, distributed inference*  
**Status:** Ceded — OCI Enterprise AI Platform

**OCI Enterprise AI Platform** [DAPM: Ceded]  
End-to-end agentic AI platform (GA March 2026). OpenAI Responses-compatible API with multi-model routing. Enterprise AI agents with modular, composable primitives. Managed agent hosting for OSS frameworks and MCP servers. Vector stores, semantic search, NL2SQL, memory, tools. IAM integration, guardrails, observability, auditability. Dedicated AI clusters for isolated compute.

**OCI Generative AI Service** [DAPM: Ceded]  
Foundation model access: xAI Grok (4.1 Fast, 4.3), Cohere Command A (Vision, Reasoning), NVIDIA Nemotron 3 Nano Omni, gpt-oss models. Chat, embeddings, rerank APIs. Model Import for custom models. OpenAI-compatible APIs. Sovereign AI options for data hosting.

**Applications and Deployments (Hosted Runtime)** [DAPM: Ceded]  
Container-based hosting for custom agentic applications. Managed infrastructure, networking, storage integration, identity configuration. Public and private endpoint support. Build-in security. Supports OSS frameworks and custom runtimes.

**Private Agent Factory (Oracle Autonomous AI Database)** [DAPM: Ceded]  
Agents run inside Oracle AI Database with direct data access. Co-locates agent reasoning with enterprise data. Eliminates external RAG pipeline latency. Private AI Services Container for on-premises inference without sending data to third-party services.

**Gap Analysis:** OCI Enterprise AI (GA March 2026) is Oracle's unified agentic platform. The capabilities are comprehensive: OpenAI Responses-compatible API, managed agent hosting for OSS frameworks and MCP servers, vector stores, semantic search, NL2SQL, guardrails, observability, and auditability. The OpenAI API compatibility is strategically important — it reduces migration friction from OpenAI's platform and positions OCI as a drop-in alternative.

The model catalog includes xAI Grok (4.1 Fast, 4.3), Cohere Command A (Vision, Reasoning), NVIDIA Nemotron 3 Nano Omni, and custom models through Model Import. The notable absence: no Anthropic Claude and no Meta Llama in published model availability. This is a narrower model selection than AWS Bedrock or Google's Model Garden.

The agentic runtime distinguishes between three patterns: (1) OCI Generative AI APIs for direct model access, (2) Enterprise AI agents with managed orchestration, tools, memory, and retrieval, and (3) Applications and Deployments for container-based hosted agentic applications with custom runtimes. This three-tier model parallels AWS's Bedrock / AgentCore / SageMaker hierarchy.

Dedicated AI clusters provide isolated compute for enterprise workloads — the opposite of shared-tenant model serving. This addresses a specific enterprise concern: inference latency predictability and data isolation. The trade-off is cost — dedicated clusters have fixed cost regardless of utilization.

The Fusion Agentic Applications (22 agents across HR, finance, supply chain, CX — GA March 2026) represent Layer 2B and Layer 3 simultaneously: the runtime executes agents that are pre-built for Oracle's application estate. No other hyperscaler ships pre-built enterprise application agents at this scale.

**Borrowed Judgment:** Model providers (xAI, Cohere, NVIDIA) bring training data, alignment, and safety decisions as borrowed judgment. Oracle's guardrails constrain output but reasoning in model weights is not customer-configurable — same pattern as every other hyperscaler.

The Fusion Agentic Applications introduce a unique borrowed judgment dynamic: these agents execute decisions within business processes by accessing unified enterprise data, workflows, policies, approval hierarchies, and permissions. The enterprise inherits Oracle's judgment about how HR, finance, and supply chain processes should be automated. This is not model-level borrowed judgment — it's business-process-level borrowed judgment. When a Fusion Agentic Application automates a talent review or maintenance troubleshooting, the enterprise inherits Oracle's encoding of what 'good' process execution looks like.

### ◑ Layer 2C: Agentic Infrastructure — The Reasoning Plane

*Policy-driven placement and resource coordination — the Autonomy Layer*  
**Status:** Intelligence 2C: Emerging | Infra 2C: Implicit

**OCI Enterprise AI Governance** [DAPM: Ceded]  
IAM-based access control for AI resources. Guardrails for content safety and policy enforcement. Observability for agent behavior, tool usage, and data flow monitoring. Auditability with audit logs capturing all AI interactions. Sovereign AI options. Project-level isolation for agent workloads.

**Autonomous Database Self-Management** [DAPM: Ceded]  
Self-managing, self-securing, self-repairing database operations. Auto-indexing, auto-tuning, anomaly detection, autonomous performance optimization. Infrastructure 2C at the database layer — autonomous placement and resource decisions within the database boundary.

**Gap Analysis:** Intelligence Layer 2C (partially present): OCI Enterprise AI governance includes IAM-based access control, guardrails for content safety, observability for agent behavior monitoring, and auditability for compliance. Oracle's blog series on runtime governance (April–May 2026) articulates sophisticated 2C concepts: runtime budget guardrails, approval-aware execution, pre-execution veto, safe degradation, evidence-backed runtime control, and the WORM Evidence Vault for audit-grade trace preservation.

But there is a gap between the conceptual architecture Oracle's engineering team has published and the productized capabilities in OCI Enterprise AI GA. The runtime governance blog describes a governed execution layer with budget guardrails, circuit breakers, and safe-mode execution. The GA product offers IAM, guardrails, and observability — necessary but not sufficient for the full 2C vision Oracle's own engineers have articulated.

Infrastructure Layer 2C (not built): No OCI service answers 'given data residency, cost, latency, GPU availability across NVIDIA and AMD, and compliance requirements, should this workload run on dedicated clusters in us-ashburn-1 or on Dedicated Region infrastructure in Frankfurt?' The capacity management primitives exist. The policy-driven placement engine does not.

The Autonomous AI Database is the closest OCI comes to Infrastructure 2C: it self-manages, self-secures, auto-indexes, auto-tunes, and detects anomalies autonomously. But this autonomy operates at the database layer, not at the infrastructure-wide placement layer that the 4+1 model defines.

OCI's unique 2C opportunity: Oracle is the only hyperscaler with both the application layer (Fusion) and the data layer (AI Database) under one authority. A Layer 2C that queries Fusion application state, database governance metadata, GPU utilization, and compliance posture to make autonomous placement decisions would have richer context than any other hyperscaler's 2C — because Oracle sees from application logic through data governance to infrastructure. The data to build 2C exists. The product does not.

Cross-vendor Layer 2C comparison:
• Dell: Absent.
• HPE: Retained (IT ops, GreenLake Intelligence) + Delegated (Kamiwaza).
• VAST: Retained/Emerging (PolicyEngine + Polaris).
• AWS: Intelligence 2C Delegated (AgentCore Policy). Infra 2C implicit.
• Google: Most complete productized Intelligence 2C (Agent Identity + Gateway + Registry + Orchestration + Observability).
• OCI: Intelligence 2C emerging (guardrails + observability + auditability). Conceptual vision published but not yet fully productized. Infra 2C implicit.

**Borrowed Judgment:** Intelligence 2C: Low — guardrails, observability, and auditability are Oracle IP. Customer defines IAM policies; Oracle enforces.

Infrastructure 2C: Ceded (implicit) — the Autonomous AI Database makes placement, scaling, and optimization decisions autonomously. These are 2C functions at the database layer that the enterprise has Ceded without explicit classification. The parallel to AWS's implicit 2C (managed service decisions) applies, but OCI's implicit 2C is concentrated in the database rather than spread across managed services.

### ● Layer 3 (+1): AI Application Layer — The Value Plane

*AI-powered business capabilities — business logic, workflow automation*  
**Status:** Strongest Application-Layer Authority

**Oracle Fusion Agentic Applications** [DAPM: Ceded]  
22 specialized AI agents across HR, Finance, Supply Chain, and CX (GA March 2026). Outcome-driven, proactive, reasoning-based. Execute decisions within business processes by accessing unified enterprise data, workflows, policies, approval hierarchies, permissions, and transactional context. Built into Oracle Fusion Cloud Applications.

**ISV + Model Ecosystem** [DAPM: Delegated]  
xAI Grok, Cohere Command A, NVIDIA Nemotron, IBM Granite models. IBM watsonx Orchestrate agents on Red Hat OpenShift on OCI. SoftBank sovereign cloud with custom AI models on OCI. Oracle Analytics with AI-powered assistants.

**Gap Analysis:** Layer 3 is OCI's most distinctive position in the assessment series. Oracle is the ONLY vendor that owns a comprehensive enterprise application suite AND the AI infrastructure to power it. AWS provides infrastructure and some first-party applications (Q, Connect). Google provides infrastructure and productivity applications (Workspace). Neither owns ERP, HCM, SCM, or CX at Oracle's scale.

Fusion Agentic Applications (22 agents, GA March 2026) demonstrate what happens when the application vendor controls the AI infrastructure: agents that can access unified enterprise data, workflows, policies, approval hierarchies, permissions, and transactional context — without integration middleware, without API gateways, without cross-vendor authentication. This is not an ISV ecosystem (Dell's model) or a curated partner program (HPE's Unleash AI). This is first-party AI applications running on first-party infrastructure accessing first-party enterprise data.

Specific agent domains: workforce scheduling, payroll issue resolution (HR), financial process automation (Finance), supply chain optimization (SCM), and customer experience enhancement (CX). Each agent is pre-trained on Oracle's understanding of enterprise processes — borrowed judgment at the business logic layer.

The Oracle AI Data Platform for US Federal Government bundles OCI, Autonomous AI Database, and Enterprise AI with FedRAMP High and DISA IL4/IL5 authorization — extending Layer 3 into classified and sovereignty-constrained environments. The US Department of War agreement (May 2026) for AI on classified networks across 10 cloud regions at DISA IL2 through Top Secret demonstrates sovereign Layer 3 that no other hyperscaler matches in classification depth with equivalent application-layer integration.

Custom agent development uses the OCI Responses API (OpenAI-compatible) with managed hosting for OSS frameworks and MCP servers — the same runtime surface described at Layer 2B, consumed here as an application development platform.

The IBM partnership adds watsonx Orchestrate agents on OCI for HR use cases, extending the agentic ecosystem beyond Oracle's own applications. IBM Granite models via OCI Data Science provide additional model options.

The SoftBank sovereign cloud platform on OCI (May 2026) demonstrates Layer 3 for sovereign AI: SoftBank's own generative AI models running on OCI Enterprise AI with full data control within Japanese data centers.

The DAPM question: Fusion Agentic Applications are the deepest expression of Ceded authority in this assessment. The enterprise Cedes business logic, process automation, and decision-making to agents that Oracle built, Oracle trained, and Oracle hosts. The efficiency gains are real. The authority concentration is total.

**Borrowed Judgment:** The highest borrowed judgment of any Layer 3 in this assessment. Fusion Agentic Applications encode Oracle's interpretation of enterprise processes: what constitutes a complete talent review, how maintenance troubleshooting should proceed, when payroll exceptions should escalate. The enterprise inherits decades of Oracle's process design as embedded agent behavior.

Model providers (xAI, Cohere, NVIDIA) add model-level borrowed judgment. Oracle's application logic adds process-level borrowed judgment. The combination is unique: no other vendor in this assessment embeds both model judgment AND business process judgment into a single managed AI application layer.

DAPM Action 3 applies with maximum force: when you move off Oracle, what judgment doesn't move with you? Answer: the process logic, the data governance, the application state, the agent memory, and the transactional context — essentially everything above Layer 0.

---
*Layer2C · AI Infrastructure Decision Intelligence · The CTO Advisor LLC · thectoadvisor.com*