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

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

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

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

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

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

What the documentation actually says

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

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

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

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

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

What Oracle told us about timing

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

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

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

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

A short note on what AI Configurator was

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

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

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

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

The practical sequence

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

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

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

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

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

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

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

The access requirement people will trip over

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

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

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

On cost

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

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

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

Why the destination is better than the origin

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

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

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

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

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

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

What I would still like to see

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

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

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

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

Where to read more

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

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

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

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.