Fusion Claw Is Arriving in 26D. Here Is What We Are Doing Before "Turning it On".

Fusion Claw Is Arriving in 26D. Here Is Why We Are Not Turning It On Just Yet.

Visible is not the same as approved. The governance conversation to have before your first Claw run.

Oracle associated Fusion Claw with 26D. Customers in the early access cohort should see it first, and everyone else gets it with their cohort's release.

One practical detail: Oracle told us some of the capability did not make the initial general availability build, so an environment on 26D may still need a weekly CWB update. Oracle offered to look at our environment with us and confirm whether the required build is present. I would recommend asking for the same.

The model question

Fusion Claw requires frontier models. Oracle told us plainly that GPT-OSS, the model it hosts at a zero multiplier, is not capable enough for it. And if you use it, it will call a frontier model hosted by OpenAI.

If your organization approved Fusion AI on the basis of Oracle-hosted models, Fusion Claw is a new conversation, not a footnote to the old one.

There was a useful nuance here that I suspect many people have not considered. Even GPT-OSS runs outside your Fusion tenancy. Oracle hosts it in OCI data centers in Chicago and Frankfurt, and Fusion calls out to it. So the real question was never inside the tenancy versus outside it. It is Oracle-operated versus third-party operated.

For many organizations, there is precedent. Plenty of us already use frontier models hosted by third parties through other tools. Precedent makes the review easier. It does not make it unnecessary.

Oracle has documentation describing how data flows to LLMs and told us it has used it to help other customers, including defense and government customers, work through the same concerns. Get it into your review early.

What you can point to in that review

The good news is that Oracle has given security and architecture teams quite a lot to work with. Based on what was described to us:

·        User-token enforcement. All data access and actions use the invoking user's token and functional rights.

·        Layered roles. Users need the role for each agent and for the agentic app. App access does not grant missing agent access.

·        Capability scoping. Authors decide which agents and capabilities a Claw can use.

·        No credential custody. The Claw plans and orchestrates. Agents execute.

·        Private runtime. Generated code runs in a private container hosted by Oracle in OCI.

·        Configurable retention. Session state is kept for up to 90 days, and you can set that period.

·        Tenant-specific learning. Self-learning stays within your tenant and is tied to the specific outcome.

·        Budgets and a kill switch. Agent Studio in 26D supports budgets at environment, app, and agent level, plus a kill-all control.

What we are still asking

We sent Oracle a written list of follow-up questions. The ones I expect any review board to ask:

·        Can an administrator disable Claw outcomes at the tenant, environment, or role level, rather than relying on instruction alone?

·        How is the user's identity handled across sessions that run for hours or days, and what happens if their roles change mid-run?

·        What does the Outcome Receipt described in the announcement contain, how long is it kept, and can it be exported for audit?

·        Is code generated by the Claw logged and reviewable?

·        Where is business data retrieved into the container held, how is it encrypted, and how is it purged?

·        Which models are available, and can a specific model and version be pinned?

I will share what we learn.

Where to experiment instead

One of our architects asked whether we could get a separate Fusion demo environment for this kind of work. It has historically been difficult to get one. Oracle told us there is now a SKU for it.

That matters more than it sounds. Even an internal sandbox with elevated access is still constrained by your own data and your own approvals. For a capability like this, a greenfield environment is the right place to learn how it behaves before it ever touches yours.

The sequence we landed on

1.      Confirm with Oracle whether your environment has the required build, and treat visibility as information rather than permission.

2.      Get Oracle's LLM data-flow documentation in front of your security and architecture reviewers.

3.      Decide who is allowed to author outcomes and who is allowed to run them, and design the roles to match.

4.      Set budgets in Agent Studio before the first run.

5.      Experiment in a separate demo environment.

6.      Only then move toward a pilot with your own data.

If you are heading to Oracle AI World in Las Vegas, October 25 to 28, Oracle pointed us to the keynotes, a roadmap session from the product team, and the Fusion Claw Meet the Experts session. We will be there with a lot of questions.

Based on a working session between our team and Oracle's Fusion AI product management group in October 2026, combined with Oracle's public announcement of Fusion Claw on September 29, 2026 and Oracle's public documentation. Statements about availability, hosting, and controls reflect that conversation and are not a substitute for Oracle's published guidance. Confirm specifics against your own environment and your Oracle account team. Views are my own.

Fusion Claw and AI Units: A New Rate Card, and Your Agents Still Bill Separately

Fusion Claw and AI Units: A New Rate Card, and Your Agents Still Bill Separately

What changes in the cost model when a Claw runs, what does not, and the budget controls you can use today.

In August I wrote about making sense of Oracle AI units. The insight that cleared things up for me then was simple: models Oracle hosts carry a zero multiplier, and models Oracle has to call out to are where charging happens.

Fusion Claw adds a new wrinkle to that picture, and one of our team members asked about it during our session with Oracle's Fusion AI product management team. Here is what we learned.

Same meter, new rate

The meter does not change. An AI unit still represents the tokens processed combined with the complexity of the type of action. Today, nearly everything is a general action, which is the cheapest category.

What is changing is the set of rates. Oracle is publishing new rates for new capabilities: one for document generation, one for audio and video generation, and a new rate card it calls Frontier for Claw work.

The Frontier multiplier was not confirmed in our session, so I am not going to guess at one here. Watch for it on the rate card.

What the Frontier rate covers

For a Claw, consumption is mostly the orchestration work: the frontier model doing the planning and reasoning. It is based on the tokens processed, and it is independent of the agents.

Your agents still bill

This is the part worth getting right in a forecast.

When a Claw asks an agent to execute something, that agent is still doing its own work, using its own model, under the rate for the type of action it performs. The Claw does not absorb or replace that consumption.

So the cost of a Claw run is two things added together: the Claw's own orchestration at the Frontier rate, plus whatever each underlying agent consumes along the way.

That is consistent with what Oracle told us in August about agentic apps: same meter, more moving parts. A Claw is one more moving part, on a different rate.

Why the hosted model escape hatch does not apply

In my earlier post I suggested starting any Fusion AI cost model by working out which use cases genuinely need a premium model, and assuming the rest can run on Oracle-hosted inference at no incremental cost.

That framing still works for agents. It does not work for the Claw itself. Oracle told us that GPT-OSS, the hosted model with the zero multiplier, is not capable enough for Fusion Claw, and that frontier models are required.

Fusion Claw is inherently premium. The question shifts from which model a Claw should use to whether a given outcome justifies a Claw at all, or whether a standard agentic app interaction will do.

What you need to have

Fusion Claw is accessed through agentic apps, so you need the agentic app SKU. That SKU includes an allotment of AI unit credits, and if your usage grows beyond it, you buy additional AI units for that consumption.

As before, I am deliberately not quoting figures. Have that conversation with your account team early.

Budget controls you can use in 26D

One of our architects asked the question every platform owner is thinking: what happens when someone kicks off something ambitious and it runs for nine hours straight?

The answer was partial but useful. In Agent Studio in 26D you can set AI unit budgets at three levels:

·        An entire environment

·        An individual agentic app, which includes its Claw usage

·        An individual agent

You can also tell it what to do when a budget is reached: stop execution, or let the current work finish. And there is a kill-all button. As it was put to us, kill -9 for the Unix users.

What is not there yet:

·        User-level budgets. You can see what individual users are consuming, but you cannot set a budget per user.

·        Events or APIs for budgets. These controls live in Agent Studio today.

Oracle described work in progress on both fronts: exposing operational observability data through something like an OpenTelemetry stream so you can monitor it in your own systems, and APIs to set budgets, stop agents, and manage user access from the outside. Until those land, budget management happens in Agent Studio.

What I would do

Set budgets before the first Claw run, not after the first surprise. At minimum, put an app-level budget on every Claw-powered agentic app you enable, and an environment-level budget on anything that is not production.

And apply the same discipline I argued for in August, one level up. Before reaching for a Claw, be clear on why the outcome needs long-running, frontier-model reasoning rather than a point-in-time agentic app interaction.

What I am still watching

·        The published Frontier multiplier.

·        Whether a single Claw run can be broken down into its Frontier consumption and its underlying agent consumption, which is what a finance conversation will ask for.

·        Whether the ROI dashboard in Agent Studio reports on Claw outcomes the way it does for agents.

Based on a working session between our team and Oracle's Fusion AI product management group in October 2026, combined with Oracle's public announcement of Fusion Claw on September 29, 2026 and Oracle's public documentation. I am reporting a conversation, not a contract. Product details and pricing mechanics change between releases. Confirm specifics against your own environment, rate card, and Oracle account team. Views are my own.

What Actually Happens When a Fusion Claw Runs

What Actually Happens When a Fusion Claw Runs

The harness, the models, the private container, the memory, and the boundaries that hold it all in.

The word Claw comes with baggage. The open agent harnesses that inspired the name earned a reputation for broad reach: a shell, a file system, a repository, and whatever else you hand them.

So the first thing I wanted to understand about Fusion Claw was not what it can do. It was what it cannot do, and what is actually running underneath it.

Oracle's Fusion AI product management team walked us through it in some detail. Here is the picture as it was described to us.

The runtime

When a Claw runs, Oracle sets up a virtual command line environment and gives the agent harness a controlled set of tools inside it.

·        The primary harness is based on the open source Codex harness.

·        Frontier models from OpenAI provide the planning, analysis, and deep research capability.

·        Skills live inside the virtual file system. Oracle provides some, and authors can add their own to describe how a particular outcome should operate.

Oracle's announcement also names Gemini alongside OpenAI, with support for additional frontier models planned over time. In our session, the discussion centered on OpenAI.

The private container

Each Claw runs in a private virtual container that Oracle hosts in OCI, specifically within its Fusion Spectra service, and that only your company and your users can access.

The lifecycle is sensible:

·        The container is live while the work is running.

·        When the session pauses or completes, Oracle stores the session state and shuts the container down.

·        If you resume, the container is rehydrated from that stored state.

Session information is retained for up to 90 days, and that retention period is something you can set yourself. Keeping it around is what lets you restart a session, continue it after the Claw has finished, or take it down a different path with the same context.

This is also where generated code runs. When a Claw writes code to analyze a large data set, that code executes inside the container, not directly in Fusion.

What it can reach

The Claw's scope is set by the agentic app it belongs to. Authors decide which parts of the app are exposed to the Claw through a capability layer, effectively a subset of the app, along with the skills and guardrails that govern how it pursues the outcome.

Oracle gave two concrete examples of what that means in practice. A Claw will not go set up a REST call outside the domain of its agentic app. And unlike general coding assistants, where you might give the agent access to a Git repository, Fusion Claw does not get that kind of open-ended access. It is limited to the agents and capabilities you make available to that particular outcome.

Whose identity it uses

All data access and all actions happen with the invoking user's token. The Claw only fetches data that user can see, and only takes actions that user has the functional rights to perform.

Combined with the point I made in my previous post, that the Claw plans and orchestrates while the agents execute, this means the Claw itself never holds credentials.

Roles, in layers

One of our architects asked the question every security team will ask: if I can use a Claw, do I inherit access to every agent it can call?

No. Access is layered:

·        A user needs the role for an individual workflow agent to invoke it, or for it to be invoked on their behalf.

·        The agentic app has its own role access, and that is where access to the Claw is set, because the outcome is tied to the app.

·        If a user has access to the app but not to one of its agents, that agent simply does not participate on that user's behalf.

App access does not paper over missing agent access. That is the answer I was hoping for.

Memory and learning

As a Claw works through a long-running session, it keeps notes to manage memory and context. Across runs, it applies what Oracle described as procedural or functional learning, so later runs of the same outcome can make fewer LLM calls, use fewer tokens, and produce better results.

Another of our architects asked where that learning lives. The answer was direct: it is tenant-centric and specific to the Claw outcome. It is not a shared, Oracle-wide learning layer.

Why it took this long

I said on the call that the open Claw concept has been around for a while, and that the real challenge was never the concept. It was constraining it.

Oracle agreed. Their point was that no customer wants a Claw going wild in their environment and picking up permissions it is not supposed to have, and that this is a deliberately constrained implementation built to work within Fusion security. Having heard the details, I believe them.

What we did not cover

A few things I still want to understand, and which are now with Oracle as written follow-up questions:

·        What the Outcome Receipt described in the announcement contains in practice, where it is stored, and whether it can be exported to the systems we already use for audit.

·        Whether code generated by the Claw is logged and reviewable after the fact.

·        How the user's identity is handled across sessions that run for hours or days, including what happens if that user's roles change mid-run.

·        Where business data retrieved into the container is held during the retention period, and how it is purged.

None of those are criticisms. They are the questions an audit or architecture review board will ask, and I would rather have them answered before anyone needs them and I'll report back with what we find!

Based on a working session between our team and Oracle's Fusion AI product management group in October 2026, combined with Oracle's public announcement of Fusion Claw on September 29, 2026 and Oracle's public documentation. Product details and pricing mechanics change between releases. Confirm specifics against your own environment, rate card, and Oracle account team. Views are my own.

Fusion Claw Does Not Replace Agentic Apps. It Gives Them a Longer Reach.

Fusion Claw Does Not Replace Agentic Apps. It Gives Them a Longer Reach.

Where Oracle's newest Fusion AI capability actually sits relative to Agent Studio, workflow agents, and agentic apps.

In August I wrote about sorting out where AI Agent Studio ends and agentic apps begin. A few weeks later, on September 29, Oracle announced Fusion Claw, and my feed has had something new about it nearly every day since.

The reaction on my team was the same one we had last time: what is this, and what does it do to everything we just learned?

So we went back to Oracle's Fusion AI product management team and asked exactly that.

The short answer

Fusion Claw is not a new place to build agents, and it is not a replacement for agentic apps. It is a governed runtime that an agentic app can use for a specific class of work: long-running, outcome-driven, and often data-heavy.

When I summarized it back on the call as a governed agentic execution runtime that agentic apps can leverage, rather than something doing work on its own, Oracle agreed with the framing. They added one refinement that turns out to matter a great deal, and I will get to it in a moment.

Oracle also confirmed what the name suggests. The architecture and concept are inspired by OpenClaw, NemoClaw, and similar approaches. What they built around that concept is considerably more governed, which I will cover in a separate post.

The hierarchy, restated

The cleanest way to understand Fusion Claw is as a third layer on top of the two we already had.

·        Workflow agents perform a specific, well-defined task. The example used in our session was taking a purchase order from an email and turning it into an invoice.

·        Agentic apps combine those agents into a team with shared context and memory, coordinated by an orchestrator, working toward a broader business outcome in near real time.

·        Claw outcomes are presented inside an agentic app as an explicitly defined business goal, described in natural language and powered by a skill that tells the Claw how it may use the agents and capabilities the app exposes.

One of our architects pushed back during the call and asked whether we had the direction backwards. The clarification was helpful. Agents are designed to work independently. The agentic app combines them into a team. The Claw is then presented through that app as an outcome. It can orchestrate against the team, but its scope is the app.

The refinement: the Claw plans, the agents execute

This is the part I would underline.

The Claw does the planning and orchestration. When it is time to actually do something in Fusion, it calls back through the agentic app to the agents to perform the execution. The Claw itself does not hold authentication credentials and does not directly perform authenticated business transactions.

That separation shapes how you should think about governance, and it is why I keep describing this as a runtime rather than a new kind of agent.

What it adds on top of an agentic app

One of our architects asked the obvious question: agentic apps already orchestrate agents, so what does a Claw add? Oracle's answer came down to four things.

1.      An explicit business goal. In an agentic app, the capability is implicit in the agents you selected and the tasks users ask of them. With a Claw, the author or user states a specific outcome, and progress is tracked toward completing it.

2.      Long-running sessions. A Claw session has a heartbeat. It can wake up, continue working, and make progress toward the outcome over minutes, hours, or days, incorporating feedback from the user where needed. Oracle compared it to deep research tools where you hand over a large ask and it works through a plan.

3.      Large data and generated code. The Claw can retrieve authorized business object data, potentially millions of records, and write code behind the scenes to analyze it. That code runs in a private container rather than directly in Fusion. The example offered was evaluating supply chain routes ahead of an upcoming event or a supplier shortage. Oracle was clear that this is not something an agentic app does out of the box.

4.      Self-learning. The runtime keeps notes and memory as it works, so subsequent runs of the same outcome can use fewer LLM calls and fewer tokens while improving quality. That learning is tenant-specific and tied to the particular outcome.

This connects directly to something I flagged in August. I wrote then that agentic apps enforce a 60 second response limit and that it is a real design constraint. Oracle described the agentic app interaction as point in time: to see updated state, you invoke the app, and then you tell it what to do next. When I asked whether long-running reasoning beyond that point-in-time interaction was the real value of the Claw, the answer was yes. Fusion Claw is what Oracle built for work that does not fit that shape.

Where you will actually see it

There is no separate Claw interface. Inside an agentic app there is an outcomes section, and available Claws are presented there as business goals. An authorized user picks one and starts it.

Behind that, the author defines the outcome: the skills, the capabilities it can use, the security constraints, and the guardrails. That package is what gets instantiated into a container when an authorized end user kicks it off. Authors decide what the Claw can do. Users with the right roles get to run it.

One of our team members asked specifically whether this created a separate path in. It does not. The agentic app is the way in.

What Oracle shipped

Oracle's announcement introduced 25 Claw-powered agentic applications, part of a portfolio of 75 agentic applications. The examples it called out span the suite:

·        Ledger for close readiness and accounting exceptions

·        Workforce Staffing for staffing plans that balance skills, availability, labor rules, and cost

·        Shipping Consolidation for modeling consolidation alternatives in supply chain

·        Account Territory Growth Plan for sales territory and opportunity allocation scenarios

The announcement describes each outcome as starting with a frontier model that reasons and plans, with deterministic enterprise computation handling execution at scale. It also describes a range of automation levels, from quick assistance to governed full auto within explicitly delegated authority.

Where this leaves your investment

My advice from August holds, and if anything it is stronger now.

A Claw is only as capable as the agents and capabilities its agentic app exposes. Well-built workflow agents matter more with Fusion Claw, not less. Agent Studio remains the foundation.

Build workflow agents first. Assemble them into agentic apps once you have components worth assembling. Then look at which of your outcomes genuinely need long-running, data-heavy work, and those are your Claw candidates.

What I am still watching

·        How much outcome authoring is open to customers on their own agentic apps compared with the Oracle-delivered Claw-powered apps, and how customer changes to delivered apps carry forward through quarterly updates.

·        How the governance terms in the announcement, the Enterprise Operating Envelope, the Outcome Trust Harness, and the Outcome Receipt, map to what you actually configure. We discussed the outcome definition in detail. We did not get into the Outcome Receipt.

Both are on the list of follow-up questions we sent to Oracle. I will write about the answers when I have them.

Based on a working session between our team and Oracle's Fusion AI product management group in October 2026, combined with Oracle's public announcement of Fusion Claw on September 29, 2026 and Oracle's public documentation. Product details and pricing mechanics change between releases. Confirm specifics against your own environment, rate card, and Oracle account team. Views are my own.

OCI Limits, IAM Policies, and Identity Domain Disaster Recovery: What We Learned From Oracle

OCI Limits, IAM Policies, and Identity Domain Disaster Recovery: What We Learned From Oracle

Soft limits keep you out of trouble, hard limits keep moving, and there is one checkbox worth verifying today.

In the same session with Oracle's OCI identity team that I wrote about in my last post, one of our architects asked a question I suspect a lot of enterprise customers carry around quietly. Setting aside divestitures and business unit boundaries, are there scale limits that should push us toward multiple tenancies?

It is a fair question. Policy limits in particular had shaped some of our earlier decisions. The answer, and the conversation it opened up, covered service limits, policy design, and identity disaster recovery. All three are worth writing down.

Soft limits and hard limits are different things

Oracle drew a clean distinction between the two.

Soft limits are bumpers. They exist to keep you from getting yourself into trouble. A default cap on how many VMs you can launch is not there because Oracle cannot run more. It is there because a sudden jump to a very large number usually means something went wrong, a runaway script or a mistake, and the next call is usually a refund request. Need more? Ask, and the limit goes up.

Hard limits are architectural. They exist because going past them could affect you or other tenants. The example given was vaults backed by dedicated hardware security module capacity. A region has a finite pool, and some code paths were written with an expected upper bound. Asking for a handful more is routine. Asking for an unusually large number in one tenancy becomes a real conversation.

Two things stood out to me. Oracle tracks hard limits proactively and works with customers before they reach them. And hard limits are not static. Oracle continually evaluates them and raises them as customers demonstrate a need.

For perspective, Oracle noted that some customers run thousands of VMs across dozens of regions and move enormous volumes of data continuously. A typical enterprise application footprint, ours included, is nowhere near the hard limits they see elsewhere.

The policy limit story is a good example

IAM policy limits used to be one of those hard limits, and the old tenancy-wide ceiling was tight for large organizations. Customers told Oracle they needed more. Oracle worked with them, changed how the policy engine evaluates policies, and the old ceiling no longer applies the way it once did. The limit is now applied along the compartment hierarchy rather than as a single flat number for the tenancy.

The practical consequence is that placement matters. Put everything at the root and you concentrate your budget in one place. Put policies in the compartments where they are actually needed and the limit largely stops being a constraint. Check the current OCI documentation for exact numbers, because they have moved and will move again.

Oracle also shared, with the appropriate grain of salt for anything roadmap-related, that a significant effort is underway to raise policy limits from the hundreds into the thousands. Their suggestion was to understand where you are and where Oracle is heading before investing heavily in reducing policy counts on a short timeline.

The default policies are simple on purpose

If you have several Fusion pods, you have probably noticed that each identity domain arrives with its own set of policies at the root of the tenancy. Multiply that across many domains and the root gets crowded quickly.

Oracle was direct about why those policies look the way they do. They are intentionally simple, typically one group, one resource type, one location per statement. That makes them easy to read and reason about, and they were designed with typical customers in mind rather than those running a large number of identity domains.

Two things follow from that:

·        They can be consolidated. Multiple groups and resource types can be combined into fewer statements while still expressing least privilege. Our team has worked through this. It is very doable, though it takes care.

·        Most of them do not have to live at the root. A small number of tenancy-level permissions do, but most resources, and the policies governing them, can live in compartments.

Oracle offered two perspectives that I think are both right. First, simple policies have value. If they work for you, do not rush to optimize them away just to reduce a count, especially with limits increasing. Second, from a security standpoint, a crowded root is not ideal. The more that lives at the root, the more there is to watch. Our own cleanup effort is aimed at the second point without giving up the readability of the first.

Oracle also offered to walk through the consolidation with us, which I appreciated.

Identity domain disaster recovery: go check the box

This is the part of the session I would most encourage other customers to act on.

A tenancy's Default identity domain is homed in the tenancy's home region. If disaster recovery is enabled, and a region-level disaster takes the home region down, Oracle is responsible for bringing that domain up in the paired disaster recovery region so you can keep managing your resources elsewhere.

The details matter:

·        The domain comes back with the same URL and hostname.

·        The IP address may change.

·        Client IDs, secrets, and the applications relying on the domain continue to work.

·        It does not cost anything extra.

·        It only happens if the option is enabled. If it is not, Oracle cannot move the domain.

That last point is why I say go check. It takes minutes to confirm, and you do not want to find out during an incident.

HA and DR are not the same thing

Oracle made a distinction that is easy to blur. Within a region, identity domains run as highly available microservices. Disaster recovery to another region is something different, reserved for serious, region-level events expected to last hours or days.

A 20 or 30 minute disruption will usually not trigger a regional failover, because relocating a domain takes time and would likely take longer than the disruption itself. That is a sensible trade-off, and it should shape your expectations and your runbooks. Identity DR protects you from catastrophe, not from every hiccup.

Make sure identity lives where your workloads live

One more design point came out of this. Identity domains serve the workloads that depend on them. If a domain is homed in a different region from the applications it supports, which happened with some older IDCS provisioning, an outage in the identity region can affect production running in a perfectly healthy region. Oracle acknowledged the pattern and agreed it is something to solve for as part of a longer-term identity plan.

My own addition, not something Oracle said: if you have firewall rules or allowlists tied to IP addresses for identity endpoints, revisit them. Oracle's DR commitment is built around the hostname. Build around the hostname too.

A short checklist

1.      Confirm disaster recovery is enabled for the identity domains you depend on.

2.      Confirm each domain's home region aligns with the region where the workloads it serves run.

3.      Replace IP-based dependencies on identity endpoints with hostname-based ones.

4.      Inventory the policies at your root. Separate the few that truly must be there from those that can move to compartments.

5.      Consolidate where it improves clarity, not only to reduce a count, and watch Oracle's limit increases before committing to a large reduction effort.

6.      If you think you are approaching a hard limit, talk to Oracle early. They would rather hear from you before you hit it.

They do not stand still

Near the end of the session, someone on our side observed that there always seems to be something new coming in OCI. Oracle's reply was simple: they don't stand still.

That feels like the right note to end on. Several constraints that shaped enterprise OCI designs a few years ago have already been lifted, and more are on the way. Design for today's limits, but revisit the assumptions behind your architecture regularly. Some of the reasons you split things apart may not apply anymore.

Based on a working session between our team and Oracle's OCI identity team in September 2026, combined with Oracle's public documentation. Product behavior, limits, and licensing change over time. Confirm specifics against your own environment and your Oracle account team. Views are my own.

One Tenancy or Many? What Oracle Told Us About Tenancies, Identity Domains, and Fusion

 One Tenancy or Many? What Oracle Told Us About Tenancies, Identity Domains, and Fusion

A tenancy is a hard boundary by design. Once that clicks, most of the other decisions get easier.

If your organization has been on Oracle Cloud for a while, there is a good chance your footprint did not arrive all at once. Fusion pods came first, or PaaS services did. A new module showed up with its own activation email. Somebody made a reasonable call at the time, and a few years later you are looking at several tenancies, a growing list of identity domains, and a question nobody can answer in one sentence: where should the next thing go?

That is where our team is. We recently sat down with Oracle's OCI identity team to talk less about how we got here and more about where Oracle is heading, and how a customer should think about tenancies and identity going forward. I want to write down what I took away from it.

Start with the vocabulary

Oracle Cloud identity runs on OCI IAM with identity domains. If you have been around long enough to remember IDCS, identity domains are where that capability lives now.

When you get a tenancy, you get one identity domain automatically, the Default domain. It exists so you can sign in to the tenancy, manage it, and do everything else an administrator does there. You can create additional domains for other purposes.

When you buy Fusion, things get more interesting.

Why every Fusion pod has its own identity domain

Buy three Fusion pods for development, test, and production, and you get three identity domains, one pre-wired to each pod, in addition to the tenancy's Default domain.

That surprises people at first. It seems like a lot of identity. The reasoning is sound, and the example Oracle used made it click for me.

Picture a developer configuring a timesheet approval flow. To prove it works, they need to sign in as the employee who submits the timesheet, then the manager who approves it, then the director above that. In a development environment that usually means a set of test users the developer controls. You cannot wire that environment to your production corporate identity provider, because those test personas do not, and should not, exist there.

So each pod is its own island of identity. Development gets test identities. Pre-production connects to your pre-production identity system. Production connects to production. Not every customer works that way, but it is a very common pattern and Oracle has to support the customers who do.

The greenfield picture

This is the part I found most clarifying. If you provision PaaS services to support a Fusion environment, such as Visual Builder, Integration, Analytics Cloud, Fusion Data Intelligence (formerly Fusion Analytics Warehouse), or Autonomous Database, you provision them in the same tenancy using the same identity domain as the pod they support.

Do that, and they are pre-integrated. No extra trust to set up, and no federation to maintain between services that are supposed to behave as one environment.

The picture Oracle described for a customer starting today looks like this:

·        One tenancy, with compartments per environment.

·        A development compartment holding the dev Fusion pod and the dev instances of Integration, Visual Builder, and whatever else supports it, all sharing the dev identity domain.

·        A pre-production compartment that mirrors it, and a production compartment that mirrors that.

·        Integrations, extensions, and configuration promoted through those environments the way you would expect.

Oracle was candid that most long-standing customers, us included, do not look like this, because services were provisioned at different times for reasons that made sense then. It is a target state, not a judgment on anyone's current state. Getting from here to there is its own conversation, and one Oracle offered to work through with us.

Everything Oracle runs is on OCI

One comment reframed things for a few people in the room. We tend to talk about moving PaaS "into the same OCI as Fusion" as if Fusion recently arrived there. It did not. Fusion has run on OCI for a long time, as does essentially everything Oracle offers, homegrown or acquired.

What has changed is visibility. Services are progressively surfacing in the Oracle Cloud console at cloud.oracle.com, which is the console for all of Oracle Cloud rather than only infrastructure. When people say "OCI" they usually mean compute, storage, and networking. The console is that, plus PaaS, plus SaaS, and Oracle's direction is that everything you subscribe to shows up there.

It also explains how so many of us ended up with split tenancies. Fusion pods originally existed without any tenancy at all. You signed a contract and consumed your environments from their URLs. When tenancies were introduced a few years ago to give customers a way to manage everything, Fusion pods were attached to one, and PaaS services bought earlier often lived in another.

A tenancy is a box, on purpose

The question our team was most eager to ask: could we simply move things between tenancies to consolidate?

The short answer is no, and the reason is a good one. When a tenancy is created, keys and certificates are generated for it and held in hardware security modules. Tenancies are a hard partition, and Oracle has intentionally not built tooling to move resources from one to another. A compute instance, a block volume, an Integration instance, a Fusion pod: whatever is created in a tenancy stays in that tenancy.

What you can do is rebuild and migrate:

·        Export and import configuration, such as Integration projects, users and groups, and API gateway definitions.

·        Use Terraform to recreate infrastructure and the PaaS service instances themselves.

·        Use the standard environment migration and refresh tooling where it applies.

Plan for the fact that a rebuilt instance is a new instance. It will have a new URL, and anything that pointed at the old one needs to change.

I appreciated the framing. A tenancy is a box that things can come into and go out of, but cannot slide sideways between. Once you accept that, "move" stops being the right word, and the real questions become whether a rebuild is worth it and where the new thing should be born.

Where new subscriptions land

That leads to the most practical takeaway I would pass to anyone buying something new from Oracle.

When you subscribe to a new Fusion service, the person who placed the order receives an activation email. It asks where you want the service to go: an existing tenancy, or a new one.

Expanding an existing subscription is different. If you have three pods and add two more, the new ones are provisioned alongside the existing ones in the same tenancy.

Oracle's direction is that SaaS services live in a tenancy. For a specific product, confirm how activation works before you assume. Oracle sells a lot of SaaS, and not every service follows exactly the same path today.

My advice is to treat that activation click as an architecture decision, not an administrative step. Decide where a new service belongs before the email arrives. We have made that call deliberately in the past, including once choosing a new, isolated tenancy on purpose, and I was glad we had talked it through first.

So, one tenancy or many?

Oracle's position was balanced. You can put everything in one tenancy, and for a smaller organization a single tenancy is ideal. There are also legitimate reasons larger enterprises do not:

·        Business units that operate independently, or could be divested someday. Separating a tenancy after the fact is hard, so if a unit might leave, it probably belongs in its own.

·        Administrative separation, where different groups need clearly distinct control.

The counterpoint Oracle offered is the one I keep coming back to. If it is your HR system and everything that supports it, and you are buying it from Oracle, it makes sense to keep it together unless you have a specific reason not to. The same applies to ERP.

A separate tenancy also comes with work. A few things our team noted you take on:

·        Network connectivity. A new tenancy does not automatically share your existing FastConnect. Remote peering or a hub-and-spoke design can bridge it, but it has to be designed.

·        Identity wiring. Inside one tenancy, the same identity flows naturally across Fusion, Integration, analytics, and the rest of an environment. Across tenancies, you build and maintain that federation yourself. This matters more every release, especially as capabilities like AI Agent Studio span product families and benefit from a common identity.

·        Commercial alignment. Subscriptions and credits are associated with a tenancy, so how you consume services in a new one is a conversation for your account team.

A word on identity domain types

One more piece helps explain the design. The Default domain in a tenancy is a Free domain type intended for managing the tenancy, and its user limit reflects that purpose. The identity domain delivered with a Fusion pod is an Oracle Apps domain type, provided as part of the Fusion subscription. It covers what your users need to access Fusion and the services supporting it in the same tenancy.

If you still carry bring-your-own licensing assumptions from older IDCS or on-premises identity deployments, it is worth revisiting them. For the Fusion use case you may not need them. If you plan to use a Fusion identity domain well beyond supporting Fusion, have that licensing conversation with your account team up front.

What I am taking away

·        Design toward the target state: one tenancy per logical platform, compartments per environment, and supporting PaaS provisioned against the same identity domain as the Fusion pod it supports.

·        Stop saying "move." Resources do not move between tenancies. Plan rebuilds with export, import, and Terraform, and plan for new URLs.

·        Decide where new services land before the activation email arrives.

·        Create a new tenancy when there is a genuine boundary, such as an independent or divestible business unit, and budget for the networking, identity, and commercial work that comes with it.

·        Keep identity consistent within each environment. The more your Oracle products work together, the more that pays off.

We closed the session with a standing offer from Oracle to go deeper on specifics once we have worked out what we want our architecture to achieve. That is the next step on our side, and I will share what we learn.

Based on a working session between our team and Oracle's OCI identity team in September 2026, combined with Oracle's public documentation. Product behavior, limits, and licensing change over time. Confirm specifics against your own environment and your Oracle account team. Views are my own.

AI Configurator Is Deprecated in 26C. Here Is What It Means for Prompts You Already Changed.

AI Configurator Is Deprecated in 26C. Here Is What It Means for Prompts You Already Changed.

The notification tells HCM customers to stop using it. It is far less clear about the work you have already done.

If you run Oracle Fusion HCM and anyone on your team has ever edited a prompt behind an embedded AI feature, you probably received a notification recently. Starting in Update 26C, AI Configurator is deprecated and replaced by AI Agent Studio. The immediate action listed is to stop using AI Configurator and make sure prompts are not propagated to production.

Clear enough on its own terms. The question it left our team with was a different one. What happens to the prompts we already modified? Do they stop working at 26C? Do we have to redo that work, and if so, by when?

The notice does not say. We had time scheduled with Oracle's AI product management team, so I asked. Between that conversation and the readiness documentation, here is the fuller picture.

What the documentation actually says

The 26C readiness note is worth reading directly rather than relying on the summary in the notification email. Several things in it matter.

AI Configurator is described as the built-in tool inside Oracle HCM Experience Design Studio, used for locally editing prompts for embedded AI features. It is deprecated in 26C.

If you previously configured prompts with it, the documentation is direct about what you owe. You must re-create and revalidate those configurations in AI Agent Studio. That is not framed as optional.

It also states that you retain access to AI Configurator so you can copy your prompts and reuse them in Agent Studio. This is not a case of the tool vanishing and taking your work with it.

What the documentation does not say is when. That is the part I wanted answered.

What Oracle told us about timing

Existing configurations do not stop working when 26C lands. That was stated plainly. There is no date on which your modified prompts revert to Oracle defaults and your users notice a difference.

The trigger for action is more specific than a release number. Today some of these embedded use cases call a completion endpoint. Oracle is progressively moving each use case over to the invoke agent and invoke sync APIs instead. When a use case you modified makes that move, your prompt change needs to already exist in Agent Studio, in the relevant LLM node, for it to keep applying.

So the re-creation the documentation asks for is real work you need to plan. The sequencing follows Oracle's migration of each individual use case rather than a single cutover date.

From an end user perspective, none of this is visible. Same experience, different plumbing underneath.

A short note on what AI Configurator was

Worth a detour, because plenty of people received this notification without a clear sense of what the tool did.

Fusion has embedded AI features throughout the interface, the ones sitting behind an AI Assist button. Goal setting is the example most people recognize. You click it and the system drafts goals in the SMART format, specific and measurable and the rest.

That formatting instruction lives in a prompt. Some organizations wanted a different structure, different language, or different emphasis for reasons of their own. AI Configurator existed so you could modify that prompt without involving Oracle.

If nobody at your organization ever opened it, this deprecation does not create work for you.

The practical sequence

This is the order we landed on, and I think it generalizes to most HCM customers in the same position.

1.        Build an inventory of what you actually modified. Which use cases, what changed, and why. This is the step people skip and it is the one that matters most.

2.        Copy the prompts out of AI Configurator. Put them somewhere you control rather than leaving them inside a tool being retired.

3.        If something cannot be recovered, ask Oracle. They confirmed they can retrieve prompts from the underlying tables if needed.

4.        Re-create and revalidate in Agent Studio, sequenced against Oracle moving each use case to the agent framework.

On the first step, the notification identified the environments where prompts had been configured, which is a helpful pointer, but it does not tell you which specific use cases were touched or what the change was. That inventory is yours to build.

I would also involve whoever asked for the original change rather than treating this as a purely technical exercise. Someone modified that prompt for a business reason. Migrating the text without carrying the reasoning forward means you cannot revalidate it properly, and revalidation is explicitly part of what Oracle is asking for.

The access requirement people will trip over

The readiness note contains one line that is easy to skim past. You must have access to use AI Agent Studio.

That access is not automatic. AI Configurator lived inside HCM Experience Design Studio. Agent Studio is a separate tool with its own access requirements. There is a reasonable chance the person who made your original prompt changes cannot get into Agent Studio today.

Sort that out before you reach the migration work rather than during it.

On cost

I asked directly whether maintaining these configurations after the move generates any additional charge. The answer was no.

The reasoning holds up. These embedded use cases are simple calls, summarization and short text generation, comfortably within what a hosted model handles. Oracle hosts a model for this category of work and treats calls to it differently from models it has to source externally. This kind of usage did not generate a bill before and does not after.

I have written separately about how that metering works, because it is the most misunderstood part of Fusion AI right now.

Why the destination is better than the origin

I will be honest that a deprecation notice with an unclear impact statement is irritating, and I said as much on the call. That said, where this lands is genuinely better, and the readiness documentation is specific about why.

·        Prompt configuration and agent configuration stop living in two separate tools.

·        Access control improves. Prompts inherit the same security model as agents, so an HCM administrator cannot configure prompts belonging to other product families. If you care about governance, that is substantive rather than cosmetic.

·        You get a broader range of models to choose from.

·        You can evaluate a prompt before publishing it. Editing prompt text in isolation and hoping for the best is how most of us have worked until now.

·        You get the full set of workflow nodes for editing, plus the ability to add and remove variables, which AI Configurator did not offer.

What I would still like to see

Two things, offered as the feedback I would want if our positions were reversed.

Clearer impact statements in deprecation communications. The notice told customers to stop using a tool without addressing the status of work already done with it. That single gap produced more internal speculation on our side than the migration itself will produce work. One sentence would have covered it.

Published sequencing for the underlying migration. Because the practical trigger is Oracle moving each use case to the agent framework, knowing which use cases move in which update would let customers plan instead of react. That timing is not visible from outside today.

Neither of these is a reason to be worried about the change. Both are the kind of thing that would make the next one land better because this change is actually a huge improvement and something to be excited about!

Where to read more

Oracle's 26C readiness note covering the deprecation and transition is at docs.oracle.com under the HCM 26C common technologies what's new, titled Deprecation of AI Configurator and Transition to AI Agent Studio.

If you received the notification and have not started, begin with the inventory. Everything else depends on knowing what you actually changed.

Based on Oracle's 26C readiness documentation and customer notification, combined with a working session between our team and Oracle's Fusion AI product management group in August 2026. Statements about migration timing and cost reflect that conversation and are not a substitute for Oracle's published guidance. Confirm specifics against your own environment and your Oracle account team. Views are my own.