A plain chatbot answers questions. An agent is given a goal and figures out the steps to reach it — reasoning with an LLM, pulling the right data, and calling APIs to actually do the work, within your existing roles and security.

Think of it as the difference between "here's how to submit an expense report" (assistant) and "submit my expense report for this trip" (agent).

The agent loop (goal → reason → retrieve → act) shows up across Oracle's stack — the difference is where it runs, who owns it and what it can touch. Read top-down as the stack: applications and custom builds sit on top of the data and OCI platform layers below.

The layer most people meet first: agents built into ERP, HCM and SCM with AI Agent Studio. They live inside the apps, act through Fusion APIs, and run within each user's existing roles and security.

A staff member asks, "What's the status of PO 44821 and can you nudge the approver?" The agent reasons about the request, retrieves the purchase order from Procurement, checks the approval chain, and either sends the reminder or drafts it for confirmation — all within that user's permissions, without leaving the app.

Cloud security is a split: Oracle secures the cloud (physical data centers, hardware, and the managed services themselves), while you secure what you put in it — identities, access, data and configuration. Most incidents come from the customer side of that line, which is why the controls below matter.

OCI is the foundation, but it isn't the only place security happens. Each layer of the stack adds its own controls — defense in depth means a gap at one layer is caught by another. The layers below the platform inherit OCI's security and add their own.

Read top-down as the stack: apps sit on integration and data, all on the OCI platform. Each layer adds its own controls and has its own owner — a gap at one is caught by another.

All of it is administered from the OCI Console (or API/CLI/Terraform) within your tenancy — see the OCI administration page for who does this day to day.

Because this is an AI platform, the security model extends to how OCI AI & Generative AI services handle your data — the questions any organization asks before sending prompts and documents to a model.

Security is easier to reason about as threats and the controls that answer them — the why behind each pillar.

Threat on the left, the OCI control that answers it on the right.

And back out again — MuleSoft moves data in both directions, transforming formats and orchestrating the steps along the way.

MuleSoft's signature pattern: build reusable APIs in three tiers so integrations are modular, not point-to-point spaghetti.

MuleSoft splits into a control plane (the management layer MuleSoft hosts) and a runtime plane (where your integrations actually execute). They're managed together but run in different places.

MuleSoft and Oracle Fusion talk over HTTPS at the network / transport layer, secured by TLS. Traffic flows out through a load balancer and, for many integrations, both sides prove their identity with certificates (mutual TLS). That handshake is what keeps the connection trusted and encrypted.

Both directions — OIC connects apps through prebuilt adapters, maps the data between their shapes and orchestrates the steps, with the whole flow running on Oracle-managed infrastructure.

Every integration is a trigger, the work in the middle, and one or more invokes — assembled visually in the browser designer.

OIC integrations take a few shapes depending on what starts them.

Unlike a third-party iPaaS that splits a hosted control plane from a separately-run runtime, OIC is a single fully managed OCI service. Oracle runs both the design-time and the run-time; you don't provision, patch or scale servers.

Because both are Oracle, OIC ships a prebuilt Oracle ERP/HCM Cloud adapter that authenticates over OAuth / HTTPS and already understands Fusion's REST/SOAP services, business events and FBDI — no hand-built connection. The connectivity agent extends the same reach to private on-prem systems.