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.