Oracle Puts Google's Gemini in Fusion and NetSuite Apps

Daniel Reyes Principal Engineer, AI/ML, YuSMP Group · Enterprise agents and model routing for US/EU teams

The short answer

What Oracle actually announced

Oracle and Google Cloud said they are extending an existing alliance so that Google's Gemini models become available across Oracle's enterprise software portfolio. The centerpiece is Oracle AI Agent Studio for Fusion Applications, Oracle's platform for building, connecting, and running AI agents using a mix of Oracle, partner, and third-party components. Oracle also plans to use Gemini for the embedded AI baked directly into Oracle Fusion Cloud applications — ERP, HCM, supply chain, and customer experience — and into Oracle NetSuite, its cloud business suite used by tens of thousands of companies.

Two specific models were named. Gemini 3.1 Flash-Lite is positioned for high-efficiency, price-sensitive workloads where cost per call matters; Gemini 3.5 Flash targets more complex reasoning and specialized jobs, including generating video and presentations. Oracle said it will select models based on the best price-performance for a given customer scenario — language that only makes sense if more than one model is on the menu. For teams that build enterprise agents rather than buy them, that framing is the interesting part, and it maps directly onto how our AI agent development team scopes multi-model systems.

Why the multi-model roster is the real story

Gemini does not arrive in Oracle's apps alone. It joins a roster inside AI Agent Studio that already includes models from OpenAI, Anthropic, Cohere and Meta. That is the shift worth noticing. A year ago, picking an enterprise platform often meant inheriting its house model. Now Oracle — which has its own AI ambitions and runs Google, OpenAI, and Anthropic models side by side — is competing on choice, letting customers route each agent to whichever model fits the task and the budget.

Gemini reaches Oracle's stack through Google Cloud's Vertex AI, which means a model family many teams already use is now reachable from the application layer without a bespoke integration. The strategic read is that no single lab is going to own enterprise AI. The market is splitting the model layer from the application layer, and that is broadly good for buyers: it is what keeps pricing competitive and reduces the leverage any one provider holds. Regulators are watching the same dynamic from the other side — France recently flagged lock-in risk when three vendors held 84% of the AI agent market — which is one more reason to design so no single model is load-bearing.

Embedding AI into the systems of record

The NetSuite and Fusion piece deserves its own attention. Embedding a model into ERP, HR, finance, and supply-chain apps is different from bolting a chatbot onto a website. These are systems of record: they hold payroll, customer data, orders, and ledgers. When a model can read and act inside them, its effective permissions become whatever those apps can reach — and its outputs can trigger real business actions.

That makes governance a first-class requirement, not a follow-up. Before an embedded agent touches production data, a team needs to know where inference runs, what is logged, and how the model's access maps onto existing least-privilege boundaries. For regulated sectors like FinTech and healthcare, "the AI summarized data it should not have seen" is precisely the failure auditors care about. The convenience of AI baked into the tools people already use is real; so is the requirement to scope what that AI can see before you switch it on.

What it means for US & EU software teams

Strip away the partnership choreography and Oracle's move hands engineering leaders two concrete instructions. First, on architecture: assume enterprise AI is multi-model and build for it. Route model calls through an abstraction layer you own, so switching or mixing providers is a configuration change rather than a rewrite, and keep prompts, tools, and evaluations portable across models. This is the same optionality that our GenAI integration work builds into custom apps, and it is far cheaper to design in now than to retrofit after a provider's price or capability shifts.

Second, on governance: if you are embedding agents into business systems — whether Oracle's or your own enterprise software — treat the rollout as a data-access exercise. Inventory what each agent can reach, enforce least privilege before you scale, and log what models read and do so you can answer an auditor's "what did it touch?" The model you pick will keep changing; the discipline around what it can see should not.

There is a strategic read too. Oracle putting a competitor's model inside its own apps confirms that the model layer is becoming a commodity input the application vendors compete to route well. For teams building on top, that is a reason to hold leverage: keep your systems model-agnostic, benchmark providers against your own tasks rather than public leaderboards, and treat any single model — Gemini included — as replaceable.

A model-agnostic AI checklist

Here is the shippable version — run it as a scoping exercise this quarter, while the model layer is still shaking out.

1. Route through an abstraction. Put every model call behind an interface you control so provider and version are config, not code threaded through the app.
2. Benchmark on your tasks. Evaluate candidate models against your real prompts and data, not public leaderboards; price-performance is per-scenario, as Oracle's own framing admits.
3. Keep prompts and tools portable. Store prompts, tool definitions, and evals separately from any one SDK so a swap is a rebind, not a rebuild.
4. Map data access per agent. For each embedded agent, record what data and actions it can reach inside the system of record before it goes live.
5. Enforce least privilege first. Tighten roles and scopes so an agent cannot surface or change what it should not, even if the model misbehaves.
6. Confirm residency and logging. Know where inference runs and what is retained, and check it against GDPR and any sector rules for the data involved.
7. Plan the fallback. Have a second model your critical agents can run on, tested, so a price change or outage is a routing decision rather than an incident.

None of this is a bet against Gemini — the models Oracle named are strong, and Flash-Lite economics are genuinely useful for high-volume agents. But the strategic signal from the announcement is already clear: enterprise AI is multi-model, the application vendors are competing to route models rather than to own one, and the part that touches ordinary software teams — abstraction, benchmarking, and governance — is buildable today. Build it.

Frequently asked questions

Sources

Oracle — Oracle to Make Gemini Models Available to Thousands of Enterprise Applications Customers, 30 July 2026
IT Pro — Oracle integrates Google's Gemini AI models into enterprise apps, 31 July 2026
The Next Web — Oracle put its cloud rival's AI inside its business apps, and the stock jumped 8%, July 2026