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.

Making Sense of Oracle AI Units

Making Sense of Oracle AI Units

What you actually pay for when agents run in Fusion, and the pricing change a lot of people missed.

Every conversation I have about Fusion AI eventually arrives at the same question, usually about twenty minutes in. Someone asks what this is going to cost. Not the license. The running cost, once agents are actually doing work.

It is a fair question, and until recently I did not have a clean answer for it. We recently spent time with Oracle's AI product management team going through the mechanics, and I want to write down what I learned. The model is more reasonable than most people assume, and I think the way it gets explained, depending on who you talk to, is part of why people assume otherwise.

What an AI Unit actually measures

An AI Unit captures two things at once: the type of action an agent performs, and the number of tokens that action consumes.

The token side works in boundaries of roughly 10,000. Your consumption gets grouped into those boundaries, and then a multiplier is applied based on what the agent was doing. A reasoning action, where an agent takes a prompt and some context and comes back with a plan, falls into what Oracle calls a basic or general action.

In the example we were walked through, a general reasoning action came out to 5 AI units, which is roughly 5 cents.

The distinction that matters most

Here is the part that reframed the whole thing for me. The multiplier depends on whether Oracle hosts the model or has to call out to someone else's.

Oracle hosts GPT OSS, the 120 billion parameter open model. Because they run that infrastructure and absorb the cost, calls to it carry a zero multiplier. In practical terms, free.

Premium models are the ones Oracle reaches out to other providers for. OpenAI's models, and more recently Google's Gemini models. Oracle pays those providers, and that cost passes through to you.

The way it was put to us was simple: any model we host, we will continue to offer at a zero multiplier. Any model we have to call out to is where charging happens. Once I understood that, most of my confusion about Fusion AI cost went away.

The embedded features you already use are not about to start costing you

If you have been clicking the AI Assist buttons scattered around Fusion, goal setting being the one most people know, those are simple LLM calls. Summarization and text generation, that category of work. The hosted model is more than capable of handling them.

Those were free when they ran on Cohere, and they stay free as they migrate over to Agent Studio. If you were bracing for a bill when that migration lands, you can stop.

The pricing change a lot of people missed

This is the part I think deserves far more attention than it has received.

The original pricing model triggered billing based on customization. Build a custom agent in Agent Studio, that triggered billing. Install one from the marketplace, same result. This applied even when the underlying model was the free hosted one.

That model is gone. Oracle told us plainly that it generated a lot of customer feedback and that it was confusing. The underlying problem was definitional. Drawing a clean line between a custom agent and a configured Oracle-delivered agent turned out to be cumbersome in practice. They started strict, tried loosening the definition, and eventually concluded the whole approach was the wrong shape.

So they moved to usage. You are charged for what you consume, not for whether someone classifies your agent as custom.

Per-user licensing still exists if it suits your procurement better, but most customers are choosing usage, mainly because it lets you start small and grow into it.

I want to give credit here without laying it on too thick. Retiring a pricing model because customers found it confusing is not a small thing, and it is the kind of decision that tends to surface only in conversations like this one. That is part of why I am writing it down.

Agentic apps use the same meter

One of our architects asked whether agentic apps are metered differently from agents built in Agent Studio. They are not.

An agentic app is a collection of agents, so what gets captured is the orchestrator performing its reasoning and delegation, plus the activities of each workflow agent underneath it. Same units, same mechanics, more moving parts.

Where I would spend premium model budget

You choose the model. Oracle's own recommendation, and I agree with it, is to use a premium model for the orchestration layer at minimum. If an orchestrator is deciding which agents to invoke and in what order, weak reasoning at that layer degrades everything downstream of it.

The workflow agents doing narrower, more deterministic work are a different story. That is where hosted inference earns its keep.

The advice that came attached to that recommendation is the part I would underline: run your own evaluation against your own use cases. Model quality on a vendor benchmark is not the same as model quality in your configured environment, with your data and your prompts. That gap is where most disappointment lives.

What is not settled

Models that generate audio or video are considerably more expensive to run and will carry a higher multiplier. Those rates were not on the rate card when we spoke.

I also want to be careful about what this post is. I am reporting a conversation, not a contract. The mechanics held up well under questioning, but the interaction between action type and model tier is exactly the sort of detail worth confirming in writing. Before you build a forecast on any of it, verify against your own rate card and your Oracle account team.

The short version

If you are trying to build a cost model for Fusion AI, start here: work out which of your use cases genuinely require a premium model, and assume the rest can run on hosted inference at no incremental cost.

That framing got us considerably further than trying to price every individual interaction, and it turns the cost conversation into a design and ROI conversation, which is a much better conversation to be having.

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

Oracle Put Fusion AI Development in VS Code and Made It Work With Coding Assistants

Oracle Put Fusion AI Development in VS Code and Made It Work With Coding Assistants

A public repo, a CLI, a VS Code extension, and a testing framework almost nobody is talking about.

I have spent years asking Oracle product teams to meet developers where they already work and different platform teams have made great strides in this area over the years with varying degrees of success.

However, I want to be direct about this one: what the Fusion AI team has shipped in a short spawn of time around this theme, I think deserves more attention than it is getting.

There is a public GitHub repository at github.com/oracle/fusion-ai-studio. It contains skills, a CLI, a VS Code extension, Oracle-authored sample applications and workflows, and how-to guides. It is published under the Universal Permissive License and updated regularly.

What is actually in it

·        A skills directory that coding assistants can read

·        An aiapps directory with Oracle-authored template applications and workflows

·        The VS Code extension and CLI

·        A how-to folder covering installation and incremental updates

Sample apps span HCM, including career development, journeys, learning, absences, and succession management, along with supply chain areas like inventory and cost management, and procurement content covering purchase orders and agreements.

The repository moved to release-based branching, with release-26C as the current branch and a dedicated branch planned for each future release. Before that change you downloaded ZIP files, extracted them, and placed the contents into the right directories yourself. Now you clone the branch matching your release and pull updates.

That is a small change, but it tells you something about how the team is thinking. Somebody looked at how people actually consume this and removed the friction.

It works with coding assistants

The VS Code extension provides guided commands and visual editing for setting up a workspace, connecting to the right environment, and creating or opening artifacts. The how-to guide walks through using it alongside Codex.

Oracle's product management team also described pointing Claude Code at a workspace directory. There is a CLAUDE.md in the repo, and the assistant reads the skills and works with Agent Studio from that context.

The reason this matters is not novelty. It is that describing a business outcome and having an assistant apply the change across workflows, business objects, agents, and supporting artifacts is a fundamentally different working mode than opening and editing each file in turn. Anyone who has built a moderately complex agent knows how many artifacts a single change can touch.

The builder assistant

In 26C, Agent Studio gained a natural language interface for describing what you want and generating the workflow agents, the business object definitions, and the agentic app itself.

Two things about it are worth calling out. The first is cost. Oracle's product management team told us the builder assistant does not consume AI units, on the basis that you are instructing it rather than running inference against your business data. I have not been able to find that stated anywhere in Oracle's public documentation, so I would treat it as reported rather than confirmed, and check it against your own environment before you build an assumption on it. The second is that it works in reverse. You can point it at an existing workflow, including one Oracle delivered, and ask it to explain what the thing does and why. If you have ever inherited a complicated workflow with no documentation, you already understand the value.

ATLAS is the part people are sleeping on

Sitting in the repository change log is a framework called ATLAS, the Agentic Testing and Lifecycle Automation Suite. It landed in early August and I have seen almost no discussion of it anywhere.

Consider the problem it addresses. You deploy agents. Models change. Providers deprecate versions and release new ones. How do you swap models across a fleet of agents and know with any confidence that everything still behaves the way it should?

ATLAS turns agent scenarios into repeatable, executable tests. Each test combines an input, expected workflow behavior, representative replay data, and evaluation criteria. It validates structurally, confirming required or prohibited execution paths, and semantically, for natural language responses where exact text matching would be too rigid.

The capabilities I find most interesting:

·        File-based replay holds external service boundaries stable while routing, conditions, code, and LLM nodes continue to execute. That makes regressions reproducible rather than dependent on whatever the source system happened to return that day.

·        Labeled runs let you compare a baseline against a candidate model using consistent evidence.

·        Optimization sweeps evaluate model placement at the individual LLM node level, using quality, latency, and usage data. Rather than picking one model for an entire agent, you work out which specific node needs the stronger one.

·        It integrates with local development and CI/CD, producing reports covering results, evaluated outputs, warnings, token usage, and execution duration.

Connect that last point back to cost and it becomes more interesting still. Node-level model evaluation is the mechanism for answering the question I keep raising internally: which parts of a workflow actually justify a premium model? ATLAS replaces intuition with evidence, and evidence is what a finance conversation requires.

Where this is heading

Oracle's product team described the next phase as fleet management and governance. Once an organization has hundreds of agents deployed, the questions change. It stops being how do I build one and becomes how do I understand what they are all doing, whether any of them are misbehaving, and how I make wholesale changes safely.

The CLI investment is aimed at that broader lifecycle rather than only the build step. Designing, reasoning about which agents make sense for a given business problem, then evaluating and maintaining them once they exist.

A few honest caveats

·        The repository does not accept external pull requests. You can consume it, not contribute to it.

·        The samples carry a broad disclaimer and no warranty. Treat them as examples to learn from rather than production code to deploy as-is.

·        The documented assistant path is most complete for Codex. Other assistants work, but expect to do some of your own figuring.

None of that changes my overall read. An Oracle SaaS product team publishing a public repository, shipping a VS Code extension, supporting third-party coding assistants, and building a testing framework for agent lifecycle management represents a real shift in posture. I would like to see it spread to other Oracle products on the Low Code front with more vigor (such as OIC and VBCS), and I have said so to anyone at Oracle who will listen and I know the teams are working on it!

Where to start

If you work with Fusion AI and have not cloned the repository yet, start there and begin with the how-to folder. Reading Oracle's own sample workflows taught me more about the intended patterns than any presentation I have sat through.

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

AI Agent Studio or Agentic Apps? Sorting Out Where Fusion AI Is Going

We spent a good part of last year getting our arms around AI Agent Studio. Each release made it better, and it was starting to feel ready for real work.

Then Oracle announced agentic apps, and the immediate reaction on my team was: what is that, and what does it mean for everything we just learned?

I doubt we were alone in that. So when we got time with Oracle's AI product management team, this was the first question I asked.

The short answer

Agentic apps are not a replacement for Agent Studio. They are a layer built on top of it that allow the ecosystem to become very useful in the enterprise. The progression makes considerably more sense once you see the steps that got there.

How the model evolved

Oracle started where most of the industry started, with a supervisor and worker pattern. A supervisor agent reasons about a request and delegates to worker agents.

Then they introduced workflow agents, and this is where it gets interesting. Workflow agents follow a deterministic path built from a graph of nodes: LLM nodes, code nodes, switch nodes, agent nodes. You define the route rather than asking a supervisor to work it out at runtime. You need agentic capability at specific points, an LLM call here, a decision there, but the sequence is not a mystery that has to be solved on every execution.

That matches my experience closely. Most of what we want to automate in Fusion is not open-ended reasoning. It is a known process that requires judgment at a handful of steps.

So what is an agentic app

An agentic app is a container. Inside it sits one or more workflows, and in practice usually somewhere between two and six, depending on the outcome you are after.

What makes it more than a folder is shared context and a common goal. The orchestrator tells the participating agents what the business objective is, and each one contributes its part while working from shared context rather than operating in isolation.

Oracle frames this as a new category of application: one that does not simply store your data or display your data, but interprets it and tells you what to do about it. That is marketing language, but the architecture underneath it holds up.

What makes a workflow agentic-app capable

This is the practical part, and Oracle's public sample repository documents it better than any announcement I have seen.

A workflow participating in an agentic app has to handle messages coming from the app. The pattern is a switch node at the front reading a message hint variable, then branching based on what the app is asking for: an initial display, a summary, an answer to a query, or an action to execute.

The workflow also declares what it is permitted to produce. There is an App Experience tab where you enable actions, enable communications, and select which visual widgets the agent is allowed to render, things like tables, charts, and Sankey diagrams.

Two details worth knowing before you start building anything, based on knowledge I believe to be true:

·        The framework enforces a 60 second response limit. That is a real design constraint, and it is one of the stronger arguments for deterministic workflows over supervisor orchestration, because predictable latency matters a great deal when you have a hard ceiling.

·        User input and chat history are not passed automatically into internal nodes. You have to wire those variables through explicitly.

Where this leaves your investment

If you have been building in Agent Studio, that work is not stranded. Agent Studio is where agents and workflows get defined, and agentic apps consume what you build there. The studio remains the foundation, and time spent learning it still pays off drastically.

If you are deciding where to start, I would build workflow agents first and treat the agentic app as the assembly step once you have components worth assembling.

On the commercial side, taking an agentic app into production requires platform access beyond ordinary usage. You can build and test in lower environments consuming standard AI units. I am deliberately not quoting figures. I would simply say have that conversation with your account team earlier rather than later, because it changes the shape of a business case.

What I am still watching

How much arrives out of the box versus how much we build ourselves. The value of platform access depends heavily on what comes with it. Oracle has committed to delivering high value agentic apps built by the domain teams, and the public sample repository has been filling out steadily across HCM, supply chain, and procurement. I want to see how far that goes and how quickly.

I am also watching how the two builder experiences settle. There is a visual, low-code builder aimed at domain experts, and a pro-code path through the CLI and VS Code. Both are genuinely useful today. Whether they stay equally capable as the platform matures is a question worth revisiting in a few releases.

Neither of those is a criticism. They are the questions I would want answered before committing a roadmap, and I would rather write them down than pretend the picture is fully settled.

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

Building an AI-Driven Oracle Fusion Cloud Analysis Tool: What We Learned Along the Way

If you work with Oracle Fusion Cloud and have ever felt like you need more insights when it comes to data quality, process health, or IDR performance, you are not alone. The Oracle ecosystem is rich, but the gap between "we have the data" and "we actually understand what the data is telling us" can be enormous. This post walks through how we built a Python-based analysis pipeline called Catalyst AI Lab that connects directly to Oracle Fusion Cloud REST APIs and surfaces actionable findings automatically, and how AI-assisted development made the whole thing possible in a fraction of the time it would have taken otherwise.

The Problem Worth Solving

Our team supports Oracle Fusion Cloud across ERP, EPM and HCM. Like most teams, we spent a lot of time answering the same questions: Why is our Straight-Through Processing rate lower than expected? Are there duplicate suppliers in the system? Which business units have the most unresolved invoice holds, and how old are those holds? Among many other existential questions!

The answers exist in Oracle. The REST APIs are well-documented enough to get started. But building something repeatable and systematic that could answer these questions reliably, across environments, and produce a report someone could actually act on -- that is a different project entirely.

The goal was to build a tool that behaves like a knowledgeable consultant running a discovery engagement: it goes into the system, looks at the data from multiple angles, identifies what is worth paying attention to, and tells you why it matters.

The Architecture: Discovery Lenses

We organized the analysis into what I call discovery lenses. Each lens is a focused analytical perspective that targets a specific domain. The IDR Invoice Processing lens, for example, looks at STP rates, hold root causes, duplicate invoices, supplier-level IDR success, and per-BU performance breakdowns. The Supplier Data Quality lens looks at the entire supplier master for duplicates, missing site attributes, banking configuration gaps, tax registration coverage, and cross-BU payment term consistency.

Each lens follows the same pattern: connect to Oracle, fetch the relevant data via REST API, run analysis, produce structured findings with severity levels, confidence scores, and remediation guidance, then export everything to an HTML report and supporting CSV files for drill-down in Excel.

The framework is extensible. Adding a new lens means creating one Python file, decorating a class with @register_lens, and adding configuration to a YAML file. No changes to the core pipeline needed.

Agentic Development: What It Actually Looks Like

I want to be honest about what AI-assisted development meant on this project, because there is a lot of noise around this topic.

The GitHub Copilot agent in VS Code was not just writing boilerplate. I was having extended conversations with it about Oracle API behavior, asking it to review findings for accuracy, having it run the pipeline against our dev environment and then analyze the results, and using it to write and fix tests. When a finding was surfaced with a remediation recommendation that turned out to be wrong (more on that below), we flagged it, the agent researched the correct Oracle Cloud guidance, and we updated both the code and the best practices configuration together.

The workflow looked like this: I would describe what I wanted to understand about the data. The agent would research the Oracle REST API structure, write the lens code, run the pipeline, and report back with results. Then we would review the output together, identify what was accurate, what was misleading, and what needed more nuance. That iterative loop is where the real value was. It compressed weeks of work into days.

The test suite ended up at 632 tests covering pagination behavior, finding logic, report generation, CLI commands, and end-to-end pipeline execution. Having the agent write those tests alongside the features meant I could refactor confidently.

Oracle REST API: Things You Will Not Find in the Quick Start

This is the section I wish existed when we started.

First, pagination. Oracle Fusion Cloud REST APIs use offset/limit pagination with a default page size of 100 records. That is straightforward. What is not obvious is that if you want Oracle to tell you how many total records exist, you have to explicitly pass totalResults=true as a query parameter on your request. Without it, the API returns your page of data but gives you no indication of the overall population size. We were calculating STP rates against a 20,000-invoice sample before realizing we had 275,180 invoices YTD. That is a 7.3% sample, which changes how you interpret the findings significantly.

The fix was simple once we understood it: on the first page request, add totalResults=true to the query string. Oracle then returns the estimated row count in the response, and you can surface that alongside your findings as a population coverage metric. Every finding now shows something like "analyzed 20,000 of 275,180 invoices (7.3% coverage)" so the reader understands the confidence level of what they are seeing.

Second, filter syntax on certain resources. Oracle's REST API supports query filters using a SCQL-style syntax, which is powerful for many resources. But for invoiceHolds specifically, we discovered that compound filters with semicolons are silently ignored. You cannot filter by multiple conditions in a single request on that resource. The API accepts the request without error, applies no filter at all, and returns unfiltered data. If you are not paying attention, you will think your filter worked and analyze the wrong dataset. The workaround is to fetch the broader dataset and filter in application code.

Third, the OpenAPI specification files for Oracle Fusion Cloud are enormous. The five files covering ERP Financials, PPM, Procurement, Common, and HCM total nearly 400MB. You cannot parse those with standard JSON libraries without running into memory issues. The solution was ijson, a streaming JSON parser that lets you walk through the spec without loading it all into memory at once.

Fourth, credentials. Oracle Cloud API credentials need to be stored securely. The pipeline uses OS keyring integration (Windows Credential Manager on Windows, Keychain on Mac) so passwords are never in plain text files, never in environment variables that might get logged, and never in source control. This is worth doing properly from the start because once you have multiple environments and multiple team members, credential hygiene matters.

What the Analysis Actually Found

Running the full pipeline against our Prod clone environment produced some results worth highlighting, both because they illustrate what this kind of tool can surface and because they validate the approach. Below are a couple of material examples.

On the IDR side: our overall STP rate looked reasonable at the summary level, but the per-BU breakdown showed significant variance. Several business units were well below the industry benchmark. That variance was invisible in aggregate reporting. The hold analysis showed issues, which is a cash flow concern that should have been caught in normal operations.

On the supplier side: analyzing all suppliers at 100% population coverage found many potential duplicate supplier groups, duplicate addresses, and active suppliers flagged as Do Not Use. The real value is that the tool gives you a prioritized, evidence-backed list to work through rather than asking someone to manually review a spreadsheet with thousands of rows.

Click on the image to expand it~

Lessons on Accuracy and Iteration

One thing I want to be direct about: the first version of several remediation recommendations in the tool were wrong. Not wrong in a subtle way -- wrong in the sense that they referenced Oracle lookup values that do not exist in standard Cloud instances, or recommended configuration changes that would break other functionality.

This happened because the AI was drawing on general Oracle knowledge that did not perfectly match Oracle Cloud specifically. The fix was systematic: review every finding's remediation guidance against actual Oracle Cloud documentation and lived experience, update the best practices configuration file that drives the recommendations, and add tests that assert the correct guidance is present.

That iteration process is not a failure of AI-assisted development. It is how the process is supposed to work. The agent accelerates construction; human expertise and domain knowledge ensure correctness. If you skip the review step, you will ship wrong recommendations at scale. If you do the review, you end up with something accurate and fast.

How You Can Apply This to Your Environment

The pattern generalizes beyond the specific lenses we built. If you support Oracle Fusion Cloud in any capacity, you almost certainly have questions you are answering manually today that could be answered systematically with this approach.

Start with one question you care about. What is your PO-backed invoice percentage? How many suppliers have incomplete site setup? What is the distribution of expense report approval times across business units? Pick something with a clear Oracle REST API resource behind it, build a focused analysis around it, validate the results against what you know to be true, and iterate from there.

The Oracle REST API surface area is large enough that you can build meaningful analytics across almost any domain without needing a data warehouse, a separate reporting tool, or an extract from production. The data is there. The APIs are there. The AI tooling to help you build something coherent on top of them is better than it has ever been.

The repository for this project is internal to our organization, but the patterns, the Oracle API gotchas, and the architectural approach are all things you can apply independently. If you are working on something similar or have questions about the Oracle-specific pieces, drop a comment below. I am happy to go deeper on any of it.

How I Connected Oracle OCI LLM Endpoints to Postman and VS Code

I recently spent some time wiring up Oracle Cloud Infrastructure Generative AI endpoints so I could call models directly with an OCI Generative AI API key, validate everything in Postman, and then take the same setup into Visual Studio Code. The process ended up being a great example of how OCI can fit into modern AI workflows without forcing teams to abandon the tools they already use every day. Oracle’s Generative AI service supports service specific API keys, OpenAI compatible endpoints, and both Chat Completions and Responses APIs, which makes it much easier to integrate enterprise hosted models into familiar developer tooling.

What stood out to me most was how practical the setup became once the moving parts were understood. OCI Generative AI API keys are not the same as standard OCI IAM API keys. They are service generated secrets created specifically for OCI Generative AI, and Oracle documents that either of the two generated secrets can be used interchangeably in the Authorization header when calling supported model endpoints in the same region where the key was created.

Step 1: Creating the OCI Generative AI API Key

The first step was creating an API key inside the OCI Generative AI area of the Oracle Cloud console. Oracle documents these as service specific credentials for model access, and that distinction matters because they are meant for LLM endpoint authentication, not for general tenancy administration. Oracle also notes that the key must be used in the same OCI region as the model endpoint, which is important when you are testing against a region specific inference URL.

Another helpful detail is that OCI gives you two interchangeable secrets per API key. That makes rotation easier because one secret can be regenerated while the other remains active. Oracle explicitly recommends using one of those secrets as the bearer token when calling a supported model endpoint.

Step 2: Adding the IAM Policy That Makes the Key Work

Creating the API key was only part of the story. The key also needed permission to call the OCI Generative AI service. Oracle’s documentation explains that a separate IAM policy is required for principals of type generativeaiapikey, and this is where a lot of integration attempts can stall if the policy step is skipped.

In my case, I created the policy in the OCI Console under *Identity & Security > Policies* and used the manual editor in the root compartment. For testing, the policy that finally unlocked the flow was:

```text

allow any-user to use generative-ai-family in tenancy where ALL {request.principal.type='generativeaiapikey'}

```

Oracle documents this pattern for broad testing access and also explains that policies can be narrowed later by compartment, model, operation type, or even a specific API key OCID. That is a good way to start wide enough to validate the integration and then tighten the scope after the path is proven.

Step 3: Calling the OCI Endpoint from Postman

Once the key and policy were in place, I moved into Postman. Oracle documents a REST endpoint pattern for Chat Completions using OCI Generative AI API keys:

```text

https://inference.generativeai.<region>.oci.oraclecloud.com/20231130/actions/v1/chat/completions

```

Oracle’s API key documentation also shows that the request should send the API key secret in the Authorization: Bearer ... header and include a valid supported model in the request body. Supported models for this API key based REST path include xAI Grok and OpenAI GPT OSS, which are the models I focused on, but there's more available models in OCI like Llama, Cohere and Gemini.

My working request in Postman ended up looking like this:

```http

POST https://inference.generativeai.us-chicago-1.oci.oraclecloud.com/20231130/actions/v1/chat/completions

Authorization: Bearer sk-<your-secret>

Content-Type: application/json

Accept: application/json

```

With a body like this:

```json

{

  "model": "openai.gpt-oss-20b",

  "messages": [

    {

      "role": "user",

      "content": "Say hello in one sentence."

    }

  ]

}

```

After the policy was added, that request returned a successful response. That was the turning point because it confirmed the key, the policy, the endpoint, and the region were all aligned correctly. Oracle’s documentation supports this exact pattern, including the Chat Completions endpoint and the use of a bearer token generated by OCI Generative AI.

Click the image to expand it~

What I Learned From the Postman Troubleshooting

The troubleshooting was actually a useful part of the exercise. Early failures came down to a few very specific issues. First, the bearer token has to be the actual `sk-...` secret, not the API key OCID or a console URL. Second, the key has to be used in the same region where it was created. Third, the IAM policy really is required or the request will not succeed even if the secret is correct. Oracle’s docs are clear on all three of those points, and once those pieces clicked, the flow became much more predictable.

That experience also reinforced something broader. OCI is not just exposing models in its own console. Oracle is making the service available in ways that work with the tools many engineering teams already use, which lowers the friction to experiment and integrate. Oracle’s newer OpenAI compatible endpoint documentation makes that intent even more obvious by describing a base endpoint that works with familiar OpenAI style request patterns while still keeping authentication, execution, and resource management inside OCI.

Step 4: Taking the Same OCI Endpoint into VS Code

After confirming the endpoint in Postman, I wanted the same model access inside Visual Studio Code, given it's broad use in our organization. That turned out to be possible using VS Code’s bring your own key model support. Microsoft’s documentation explains that VS Code lets you add language models through the model picker and that custom providers can expose one provider with many models. The model metadata includes fields such as id, name, maxInputTokens, maxOutputTokens, and capability flags like tool calling and image input.

Using the custom endpoint option in the VS Code model picker opened a configuration file where I defined the OCI model settings. I used a Chat Completions style configuration because I had already validated that path in Postman. The key pieces were the OCI endpoint URL, the OCI API key, and the exact model ID. For example, openai.gpt-oss-20b worked well for a first pass because it had already succeeded in Postman, and Oracle lists GPT OSS as a supported model family for API key based Chat Completions.

The result was that I could select the OCI backed model in VS Code’s chat experience and use it like any other language model available through the model picker. Microsoft documents that the model picker is how users switch chat models, and Oracle documents that OCI supports both native and OpenAI compatible inference patterns. That combination is what made this work so well.

Click the image to expand it~

Why This Matters

To me, the bigger takeaway is not just that I got Postman and VS Code working. It is that OCI can participate in the same AI development workflows people already use for testing, coding, prototyping, and experimentation. Oracle’s documentation highlights support for OpenAI compatible endpoints, supported SDKs, and familiar APIs like Chat Completions and Responses. Microsoft’s documentation shows that VS Code is increasingly flexible about model choice through bring your own key and custom providers. Put those together and you have a path for teams that want enterprise hosted AI models without giving up developer ergonomics.

That opens up a lot of possibilities. It means OCI hosted models can be validated in Postman, consumed by scripts and SDKs, and surfaced directly in the editor where developers work. It also means organizations that are already invested in Oracle can extend that platform into modern AI workflows instead of treating it as something separate. OCI Generative AI is positioned by Oracle as an enterprise scale AI platform that supports hosted models, OpenAI compatible APIs, governance, and agent related features. This kind of integration work shows what that can look like in practice.

Final Thoughts

What started as a simple attempt to call a model with an OCI API key turned into a good exercise in understanding how Oracle has structured access, authorization, and compatibility with recent product enhancements. The final setup was straightforward once the pieces were in place: create the API key, grant the IAM policy, validate the endpoint in Postman, and then carry the same working endpoint into VS Code. Oracle’s API key model, policy framework, and OpenAI compatible options make that path realistic, and it is a strong example of OCI being useful well beyond the console itself.

If you are working in OCI and want to make enterprise hosted LLMs available in tools your team already trusts, this is absolutely worth trying.

AI Enhances Oracle Cloud HCM Support: Elevating Insight with the Oracle HCM Intel CLI

Oracle Gen AI + Public HCM Metadata = Limitless Insight

The Oracle HCM Intel CLI Tool is a professional-grade command-line assistant that uses your extracted HCM metadata and combines it with the capabilities of Oracle’s OCI Generative AI service (powered by Cohere) or OpenAI, or the LLM of your choice, giving you intelligent insights relative to HCM data structures. And it's all done securely and locally—no sensitive data leaves your environment.

By referencing public HCM data definitions, this project demonstrates just how powerfully Oracle Gen AI, and other AI offerings, can be applied in the enterprise to support analysts, developers, and architects with tasks such as:

• Generating SQL queries based on natural language
• Suggesting joins between key Oracle HCM tables
• Explaining and optimizing existing SQL
• Creating BI Publisher-ready templates
• Performing semantic metadata searches

Project GitHub: oracle_hcm_intel_cli

Demo: Watch Demo

---

Built With Practical Enterprise Needs in Mind

The tool includes features that any real-world implementation would benefit from:

• Encrypted .env handling using runtime secrets
• Markdown output for reporting or Copilot/Teams usage
• Audit mode for logging what metadata was passed to the LLM
• Modular provider support for OpenAI or Oracle Gen AI
• Interactive prompt chaining for analysts and non-developers

It’s optimized for real users working in real environments—offering flexibility without sacrificing security or precision.

---

Powered by Oracle Technology, Honoring Oracle’s Vision

This CLI tool is powered by Oracle’s own public documentation and showcases the capabilities of Oracle Cloud Infrastructure’s Generative AI platform. It's a clear example of how AI and metadata can be responsibly applied in the enterprise, especially when building tooling around Oracle’s HCM ecosystem.

Oracle’s Gen AI service is the star of the show here—it brings context, comprehension, and creative query generation to the hands of business users and technical professionals alike.

Earlier this month, I introduced a Metadata Extractor CLI Tool built to programmatically parse Oracle Cloud HCM’s public documentation and extract table and view metadata into JSON format. That foundational tool—available on GitHub at oracle_hcm_metadata_extractor—has enabled this powerful second act: the Oracle HCM Intel CLI.

---

Get Started

1. Extract metadata using: oracle_hcm_metadata_extractor

2. Query and explore with: oracle_hcm_intel_cli

Whether you’re working in HCM data architecture, reporting, or support—this is your AI-powered sidekick.

---

I hope this project inspires others to build upon Oracle’s cloud platform and apply Generative AI responsibly. The future of enterprise tooling is intelligent, secure, and deeply integrated—and with Oracle Gen AI, that future is now.

—
Julio @ OracleSpot.net