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.