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.