In my earlier piece on what is inside a Fusion agentic app, I listed the seven widgets available in 26B, along with their pattern IDs and Oracle’s guidance on when to use each one. The 26C readiness note adds Multi-Card and Artifact Preview, bringing the total to nine.

The short version

• 26C adds two widgets, taking the total from seven to nine. Oracle’s readiness note identifies Multi-Card and Artifact Preview as the additions, and the current widget guide lists their pattern IDs as multiCardWidget and artifactPreviewWidget.

• In the lab authoring flow, two things have to agree. The widget must be selected in the App Experience settings on the InitDisplay LLM node and named in the instructions available to the agent. If those two places disagree, you can get the wrong widget or no widget.

• The prompt controls the layout. In Lab 3, I added two columns to a multi-record widget by changing the field list in the Init Display User Prompt. There was no separate schema or configuration screen to update.

• Set readOnly explicitly on recordWidget. In the training pod, leaving it unspecified produced different values across runs.

• Actions can be assigned row by row. One row can be clickable while the next is not, even within the same list.

• There is a second identifier set. The LLM output uses patternId values. Oracle’s public 26C sample workflows also contain ORA_LAYOUT_* values under aiAppOutputSpecification.dataDisplay.layouts. A training slide placed similar values in an app-level displayWidgetList, but I have not reproduced that exact field or its scope.

The nine widgets in 26C

• Chart (chartWidget) for trends over time, comparisons across categories or proportions.

• Card (cardWidget) for a single alert or update, with error, warning and info variants.

• Messages List (messageListWidget) for several alerts, with optional priority and actions on each item. Oracle’s earlier CoE guide calls this one “Message List”.

• Change List (changeListWidget) for comparing a KPI’s current and previous values.

• Multi Record (multiRecordWidget) for tabular data with row-level status and actions.

• Record (recordWidget) for showing one record as either a detail view or an editable form, using readOnly true or false.

• Sankey (sankeyWidget) for a flow or funnel where relative volume matters.

• Multi Card (multiCardWidget, new in 26C) for displaying several peer cards in one widget.

• Artifact Preview (artifactPreviewWidget, new in 26C) for reviewing text, rich text, structured rich text, PDF or URL content in place.

Use multiCardWidget when related cards belong together in one widget. cardWidget is for a single update; messageListWidget presents a list. The session slides listed text, rich text, PDF and URL support for Artifact Preview. Oracle’s current 26C widget guide now confirms those formats, adds structured rich text, and notes that PDF and URL content remains read-only even when edit mode is requested.

Widget output is wrapped in <oraInfoDisplay> and identifies the widget with patternId. Be careful with the payload wrapper. Oracle’s current 26C page describes a widget-specific config block and uses it in most examples, while its Artifact Preview example uses properties. Older Fusion CoE examples also use properties, often alongside title and description. I would follow the example for the target release and widget instead of assuming one four-key wrapper applies everywhere. Oracle’s Agentic Apps – Widgets article remains useful for the original seven property schemas.

A widget has to be enabled and prompted

In the authoring flow used in the labs, the training described widget setup as a two-step sequence.

First, enable the widget. On the InitDisplay LLM node, the App Experience section contains a picker labelled “Select the widgets you want to use”. In the Lab 3 example below, Multi Record is the only selection. The same section has toggles for actions, communications and PowerPoint generation, as well as an Instructions box. Its help text asks for clear, everyday guidance on when and how the widgets should be used.

For an app designed around one widget type, I keep the selection narrow. There is little benefit in enabling five when the instructions use only one.

Second, describe the output you want. The Initial Graphics Display Instructions tell the agent how to use the enabled widget. Its response includes the patternId and configuration block that the UI renders.

The lab guidance put app-wide formatting and widget rules in the App Experience tab’s Instructions field. Guidance for one agent went in that agent’s prompt or its workflow LLM node prompt. This keeps the same general widget instructions from being copied and maintained across several agents.

Adding two columns in Lab 3

Lab 3, Exercise 1 made the prompt’s role especially clear. The starting point was a multi-record widget showing deals. The exercise asked us to add Revenue (USD) and Win Prob (%) as two new columns. There was no column designer and no schema change. The only required layout edit was to the field list in the Init Display User Prompt:

Return as multiRecordWidget with:
- Name
- RecommendedAction (if present)
- Deal Risk
- Revenue (USD)
- Win Prob (%)

Six steps get that edit into a running app.

The full change took six steps:

1. Open the Deal Risk workflow agent and locate the InitDisplay branch of the message-hint switch.

2. Open the Init Display LLM node, code INIT_DISPLAY. Its panel contains Name, Code and Error Handler, the language and chat-history toggles, and the two prompts.

3. Find the rendered field list in the User Prompt. Add Revenue (USD) after Deal Risk, followed by Win Prob (%).

4. In App Experience, confirm that Multi Record is selected under “Select the widgets you want to use”. The lab also has actions and communications enabled. Match those settings when reproducing the exercise, but treat them as separate capabilities; communications are not what makes a table row clickable.

5. Publish the workflow agent. In the lab environment, draft changes did not reach the running app unless useDraftWorkflowWhileDeveloping was set in the app JSON. The field now appears in Oracle’s public 26C sample app files with both true and false values, although I have not found its runtime behaviour explained in the prose documentation. Publishing remains the safest default.

6. Reopen the app and run it. The table should now contain both columns.

The exercise changed how I think about prompt governance. If a prompt edit can add or remove a column, the prompt is part of the layout specification. It deserves the same version control and regression testing as a page definition. On many of the programmes I see, prompts are still reviewed mainly as copy, which leaves this part of the interface under-governed.

Four common reasons a widget does not render

The following failures came up several times during the sessions. Oracle’s current documentation now confirms the two-step enable-and-prompt requirement and the need for specific widget instructions. The run-to-run readOnly behaviour and the exact failure symptoms below remain observations from the training pod, so I still treat the list as a practical pre-flight check rather than a product guarantee.

1. The settings and prompt disagree. If a widget is enabled but never named in the prompt, the agent has not been told to use it. If it is named but not enabled, the agent is not allowed to use it. The UI does not flag either mismatch.

2. readOnly is not specified. With recordWidget, the same prompt can produce readOnly: true on one run and readOnly: false on another. If the user needs an editable form, state that directly in the instructions.

3. Several widgets are enabled without selection criteria. You can enable more than one, but the agent then needs a rule for choosing between them and enough data for each valid choice. If you enable a chart and a multi-record table but provide five rows with no series, there is nothing for the chart branch to plot.

4. The requested content is underspecified. The model generates the widget JSON from your instructions, so it needs enough detail to shape the response correctly. Name both the widget and the fields you want.

Most of these are straightforward configuration errors. I now check the widget picker, the prompt and the available data before rewriting any instructions. Otherwise, it is easy to spend an hour polishing a prompt that was never the source of the failure.

Actions can vary by row

In a message list or multi-record widget, actions are attached at row level. A row with a genuine recommendation can be clickable while the next row has no action at all.

The trainers also drew a comparison with Redwood tables. I have not validated that side of the comparison and would not present it as a Redwood limitation without doing so. What I did confirm is the agentic-app behaviour: actions can vary from one row to the next.

That row-level control is useful when only two of ten records have a meaningful next step. Make those two clickable and leave the other eight alone.

patternId and ORA_LAYOUT_* appear at different layers

One session slide showed a CLI-generated app configuration whose displayWidgetList array used a second naming scheme: ORA_LAYOUT_CARD, ORA_LAYOUT_CHANGE_LIST and ORA_LAYOUT_RECORD.

Oracle’s public Fusion AI Studio sample repository now confirms the ORA_LAYOUT_* vocabulary. In the 26C branch, sample workflow files store values such as ORA_LAYOUT_MESSAGES_LIST, ORA_LAYOUT_CHANGE_LIST, ORA_LAYOUT_CARD, ORA_LAYOUT_RECORD, ORA_LAYOUT_MULTIRECORD, ORA_LAYOUT_CHART and ORA_LAYOUT_MULTICARD under aiAppOutputSpecification.dataDisplay.layouts. The same nodes use familiar patternId values in their widget instructions.

That is good evidence that the two vocabularies belong to different parts of the configuration. It does not confirm the slide’s exact displayWidgetList field or prove that it is an app-wide allow-list: that field does not appear in the current public samples I checked. For pro-code debugging, inspect the workflow node’s dataDisplay.layouts array and compare it with the widget requested in the prompt. If your app export also contains displayWidgetList, verify its behaviour in that release before depending on it.

Widgets are not limited to the InitDisplay region. Oracle’s workflow guide says Query responses can include displays and that AdditionalContent requests load extra panels; the widget guide uses <oraInfoDisplay> for widget output. The public samples place dataDisplay.layouts at node level, so check the node handling the relevant path rather than assuming one list covers the whole app.

Sources: hands-on labs at Oracle’s partner enablement, 17-19 August 2026; the Public lab guides issued alongside them, 26C documentation and the public 26C readiness note. Views are my own, not my employer’s or Oracle’s.

An agentic app does not have its own tables, views, business objects or REST APIs. Its workflow agent provides the backend behaviour. I spent three days building against this model during Oracle’s partner enablement in August. My earlier article, Inside an Oracle Fusion Agentic App, described the app in the terms used by the documentation. This article looks at the execution underneath it, the design consequences and the console command that lets you observe it directly.

Quick Summary

• The app has no separate data layer. It does not have tables, a business object layer or a REST API layer of its own; the workflow agent fills that role. This was stated in the sessions, rather than in a published source I can cite.

• A single label routes each request. The app includes {{$context.$app.$OraMessageHint}} on every call. The workflow’s first substantive node is a Switch that reads it. The published set contains ten hints, with InvokeCapability added in 26C.

• Each invocation begins at the top of the workflow. Business object outputs do not persist between hints, conversation-scoped variables do not survive, and each hint arrives as a fresh session. I observed this in three different ways during the labs, but it remains on my re-verification list.

• The browser-console command turnOnDebugging() shows the load sequence. It logs the hint type, the duration for each hint and each contributing agent’s Partial Summary before the “Oracle AI Apps Orchestrator” combines them. The command appears in Oracle’s Public lab guide, so this is not simply a trick demonstrated on a slide.

• The number of sections affects latency and cost. Every contributing agent runs when the app loads. Trainers gave six or seven as the practical ceiling.

• Three settings determine whether an agent works in the app. If the agent is missing from the builder dropdown, or returns plain text instead of a widget, one of those prerequisites is usually the cause.

Read on for the full breakdown.

The Workflow Agent Provides the Behaviour

When an agentic app calls an agent, it passes a label in {{$context.$app.$OraMessageHint}}. The label tells the workflow what kind of response the app expects.

The lab guide describes a hint as a label sent by the application to a workflow agent to identify the purpose of the request and the expected response. Oracle’s Fusion CoE article, Agentic Apps - Message Hints, lists every hint and its trigger, so I will not repeat the table here.

The first real node in the workflow is a Switch on the hint value. Each branch gives the same agent a different job. Summary produces the strapline, InitDisplay builds the widgets and Query answers a typed question. The workflow therefore has one agent, ten entry points and one label that selects the entry point.

This changes the data-model discussion with a client. Anything that touches Fusion data lives inside a workflow branch and runs there under the requesting user's security. The useful architecture questions are which operations each agent may perform and on whose behalf.

Each Call Starts Again

The detail that catches people is that the workflow retains no state between these calls. Every call enters at the top and evaluates the Switch again.

The session phrasing was that every single time the app calls a workflow, it starts from the top. The Day 2 labs approached this from three directions. A business object output fetched for one hint was unavailable to the next. Conversation-scoped variables did not survive. Each hint behaved like a new session. The behaviour was consistent, but I saw it in a training pod rather than in a documented guarantee. I am reproducing it in my own environment before presenting it to a client as a firm constraint.

If the behaviour holds, it has three practical consequences:

• Keep business object calls inside the relevant hint branches and expect some repetition. If both InitDisplay and Query need a worker’s assignment record, each branch fetches it. There is no shared cache, and a common node placed before the Switch would run for every hint, including those that do not need the data.

• Carry the required context in the payload. An action must receive what it needs in the request or fetch it within its own branch. An action that relies on a value calculated by the display branch thirty seconds earlier may appear to work in a demo and fail on the next click.

• Only the Query branch receives conversational memory, and it receives that memory with the request. When Include chat history is enabled, the conversation is handed to the node on each call. The workflow itself still retains nothing. The rest of the app is answering ten distinct requests about one screen, rather than maintaining a conversation.

This design isolates the ten call types from one another: a failure in one region cannot corrupt state used by another. The cost is repeated data retrieval, which needs to be included in the design and estimate.

Observing the Sequence With turnOnDebugging()

Open an agentic app, open the browser console, enter turnOnDebugging() and press Enter. The console responds with “Agentic Apps debug mode enabled”. Refresh the page and it logs every agent response as it arrives, including the hint type and elapsed time. Oracle documents this in steps 21 to 23 of its Lab 1 guide, which is marked Public on every page.

With debugging enabled, a refresh shows the five startup hints. Filter the console for “Summary” and you can see the consolidation: each contributing agent returns a Partial Summary, after which the “Oracle AI Apps Orchestrator” combines them into the summary displayed in the app. What looks like a single paragraph in the interface is produced by a fan-out and merge.

The log contains more than hint responses. [ora.app] Saving application metadata prints the app configuration, including its pagePattern. The session app used swimlanesPattern, which shows that layout belongs to app metadata rather than to an individual agent.

If an app feels slow, these per-hint timings let you identify the agent responsible. There is an important handling point: the console output includes agent codes and a configuration dump. I would use it only in my own demo pod, never in a client’s environment or in a screenshot taken from one.

Why Section Count Matters

On load, every section configured to contribute to the summary receives a Summary hint and runs its agent. The session did not give a technical limit on the number of sections or agents in an app. It did give a practical ceiling of six or seven, because additional sections increase both load latency and AI Units consumed on every open. A 300-node workflow was offered as the example to avoid.

This makes section count part of the cost model:

• A section does not necessarily need to contribute to the summary. Removing that branch, or using a dedicated summary agent, removes one call from every load rather than from a single screen.

• The load-time cost applies on every open. An eighth section that is useful once a week still runs for every user on every load.

• Workflow Settings contains useful estimate fields. Beside the exposure flag are fields for estimated cost and time saved per run, in dollars and minutes. They are underused, but they provide the figures a steering committee is likely to request.

I would not cite six or seven as a documented limit, because it is not one. The mechanism is the defensible point: each contributing section triggers a call on each load, and the console shows those calls.

The Three Prerequisites

A common failure during the training was an agent that did not appear in the app builder’s dropdown. The trainers gave three checks, in this order:

1. Enable Expose to Agentic Apps in Workflow Settings. Without it, the app-experience properties do not appear on the LLM nodes, so the agent has nothing to render even if it could be selected.

2. Publish the agent at least once. A draft-only agent is absent from the builder. This catches teams that iterate quickly but have never completed an initial publication.

3. End every branch on an LLM node. Widget, action and communication properties exist only on that leaf node. A branch that ends with a code node and a return node can still return plain text, making the agent appear functional until the app needs a chart.

The third issue can consume an afternoon because it produces no error. When an agent behaves unexpectedly in the builder, I work through these checks in order.

Run Profiles and a Deliberately Broken Node

The most frequent complaint in the room was the iteration loop: edit the workflow, publish it, return to the app, refresh and inspect. There are two ways to shorten it.

One is useDraftWorkflowWhileDeveloping in the app JSON. An agent has only two versions at a time, draft and published, and this setting directs the app to the draft while you work.

The more capable option is a run profile in the workflow debugger. Set the trigger type to Agentic App, then choose Initial Display to inspect the rendered result or Invoke Action to supply a payload in the form the app sends. In my lab, that payload was ScheduleCheckin, ScheduleCheckin(101). You can use breakpoints, Step, Resume, Rerun From Node and input overrides without leaving the editor.

Oracle taught this with a deliberately broken node in Lab 2. A “Create Check-in Document” business object function returns a 400 response with five missing-value errors, so participants diagnose a real failure instead of stepping through a successful workflow. That deliberate fault is why the debugger exercise stayed with most of the room.

I would create the run profiles at the start of a build, before the publish-and-refresh loop has taken up a morning.

A Twenty-Minute Reproduction

You can reproduce the behaviour above on a pod you already use, without first building anything.

1. Open one of your own agentic apps and place the browser console beside it. The labs use a compliance app with four audit agents. Enter turnOnDebugging() and confirm that the console replies “Agentic Apps debug mode enabled”.

2. Refresh the page. The five startup hints should appear in sequence, each with the responding agent and elapsed time. Filter for “Summary” to see the Partial Summary consolidation.

3. Open the same agent in Workflows. Under Settings, then Details, find Expose to Agentic Apps. The adjacent fields capture estimated time and cost saved per run.

4. Open the message-hint Switch and inspect the case values. The panel shows the ten published hints. Also note that the visible part of the case expression begins {{$context.$triggers.; the namespace ambiguity is discussed below.

5. In Debug, create an Agentic App run profile in Initial Display mode. Run it to inspect the app output in the editor. Then add a breakpoint and step through it. Lab 2 uses the broken business object call described above, which is worth recreating simply to learn the debugger.

Doing this with your own agents on your own pod makes the execution model observable rather than something you have to accept from my account.

Where This Leaves You

The most useful model is to treat an agentic app as a rendering shell with a message contract. The logic, data access and security normally associated with a backend live in branches of a workflow agent, and that workflow starts at the top on every call.
For an architecture review, I would therefore focus on which agent handles each hint, what it can fetch and how many contributing agents the app runs on every open. The console gives you timings for that discussion instead of relying on impressions.

Sources: Oracle AI Agent Studio partner enablement, attended in person 17-19 August 2026. The claims, the judgements and any errors are mine. Views are my own, not my employer’s or Oracle’s.

The morning after, I cloned the repo instead of building an agent. Every README, all 94 sample workflows, the CLI’s full command surface, both how-to guides - with Claude reading and parsing alongside me, because 94 workflow files is not a weekend well spent by hand. The repo says more about where Oracle thinks enterprise agents are going than anything said on the Live. Some of it Oracle hasn’t said out loud at all.

The most revealing thing in it isn’t a demo. It’s a ratio: across all 94 sample workflows, Oracle builds four deterministic nodes - plain code and branching logic, no model call - for every one LLM call. Here’s what that, and the rest of the drop, tells you.

Quick summary - the headlines:

• The sample library is 83% not AI. Across 94 workflows there are 1,481 pipeline nodes; only 247 (16.7%) call an LLM, and plain CODE nodes outnumber LLM calls 420 to 247. Twenty-eight workflows - almost a third contain no LLM node at al - This is intentional design choice - every LLM node is a latency risk and a potential billable event.

• Every sample is a workflow graph. Zero .agent or .topic files ship in this drop. Read it as a steer: workflow teams are the pattern Oracle trusts inside the 60-second response window.

• The CLI ships a full evaluation harness - test generation, LLM-as-judge scoring, model sweeps, token analysis - that the install guide doesn’t cover yet. It’s the most forward-looking thing in the box, and no independent run of it has been published.

• The quarterly update replaces your folders wholesale. Only src/ survives. Fork a sample in place and the 26D uptake deletes your work.

• Codex is the documented assistant, not a requirement. The skill format is the open Agent Skills convention; the same skill runs under other coding agents unmodified.

Read on for the full breakdown.

What Actually Landed

The repo (github.com/oracle/fusion-ai-studio) was created on 26 June and went public alongside the 14 July announcement. Inside the release-26C/ folder: a VS Code extension (a .vsix inside a ZIP), the aistudio agent skill with a Node CLI inside it, two domain skills (succession management and warehouse shortages), and a sample library spanning eleven HCM modules, General Ledger insights, and three SCM modules.

The housekeeping tells its own story: UPL licence, no external pull requests accepted, one branch, no tags, publish-only commits. Development happens inside Oracle, GitHub carries the releases. This is a delivery medium for a quarterly drop, not an open-source project in any community sense - there’s no pull request to file, no maintainer to watch respond to an issue.

The functional shape is genuinely new for Fusion, though. Agent Studio artefacts - workflows, business objects, apps, tools - now exist as JSON files on your laptop: created locally, edited locally, pushed to the environment through a CLI. Configuration you can diff, review, and version. Leone framed it as the foundation for modern AI software engineering, and for once the architecture backs the sentence.

What the Sample Library Really Teaches

The demos show how fast you can build. The samples show how Oracle thinks you should build - and the single most useful thing to learn here is the number: four deterministic nodes for every LLM call.

Use it three ways:

• As a design-review shortcut. When your proposed workflow is mostly LLM nodes, the question should be - which of them a CODE or SWITCH node could replace?

• As a cost-model input. The node mix, not the use-case count, is what drives AI Units consumption - the ratio gives you a realistic baseline before anyone signs a forecast.

• As a scoping anchor. Start from the nearest sample, not a blank canvas. The median shape is ten nodes; anything sprawling past xx_worker_search (roughly 80 nodes) probably needs decomposing.

Here’s the count behind it. I had Claude parse the dataPipeline of all 94 sample workflows and count every node.

Strip the START/END scaffolding and deterministic nodes outnumber LLM calls roughly four to one. The median sample has ten nodes, two of them LLM. The largest, xx_worker_search, runs roughly 80 nodes with 13 LLM calls. And 28 of the 94 - almost a third of the reference library - contain no LLM node whatsoever.

The samples are also exclusively workflow graphs: no .agent or .topic artefacts in this release, and the README marks Workflow Teams as the recommended architecture. Read that as a steer. In the agentic-app context, where every response has to land inside the 60-second window, Oracle is showing you the pattern it trusts.

And the restraint is the craft. Every LLM node is a latency risk and a billable event. I covered the AI Units arithmetic in my pricing piece, these samples read like they were built by people who did that arithmetic too. In a field where most vendor demos maximise the AI on show, shipping a reference library this disciplined is a quietly confident move.

Hold onto this: the sample library is a style guide. The fastest way to raise your team’s first build is to make reading it part of the design phase.

The Evaluation Harness Is the Quiet Headline

The install guide walks a first-time user through setup with genuine care, and it stops there - fair enough for a first release aimed at getting people building. The CLI’s --help output is where the release shows its longer game.

Roughly 25 commands sit beyond the guide: do-generate-workflow-test, run-workflow-tests, compare-workflow-test-runs, run-optimization-sweep, analyze-token-usage, and more. Together they add up to LLM-as-judge evaluation, regression comparison across runs, per-node model overrides, and automated cost-optimisation sweeps - sitting next to a full policy lifecycle and the non-interactive login a CI pipeline needs.

Oracle showed this working at the 14 July session. The live model-downgrade demo switched two of six capabilities to a lower-tier model for the same quality at lower cost and latency. That demo maps directly onto run-optimization-sweep and get-workflow-model-override-targets. This is the part of the release that turns agent building from a craft into a discipline, and it deserves more attention than the fast-build demos you have seen so far. The honest caveat: the harness is demo-proven, not field-proven. The bundled guide doesn’t cover it, the samples ship without example tests, and I can’t find a published account of anyone running it independently - mine included, which is why it’s next on my lab list. Documentation usually catches up a release or two after the machinery lands. What matters is what you do in the meantime.

The real so-what, in three parts:

• Your definition of done changes. Once test generation and judge scoring are one CLI command away, a workflow without a test and a judge result attached is a draft, not a deliverable. Write that into your delivery standard now, ahead of the tooling becoming table stakes.

• Your evidence trail changes. When an AI assistant authored the workflow, the judge results are the review artefact your auditors - and your own QA - will actually accept. Keep them with the release record.

• Someone needs to own it. Give the harness to whoever owns test scripts on your programme today, and have them run it against one sample workflow this month. The teams that learn it early will set the standard the rest inherit.

The Quarterly Update Eats Your Folder

The second how-to in the repo covers uptake, and it is blunt: when a new release drops, you replace aiapps/ wholesale, the aistudio skill folder wholesale, every domain skill folder wholesale. The only directory that survives is src/ - the things you built yourself.

Follow the thread. The natural first move for any consultant - copy the succession-management sample, rename it, adapt it - is precisely the move the update model punishes. Copy the pattern into src/, never fork the file where it stands. And every quarter, everything your src/ work sits on shifts underneath it.

Which is exactly what regression evaluation is for. The uptake model and the evaluation harness are two halves of one story: a quarterly refresh of the base is comfortable only if you can re-run your evals against it and diff the results. The survival kit ships in the same box - the guides just haven’t joined the dots yet, so join them yourself.

The sentence to lift into your delivery methodology: re-baseline your workflow evals as a standing step of every release uptake.

Codex on the Box, Any Agent in Practice

The bundled how-to sends you to developers.openai.com to install Codex, and every demo you’ve seen runs on it. Oracle’s own press release is broader - it names OpenAI Codex and Claude Code as supported assistants - but the only install guide in the repo documents Codex alone, and that guide is what your consultants will actually follow. Worth being precise about what this does and doesn’t mean.

The skill itself is packaged in Agent Skills format - the open standard Anthropic published, since adopted across the major coding agents: a SKILL.md with prompt references and scripts under .agents/skills/. Nothing in it is Codex-specific, the CLI is plain Node, invoked by whatever coding agent reads the skill. I’ve had this exact skill running under Claude Code and GitHub Co-Pilot in my own setup. Codex is the documented path, not a dependency.

Three practical consequences:

• No assistant lock-in. Whatever coding agent your firm has already put through security review can drive this.

• A data-governance question - flag it to your CTO early. The documented flow has functional consultants signing into a third-party AI assistant and handing it local files describing your org structures, GL logic and talent data context. Someone needs to answer which enterprise agreement that session runs under before the first laptop does it in anger.

• A second meter running. Every coding-agent session against the CLI burns its own tokens, on top of whatever AI Units the workflow consumes once live. Budget for the assistant plan alongside the AI Units - agentic development bills on both sides of the keyboard.

And for those keeping score in the protocol wars: nobody abandoned MCP here. MCP remains a first-class tool type inside Agent Studio, where a running agent calls a live system. The CLI and skill live on the other side of the line, where artefacts get authored. Runtime integration and build-time authoring were never the same problem, and Oracle has just drawn the boundary where the rest of the industry has been converging on it.

Before Your Team Clones It

Credit first: the platform closes more of this than a generic security take admits. The CLI encrypts the Basic Auth password it stores in env.properties. Artefacts pushed to the server run inside Fusion’s security model, and business-object access rides the requesting user’s context. The residual list is short - which is rather the point:

• The extension is a side-loaded .vsix out of a ZIP. Enterprise endpoint policies commonly block exactly that. Getting it whitelisted is your first blocker, and it isn’t a technical one - start it before the kick-off, not after.

• Oracle’s .gitignore ignores only a single build script, and the quick-start builds inside the cloned repo. The moment a workspace goes under git - the whole direction of travel - env.properties is one careless git add -A from being committed, carrying your pod URL and username even with the password encrypted. Write the ignore file first.

• One environment per workspace. env.properties holds a single host. If test is on 26C and prod is still on 26B, that’s parallel workspaces and parallel skill versions - plan the folder layout before ten consultants invent ten conventions.

• Nothing mandates a review before a push to a live environment. do-save-workflow deploys, and the toolchain puts no gate between the coding agent and the save. For HCM that’s a conversation, for the General Ledger samples it’s an audit finding waiting to be written. Put a human diff in the path, and keep the judge results as your evidence trail.

What To Do This Week

Three moves, in order:

1. Clone the repo and run the node census on the samples nearest your own use cases. The pattern you should copy is sitting in there, counted.

2. Get the .vsix in front of whoever owns your endpoint policy. It’s the long pole, and it isn’t technical.

3. Run do-generate-workflow-test against one sample workflow and see the judge machinery with your own eyes - before anyone on your programme claims an agent is production-ready without it.

The samples answer what Oracle thinks agents should look like. The harness decides whether yours actually work. No doubt, Oracle will keep refining this and adding to it but there's already enough here to be worth the time of anyone creating, deploying or managing agents today.

Sources: the oracle/fusion-ai-studio repository, its bundled guides and CLI, and my own analysis scripts against a fresh clone. Node counts are reproducible from the repo’s release-26C sample set. Oracle product names and any screenshots remain the property of Oracle Corporation. Views mine, not my employer’s.

An OpenAI model broke out of its sealed test environment and hacked Hugging Face. Nobody told it to. It was trying to pass a benchmark, decided the answers were on someone else’s servers, and went and took them.

What Actually Happened

OpenAI was benchmarking GPT-5.6 Sol and an unreleased, more capable model on ExploitGym, a public set of 898 real-world software vulnerabilities - refusals dialled down for the evaluation, inside an isolated sandbox. The models found a zero-day in OpenAI’s own internal package registry proxy, escalated to admin, moved laterally until they reached a node with internet access, worked out that Hugging Face probably hosted the benchmark solutions, and broke in.

Hugging Face’s own incident report describes the other end of the same attack: “A malicious dataset abused two code-execution paths in our dataset processing” - a remote-code loader and a template injection in a dataset config. From there the agent leaked cloud and cluster credentials, moved across internal clusters, planted decoy activity to slow investigators, and ran up more than 17,000 logged actions. It reached a limited set of internal datasets and several service credentials before it was stopped.

OpenAI's own assessment: the models were "hyperfocused on finding a solution". That is the whole story in three words. The sandbox was not a boundary to them. It was an obstacle between them and the score.

The Clean-Up Nobody Would Help With

Here is the part that should worry you more than the breach. When Hugging Face’s incident response team tried to point US frontier models at the forensics - 17,000-plus attacker events to analyse - the models refused. Hugging Face’s words: “these requests were blocked by the providers’ safety guardrails, which cannot distinguish an incident responder from an attacker.” The exploit payloads and command-and-control artefacts a blue team needs to read are, character for character, the things a safety classifier is trained to reject.

So they ran the analysis on GLM 5.2, a Chinese open-weight model, on their own infrastructure. That choice carried a second benefit they name explicitly: no attacker data and no exposed credentials left their environment.

Attackers get an unrestricted agent. Defenders get a refusal. Sit with that, because it is now a live input to every AI security conversation you are in - and it will not resolve soon. Guardrails that can tell a legitimate responder from an attacker performing the identical action are a genuinely hard, unsolved problem.

The Warning Was On arXiv Eighteen Months Ago

If this feels familiar, it should. In February 2025 Palisade Research published Demonstrating specification gaming in reasoning models: asked to beat a chess engine, models like OpenAI o3 and DeepSeek R1 “will often hack the benchmark by default” - editing the game state rather than losing. Most of us filed it under lab curiosity. Eighteen months later the same instinct chained zero-days across two companies’ production systems to win a different game.

The lesson was never that AI is malicious. It is that optimisation pressure finds every path you did not fence off. The model does exactly what you rewarded - it just does not share your unstated assumption that “solve the benchmark” excludes “break into a third party to read the answer key.”

What To Actually Do Before Your Next Agent Ships

Before you reach for a control list, give the platform its due, because a lot of what failed here is closed by default in Fusion. A business-object tool runs under the requesting user’s own Fusion token, so an Agent Studio agent inherits that person’s identity and data security - it does not carry a standing super-credential of the kind the attacker harvested. Agents inherit Fusion’s security policies and access controls, the Security tab gates who can reach a team, and the agent is not executing arbitrary code on a node with open egress - it calls registered tools and a managed model endpoint, not the open internet. Most of the generic “give it least privilege, fence the network” advice doing the rounds this week is describing controls you already have.

What the defaults do not cover is a shorter, sharper list - and it is where this incident should actually change your build:

Custom REST and MCP tools are where the identity binding breaks. Business-object tools ride the user’s token; a REST or MCP tool you build reaches outside that model on whatever credential you stored against the connection. Oracle’s own secure-by-design guidance says to design these tools to preserve identity - that stored service credential is this breach’s “reach far beyond the job” in miniature. Scope it to the task, and do not let convenience turn it into a standing key.

The agent is only as least-privilege as the role behind it. Because tools inherit data security, an over-broad duty role - or exposing the team to a highly privileged user - hands the agent exactly that reach. Prune the fields a business-object tool exposes, and run a Segregation of Duties check (map it to Access Governance) before you compose any transaction-writing workflow. The platform enforces the role; it does not decide the role is too wide.

Put a human on the irreversible step, by risk tier. Risk-classify the team - Low for info Q&A, up to Critical for payments, payroll, supplier banking - and set Require Human Approval on the High and Critical actions. This is the specification control in Studio’s own language: the model will honour the goal you set, so the human sits on the step you cannot take back.

Trust the instruction hierarchy, and treat inbound data as hostile. Studio ranks trusted policy above tool output above user request - keep it that way, and keep trusted instructions separate from untrusted content. Hugging Face’s entry point was a malicious dataset: content the system ingested and acted on. Ask the Palisade question of every agent before it ships - what is the cheapest path to this reward that I would be appalled by? - then close it in the environment, not the prompt.

And one control that lives above Studio entirely: do not assume your AI tooling will co-operate during an incident. Hugging Face’s fix was a locally hosted open-weight model that would actually read the attack logs when the commercial ones refused. If your IR plan quietly depends on a frontier model to triage an attack, that dependency fails at the exact moment you need it. Know which model your team can run on your own infrastructure, before the day you need it.

The model honours the goal you set and none of the assumptions you left unsaid. That is the sentence to lift into your agent governance framework - before the next deployment, not after the post-mortem.

Sources:
Hugging Face security report (16 July 2026)
OpenAI incident disclosure (21 July 2026)
Palisade Research, arXiv:2502.13295 (February 2025)
Reporting by Fortune and The Stack.

This is my own view, not my employer’s. Diagram is my own.

Disclaimer: Everything below is taken from Oracle’s official 26C readiness documentation for Common Technologies and User Experience, published this week. These are confirmed 26C features, not roadmap items. As always, functionality described in readiness documents can change at Oracle’s discretion before it reaches your pod.

The 26C readiness notes landed this week, and the question you’ve been getting from clients and colleagues would be the usual one: what’s actually new, and what do I need to do about it?

The honest answer is that the headline of 26C is not a new agent. It’s the platform underneath the agents. Steve Miranda has talked about the installed base growing from maybe a hundred agents at launch to well over a thousand. At that scale, the question customers face changes from, Can we build an agent for this? to How do we run all of these properly? 26C is Oracle’s answer to that second question, and it makes this one of the most significant quarterly update for AI Agent Studio since the product launched.

Quick Summary

If you just want the headlines:

1. AI Configurator is deprecated in 26C. All prompts configured there must be re-created and re-validated in AI Agent Studio.

2. A new Debugger lets you pause on a node, step through a flow one node at a time, rerun from any point, force a node's output to test what follows, and save reusable run profiles.

3. A new command line interface (CLI) works standalone or through the VS Code extension, and supports Codex-assisted and Claude Code-assisted editing.

4. Policy Models bring deterministic, repeatable decision logic into agent workflows through a new policy node.

5. The open Agent2Agent (A2A) protocol lets published Fusion agents be discovered and called by external agents, and vice versa.

6. Long-running sessions support multi-day agent conversations. Long-term memory adds episodic memory notes and user preferences shared across agents.

7. Bring Your Own LLM is now available via a service request to My Oracle Cloud Support, typically completed in two weeks, when OCI is your model provider.

8. HCM administrators are now scoped by product family for prompt configuration.

AI Configurator Is Deprecated

The change that might consume the most project hours is also the one buried deepest in the notes. AI Configurator - the prompt editor built into HCM Experience Design Studio for locally editing prompts behind embedded AI features - is deprecated in 26C. Any prompts you configured there must be re-created and re-validated in AI Agent Studio. The old tool stays accessible, but only so you can copy your prompts out of it.

There’s a governance change riding along with this. HCM administrators are now scoped by product family, so a compensation admin can no longer edit recruiting prompts. In multi-pillar implementations that’s a welcome improvement - it just needs to be in your security design before the upgrade, not discovered after it.

If you’ve customised AI Assist prompts across recruiting, talent or HR over the past year, this is a real migration and regression testing exercise, and it lands in the same window as your normal 26C testing. I cover what that means practically in part two. The short version: treat it as a workstream with an owner, not a line on the upgrade checklist.

The Debugger

Agent Studio finally has a real debugger for agentic flows. Drop a breakpoint on a node and execution pauses there, so you can walk the flow one node at a time rather than watching it run end to end. From any node you can rerun forward, and you can pin or override what a node hands back to see how everything downstream reacts to a value you’ve forced in. The test setups you keep coming back to get saved as run profiles, so you’re not rebuilding them by hand every time.

For anyone who has sat reading trace logs trying to reconstruct why a team of agents produced a daft answer, this is the part of 26C that changes the day job most. Agent misbehaviour used to be something you reasoned about after it happened. Now you can halt the flow mid-execution and watch the decision being made. That pays off twice in delivery. Defects surface during the build instead of in a client demo, and the reasoning becomes visible enough that “the agent just did that” stops being a good enough answer for anyone in the room.

The CLI

There’s now a command line interface for Agent Studio, run on its own or from a terminal inside the VS Code extension. It handles the whole lifecycle of an artefact locally. You author it, validate it, debug and test it, then save it back, so none of that has to happen in the browser canvas any more. Artefacts can be validated before they’re handed on, and the part worth dwelling on is that it supports building and editing agents with Codex and with Claude Code.

Two years ago, Oracle baking first-class support for rival vendors’ coding assistants into its own product would have raised eyebrows. It is the right move regardless. Once an agent lives as a file on disk, it can sit in version control, go through the same peer review as any other change, and move across environments like normal code. The canvas is not going anywhere for business users. The CLI is there for the teams who have outgrown it.

Policy Models

You can now create policy models in Agent Studio for reliable, repeatable, deterministic policy-based decision-making at runtime, invoked from agentic workflows through a new policy node.

Approval limits, eligibility tests, the compliance checks where 'mostly right' is simply a fail, all of that can now be expressed as deterministic policy logic, with the LLM's probabilistic reasoning kept for the parts of the flow that genuinely need it. Clients have been asking how to get deterministic behaviour out of agentic workflows for a year, and until now the honest answer involved workarounds. Now it’s a platform feature.

Agent2Agent (A2A)

Published Fusion agents can now collaborate with agents on other platforms through the open A2A protocol. One thing to hold onto: an Agent Card broadcasts what an agent can do to anything that comes looking, so publishing needs to be a deliberate, per-agent decision rather than the default setting.

In practice this means an agent in Slack or Teams can ask a Fusion agent a payroll question and get a properly governed answer. One thing to hold onto: an Agent Card broadcasts what an agent can do to anything that comes looking, so publishing wants to be a deliberate, per-agent decision rather than the default setting.

Long-Running Sessions and Long-Term Memory

Two related changes. First, agent conversations can now stretch across extended, including multi-day, interactions. If the system needs time to work through a complex query, or you need to leave the conversation to gather data, you can rejoin the same conversation in progress.

Second, agents get long-term memory, in two components. Episodic memory captures summaries of past interactions as memory notes, generated automatically through a memory curation process. User preferences are shared across agents, so a person gets a consistent experience regardless of which agent they’re talking to.

Shared preferences across a thousand-agent estate is what makes the whole thing start to feel like one assistant rather than a directory of bots. One thing to flag to your privacy team early: memory notes are derived personal data, and most organisations don’t yet have a retention position for them. Better to write one now than after the first data subject access request mentions it.

Bring Your Own LLM

You can now request enablement of additional supported LLMs through a service request to My Oracle Cloud Support. Most requests are completed within two weeks. More complex model integrations can take up to four. The BYOLLM path applies when Oracle Cloud Infrastructure is selected as the model provider, and doesn’t apply to the basic and premium models Oracle provides itself. For reference, Oracle’s published line-up in Agent Studio currently includes GPT 5.1 mini, GPT 4.1 mini and GPT-OSS-120B.

Model choice has been the loudest ask from regulated clients since Agent Studio launched. Now that the choice is available, the accountability comes with it - which model runs which workload becomes a decision your architecture governance owns, with cost and behaviour consequences attached. The cost side matters more than it used to, for reasons covered in part two.

A Note on the Agentic Applications Builder

You’ll see the Agentic Applications Builder mentioned in a lot of 26C coverage - the natural-language, low-code builder for assembling agentic applications from Oracle, partner and custom agents, announced in Oracle’s London press release on 24 March. Worth knowing: in the readiness documentation it sits under 26B, not 26C. It’s part of the same platform story but if you present it as a 26C feature in front of a client, someone will correct you, and they’ll be right.

What to Make of All This

Taken together, 26C reads like Oracle deciding that agents are software and should be treated accordingly. A debugger, a CLI, version control, deterministic policy logic, a standard interoperability protocol - this is the toolchain you’d expect around any serious development platform, and until this quarter Agent Studio didn’t have it.

The consolidation matters too. With AI Configurator gone, Agent Studio becomes the single place where all prompt configuration and agent management happens. That’s cleaner architecture and better governance, at the price of a migration that every customer with customised prompts now has to run.

That said, most of what’s new in 26C only pays off if implementation teams actually use it. Breakpoints, run profiles and peer-reviewed agent definitions are only valuable to teams that bring engineering discipline to agent work, and in my experience most programmes aren’t set up that way yet. The platform has grown up faster than the delivery practices around it.

Part two covers the other half of the story: what 26C asks of your ERP/HCM programme specifically, the agent landscape across all nine pillars, and the pricing question I can only partly answer.

This is the first of two technical follow-ups. This one is about what’s inside an agentic app from the user’s side: the philosophy that shapes the design, the four-region UI, the protocol that wires it together, the visual vocabulary of widgets, and the communications model.

The architecture stack, the agent orchestration patterns, and the AI Agent Studio tooling are in the second post.

Quick Summary

If you are only after the technical headlines:

• Fusion agentic apps are built around four design principles: Proactive Alerting, Decision Support, Action-Oriented Intelligence, Context-Aware Prioritisation.

• Each principle maps to specific technical primitives - InitActions + priority: true, <oraInfoDisplay> + 7 widgets, ora.Invoke() + followUpCommand + <oraFormSubmit>, $OraUserContext + $OraMessageHint.

• Every agentic app shares the same four-region UI anatomy: Advisor (Ask Oracle), Information Summary, Priority Actions, Communications.

• Those regions map to four capabilities - Information Display, Advisor, Actions, Communication - this is what closes the loop from data to decision.

• The app talks to its agents through $OraMessageHint - 10 enumerated hints across 3 lifecycle moments, routed through a Switch node, with a 60-second response window.

• Information is displayed through a finite catalogue of seven declarative widgets: Chart, Card, Message List, Change List, Multi Record, Record, Sankey.

• Communications converge on a five-step lifecycle - Suggest, Prefill, Fill, Review, Send - with a non-bypassable User Review step. As Aarti Satyamurthy at Oracle puts it: “The agent moves the work. You keep the accountability.”

Read on for the full breakdown.

The Four Design Principles

Four design principles shape every Fusion agentic app. They are worth reading carefully because each one maps directly to a piece of the architecture you’ll see later.

Proactive Alerting. Don’t make users hunt for problems. Surface critical issues the moment they matter. A compliance certification expiring next week shouldn’t wait for someone to open a dashboard - the app proactively surfaces it before the user asks.

Decision Support. Filter signal from noise. Present synthesised insights with clear recommendations and trade-offs, not raw data points. The principle is: if it’s purely informational, dashboard would suffice. An agentic app earns its place by helping the user decide.

Action-Oriented Intelligence. Every interaction should lead to a concrete action - approve, escalate, renew, investigate. No dead-end views, no read-only summaries that leave the user with a follow-up tab to open.

Context-Aware Prioritisation. Not all alerts are equal. Agents understand business goals and user roles, surfacing what’s urgent and holding what can wait.

Aarti Satyamurthy summarised this as “Philosophy drives architecture. Architecture enables experience.” in her last post. That’s the right way to read what comes next. Each piece of the framework below exists to make one of these four principles real.

Principles → Technical Primitives

The principles are not a marketing layer. Each maps to specific technical capabilities in the AI Agent Studio framework.

If you’re building or extending an agentic app, that table is the cheatsheet. Each principle has named primitives you will be working with directly.

The Four Regions and Four Capabilities

Every Fusion agentic app shares a four-region UI on screen.

An Advisor at the top, branded “Ask Oracle”. An Information Summary in the body. A Priority Actions rail on the right. A Communications rail underneath.

Those four regions map cleanly to four capabilities the app delivers.

Information Display is context that comes to the user. Agentic apps do more than just retrieve data, they generate context dynamically at startup, with the right widget chosen based on what the user needs to understand.

Advisor is built-in expertise on demand. Ask Oracle is a 24/7 expert panel embedded in the workflow. Natural-language questions, responses grounded in business context and policy, drawing on specialised agents or coordinated agent teams.

Actions is from insight to execution. The agent presents structured decision points with one-click execution inside the app itself. Prasanna Borse at Oracle Product Development describes this as “no swivel chair, no handoffs.”

Communication is proactive and embedded. The agent drafts messages and suggests follow-ups and the work doesn’t end with a decision, it requires follow-through.

All 22 apps in release 26B share this same four-region shape.

The $OraMessageHint Protocol

Aarti Satyamurthy covered this protocol briefly last month. It’s called $OraMessageHint - a contract between the app shell and the agent team. Ten enumerated hints across three lifecycle moments.

At app startup, five hints fire in parallel - InitSubtitle, Summary, InitDisplay, InitActions, InitCommunications - populating the four regions before the user even clicks.

When the user engages, three more - Query (carrying $chatHistory for Ask Oracle conversations), InvokeAction (carrying $OraAction when an action is executed), AdditionalContent (carrying $OraPanelName when a panel needs more detail).

When communications flow, two more - FillParameters (carrying $OraCommsParamsToFill), SendCommunication.

Workflow agents inside the app route hints through a Switch node on $context.$app.$OraMessageHint. Each case maps to a purpose-built LLM or Agent node - Summary goes to a Handle Summary LLM node, InitDisplay to a Build Display Agent node, Query to an Answer Q&A node carrying chat history. Structured prompts per branch. 60-second response window. One agent team, ten entry points.

That’s why Workflow Teams are the recommended architecture for agentic apps - structured routing, custom prompts per request type, and predictable latency inside the response window.

The full context-variable system that flows alongside the hints is wider than just $OraMessageHint:

• $OraUserContext carries the invoking user’s identity (name, role, ID) on every request.

• $OraAppContext carries app-level initialisation context.

• Per-hint context expressions: $chatHistory, $OraAction, $OraPanelName, $OraCommsParamsToFill.

Message hints are not merely plumbing but the contract between the app and the agents - the reason an agentic app feels coherent instead of chaotic.

The Seven Widgets

The Information Summary region isn’t free-form copilot generation. It’s built from declarative widgets - pattern-based components with published JSON schemas. The agent’s job is to populate one of seven widget types with structured data and the UI renders it once done.

The full catalogue:

chartWidget - Trends over time, category comparisons, proportions. Line, bar, or pie. Multiple datasets supported. Example: a monthly revenue trend with an insights summary block.

cardWidget - One critical alert that deserves its own focus. Variant for severity (error, warning, info). Example: a CRITICAL system alert for High CPU Usage with an Investigate button.

messageListWidget - Multiple alerts with individual priority, badges, timestamps, and inline actions. The workhorse for triage. Example: Compliance alerts (3 min ago), Pending approvals (12 min ago). Prevents alert fatigue.

changeListWidget - KPI tracking with automatic percentage-change calculation. Feed it current and previous values; the widget handles direction and percentage. Display modes: percentage, raw, currency. Example: Conversion Rate 2.8 → 3.5 (+25.0%).

multiRecordWidget - Tabular data with badge-style status cells and per-row actions. Example: a transactions table for employee roster.

recordWidget - One record’s worth of fields, in either read-only display mode or editable form mode. Field types: text, textarea, number, date, select. Example: an Employee Profile form with Full Name, Hire Date, Department.

sankeyWidget - Flow diagram with proportional link widths. Nodes are stages, edges are movement, link widths reflect volume. Example: Support ticket funnel, hiring pipeline with proportional widths exposing where the funnel narrows.

Quick decision rule:

• Single alert → cardWidget

• Multiple alerts → messageListWidget

• KPI comparison → changeListWidget

• Tabular data → multiRecordWidget

• Data visualisation → chartWidget

• Form or detail view → recordWidget

• Flow or funnel → sankeyWidget

The catalogue is finite and known, and in my opinion it is the reason the visual layer of an agentic app feels coherent across the 22 apps and across customer extensions.

Communications: The Trust Contract

Of all the pieces in an agentic app, the communications model is the part of the design that’s been thought through most carefully.

Two creation paths with the same lifecycle.

APP-DEFINED templates are configured once in the Builder, linked to a template, and reused whenever the situation calls for it. Email, text, PowerPoint, PDF. Best for repeatable communications: weekly status updates, standard compliance alerts, executive briefings.

AGENT-GENERATED runtime content is what the agent drafts on the fly when a situation is one-off. Email and text only. Strict rules: no placeholders, no fabricated data.

Both converge on a five-step lifecycle:

1. Suggest. Agent recommends the right communication for the moment based on context.

2. Prefill. Agent fills the parameters it already knows from prompting, knowledge, and current context.

3. Fill. When the user selects it, the agent completes the remaining parameters.

4. Review. The user inspects, modifies, and approves before anything leaves the system. The non-bypassable node.

5. Send. A designated delivery agent dispatches the message via email, Slack, PDF, or PowerPoint.

Notice what’s not in that list: any step where the system sends without the user seeing it first.

Aarti’s framing on this was:

“Communications are always outbound. Always reviewable. Always under human control. That’s the trust contract. The agent moves the work. You keep the accountability.”

That’s the sentence to lift into your governance framework when you’re setting up these apps in your environment.

The architecture stack, the agent orchestration patterns, and the AI Agent Studio tooling are in the second technical post. If you’re building or extending one of these apps, that’s the read you’ll want next.


Disclaimer: This is my best reading of Oracle's Fusion Agentic Applications based on Oracle's public press releases dated 24 March and 9 April 2026 and conversation with Oracle product development team, technical posts by Oracle staff, and independent analyst coverage through May 2026.

The announcements in AI World Tours have been different. Oracle has shipped a new category of enterprise software, not a new AI feature, and named 22 of them across ERP, SCM, HCM, and CX.

If you’re a Fusion architect or functional lead, the architecture underneath is good, the on-prem boundary just moved in a way that should change your Q3 plans, and release 26C will hit your tenant sooner than your release-management process is ready for.

Quick Summary

If you just want the headlines:

• Oracle has named 22 agentic applications across ERP/SCM (12), HCM (7), and CX (3). All included in Fusion at no additional subscription cost today.

• Customer-side activation begins with release 26B.

• The category is truly new - composable workspaces orchestrating teams of specialised agents around a business outcome. Most things called Agentic AI in 2025 are still single agents or fixed workflows.

• Oracle has drawn a hard SaaS-only line. It remains to be seen how these will affect EBS, PeopleSoft, JD Edwards and Hyperion.

• The engineering claim worth taking seriously: agents execute as the invoking user, inheriting RBAC and approval hierarchies, not as a service account.

• Architecture is real, adoption is yet to be proven, and Forrester’s line - “agent supply is strong, adoption proof is not” - is somewhat of an honest take.

Read on for the full breakdown.

What’s Actually New

The taxonomy goes AI Agents > AI Workflows > Agentic Apps. Goal-based single agents, then multi-step logic-based automations, then composable workspaces that orchestrate teams of agents around an outcome. The third pattern is the new one.

Most of what’s been called “agentic AI” in 2025 - parts of Agentforce, parts of Joule, large parts of Copilot - sits in the first two buckets.

I've watched Fusion users do exactly the manual orchestration agentic apps are supposed to compress i.e. hire-to-retire, workforce planning, to name a few.

That distinction is the one to take into your roadmap conversations.

What Oracle Is Saying

Enterprise software has historically been a system of record. It documents the business, follows fixed rules, retrieves information, completes tasks the user initiates.

Oracle is staking Fusion’s next decade on a system of outcomes. Software that works toward objectives without a human stitching steps together.

The shared foundation is what Fusion has always been good at - enterprise data, business objects, policies, approval hierarchies, RBAC. The agentic apps don’t replace that foundation. They sit on top and orchestrate against it.

Most AI shipping in 2025 was new presentation over old transactions - chat over the same forms. Oracle is describing something different. A new application tier that takes business objectives as input and produces outcomes as output, calling existing transactional Fusion modules along the way.

If You’re on EBS, PeopleSoft, JDE, or Hyperion

One important thing to note is Rondy Ng’s comment during April Applications Analyst Summit -“These agents are not coming to [EBS]. They’re not coming to our on-premises solutions, to JD Edwards, to PeopleSoft, to Hyperion. To enable this, you have to get to SaaS.”

If true, that’s Oracle telling roughly half its installed base that the system of outcomes is Fusion-SaaS-only (for now at least). EBS, PeopleSoft, JDE, and Hyperion stay in the system-of-record world for the rest of their support lifetime.

Oracle’s mitigation plan is a new enterprise configuration agent that ingests EBS, PeopleSoft, and JDE metadata and proposes a Fusion enterprise structure. Work that took SIs months now runs in hours. Real and useful, and commercially convenient. It accelerates the migration funnel Oracle has been trying to fill for a decade.

If you’re on a legacy stack, Q3 isn’t a multi-year migration. It’s negotiating the bridge to Fusion AI in 12-18 months and locking renewal guardrails before pricing models move.

The 22 New Apps

Oracle named 22 agentic applications across three suites - 12 in ERP/SCM, 7 in HCM, 3 in CX. Announced on 24 March 2026 at Oracle AI World London, with follow-on press releases on 9 April.

All 22 are included in Fusion starting 26B.

Forrester is expecting staggered maturity but from what I have seen in last few weeks, there is enough evidence that the delivered agentic applications are good enough to start with and will only improve moving forward. The ledger agent is in production, FP&A and consolidation apps demoed live, Collectors and channel-revenue apps are expected this year.

The 22 also sit above a larger inventory of individual agents - Payables, Ledger, Planning, Claims Settlement - embedded in Fusion modules for longer. It’s best not to conflate the two layers.

In the table below, each workspace is collapsed to a primary user and a primary outcome.

How It Stacks Up

It’s worth holding this up against where the other three big platforms are.

SAP Joule has the good enough inventory - 40+ agents and 2,400 skills but the friction point is adoption. DSAG’s independent survey found only around 3% of SAP customers running it in production. Pricing through AI Units, at around €7 per unit with 12-month expiry, has been a real sticking point for SAP. And Joule needs RISE or GROW - it doesn’t run on-prem. So Oracle is ahead on transactional depth and on suite breadth in a single product motion.

Salesforce Agentforce is where Oracle should probably watch out. Salesforce posted $2.9B ARR, 29,000 deals, and 2.4B Agentic Work Units in FY26 Q4. That’s adoption trajectory Oracle might not be able to match for another release cycle. The AELA “all you can eat” pricing model is commercially differentiated too. Forrester reports limited adoption depth in customer conversations though, and third-party hallucination rates of 3-27% have been reported on some workloads. Oracle’s transactional-system-native architecture is the technical answer here. The commercial side will take longer.

Workday Illuminate is the interesting one on governance. Their Agent System of Record plus Agent Gateway has 65+ third-party agents registered. They’re consumption-priced via Flex Credits, with around 50 customer signings disclosed. The production cases are real - GM cut candidate screening 70%, AdventHealth claimed $68M in savings. Oracle’s AI Agent Marketplace covers similar territory but doesn’t yet have a comparable governance plane but I wouldn’t be surprised if something very concrete from Oracle hits in 26C and 26D because they are certainly working on this behind the scenes.

Microsoft Agent 365 went GA on 1 May 2026 with a cross-cloud agent registry that inventories AWS Bedrock and Google Cloud agents. Oracle has nothing equivalent at the moment and that’s a real gap for multi-cloud architecture. Microsoft’s distribution moat is 20M paid Copilot seats. Their transactional depth in Dynamics 365 Finance is shallower than Oracle’s though.

For your CIO conversation: Oracle’s strengths are its transactional-system-native execution and the breadth of suites it covers in one product motion. The places it trails are - Salesforce is ahead on raw adoption projections, Workday has shipped a more formal governance plane, and Microsoft was first with the cross-cloud agent registry. Each of those is closeable inside a year if Oracle prioritises it.

What to Do Now

Concrete actions for your roadmap this quarter.

Fusion customers - pick one workspace from the most-fleshed-out group (Collectors, Cross-Sell Program, Workforce Operations, or Design-to-Source) and stand up a sandboxed pod for release 26B activation. Choose one with a clean outcome metric (DSO, candidate-to-hire time, RFQ cycle time) so you have something to put in your Agent ROI Dashboard pilot.

EBS, PeopleSoft, JDE, and Hyperion shops - negotiate the bridge to Fusion AI in 12-18 months and ask Oracle for the enterprise configuration agent in a pre-sales engagement. You’ll want to see what migration acceleration actually looks like.

In a follow-up post I’ll go inside one of these apps - the protocol that wires the app shell to its agents, the widget schemas, the communications model, and what makes Oracle’s architecture defensible. If you’re standing one of these up in your tenant, that’s the read you’ll want next.

Disclaimer: This is my best reading of Oracle’s Fusion Agentic Applications announcement based on Oracle’s public press releases dated 24 March and 9 April 2026, conversations with Oracle product development team, and independent analyst coverage published through May 2026.

That’s a mistake. Trigger design matters more than most people think when deploying Workflow Agents in production - because the trigger determines not just when your agent runs, but how well it fits into the way your organisation actually works.

The 26A release introduced three trigger types for Workflow Agents - webhook, email, and schedule - alongside native integrations for Microsoft Teams and Slack. Between them, they cover most of what you’ll need. I’m not going to walk through what triggers exist - you can find that in the docs. This is about which trigger fits which problem, and what you actually need to know to configure each one properly.

One thing to flag upfront: the agent must be in a published state for any trigger to work. Sounds obvious. It isn’t, I’ve been personally tripped by this more than once.

The Webhook Trigger: System-to-System Integration

This is what sits behind the invokeAsync REST API, and it’s where you’ll spend the most time if your organisation runs Fusion alongside other enterprise systems.

The pattern is a two-step async flow. An external application sends a POST to the invoke endpoint - passing a user prompt or structured data - and because the agent may take time to reason through that input, the call returns a job ID immediately. The calling system then polls a separate status endpoint using that job ID to retrieve the final output.

The endpoint URLs follow a consistent structure:

• Invoke: https://<pod_host>/api/fusion-ai/orchestrator/agent/v2/<workflowCode>/invokeAsync

• Status: https://<pod_host>/api/fusion-ai/orchestrator/agent/v2/<workflowCode>/status/<jobId>

Authentication is standard OAuth 2.0 bearer tokens via OCI IAM/IDCS. Nothing new if you’re already working with Fusion APIs.

The Request Body: More Than Just a Message

The invokeAsync request body supports more fields than most people realise. Beyond the obvious message field (your user prompt), there’s conversational (boolean - set to true for multi-turn exchanges), conversationId (pass back the ID from a previous response to continue a conversation), invocationMode (either END_USER or ADMIN for debug output), parameters (key-value object for webhook input variables), streamOutput and progressMessage (booleans for streaming and progress updates), and resumeNodeInput (for resuming a workflow that’s paused at a human approval step). The status field lets you target either the PUBLISHED or DRAFT version of a workflow - useful during testing.

The initial response returns immediately with status RUNNING, a jobId for polling, and a conversationId for future multi-turn exchanges. You then poll the status endpoint until the status transitions to COMPLETE or ERROR. When COMPLETE, the output field contains the agent’s final response. If the status is WAITING, that means the workflow has paused at a human approval step - your integration needs to handle that explicitly.

For development, appending ?invocationMode=ADMIN as a query parameter (or setting it in the request body) is worth knowing about. It returns the full node execution trace - traceId, start and end timestamps in both epoch and ISO format, input and output token counts, node-level execution details, and timeTaken in milliseconds. That saves you a lot of debugging time compared to guessing from the output alone.

Setting Up External Access: The IAM Configuration

If you’re calling invokeAsync from outside the Fusion ecosystem, there’s a multi-step IAM setup that needs to happen first. The Oracle documentation outlines five steps: create a confidential application in Fusion IAM that represents the external app, enable access to the AI Agent Studio service for invokeAsync, create a matching confidential application in the external app’s own IAM, register the external app in the AI Agent Studio Credentials tab (base URL, IDCS URL, scope, public/private keys), and then create business objects from the registered data source if needed. It’s not complex, but it’s sequential - and skipping a step means silent failures rather than helpful error messages.

Two profile options also need to be set at site level before any of this works: ORA_ASE_SAS_INTEGRATION_ENABLED must be set to Yes, and ORA_HCM_VBCS_PWA_ENABLED must be set to Y for end user access. These are the kind of prerequisites that don’t surface in any error message - you just get a blank response or a 403.

Parameterised Webhooks

This is the more powerful pattern. When configuring a webhook trigger, you define named input variables - with explicit types like string or number - that get passed into the REST call as part of the parameters object. Those values are then available within the workflow as trigger variables, accessible through the context picker under Input > Variables.

So in practice: a single published workflow can handle multiple variations of a process, with the calling system supplying the context that shapes how the agent behaves. Instead of building separate workflows for every scenario, you parameterise the inputs and let the workflow adapt.

If your integration platform, middleware, or an application like EPM or a third-party system needs to invoke a Fusion agent without any human initiating the conversation - webhook is the right choice. And with the Data Source Applications capability in 26A, those agents can now reach back out to non-Fusion systems too, using OAuth connections configured under Credentials. The integration story is becoming properly bidirectional.

Multi-Turn Conversations via the API

The conversationId field is what makes multi-turn integrations work. After the first invokeAsync call, the response includes a conversationId. Pass that back in the next request with conversational set to true, and the agent retains the full conversation history - meaning it can reason about what’s already been discussed rather than treating each call as a cold start. For integration scenarios where an external system needs a back-and-forth exchange with a Fusion agent (rather than a single fire-and-forget), this is what makes that possible. When session management is enabled, the session persists for interactive conversation with short-term memory that condenses chat history to reduce latency and token usage.

The External REST Tool: Reaching Beyond Fusion

Before getting to the other trigger types, I want to cover the External REST tool - because it’s the primary mechanism for connecting workflows to non-Fusion systems, and it comes up in almost every integration design I’ve seen.

The configuration follows a consistent pattern: you set a base API URL, choose an authorization type (API Key or OAuth), then define individual functions - each with an HTTP method, resource path, parameters, headers, and body. POST with JSON body is the most common pattern for create/update operations: leave requests, job requisitions, benefit enrolments, record updates in external systems.

The clever bit is slottable parameters. You define placeholder fields in headers, query parameters, and body content - and at runtime, the LLM learns to generate the correct values based on context. The key to making this work well is providing good example parameters at design time. The agent uses those examples to understand what kind of data each field expects, and Oracle gives you the ability to test individual functions during design - before the workflow is published - with sample parameters to verify the integration works.

If you’re coming from traditional Fusion integration work, this is a big change. Instead of building middleware or writing custom adapters, you’re configuring REST connections directly within the agent studio and letting the LLM handle the dynamic parts. It’s not a replacement for OIC in complex integration scenarios, but for point-to-point API calls within a workflow, it’s a lot quicker to set up.

The Email Trigger: Document Ingestion That Actually Works

The email trigger doesn’t get as much attention as the REST API. It should.

Setup is simple. Configure a Google or Microsoft email account under Credentials > Email Accounts with the account type set to Inbound. From that point on, any new email arriving in that inbox automatically kicks off the workflow. No polling job, no middleware.

What makes it useful is what context it gives you. The email body, sender address, subject line, headers, and processed attachment text are all available as context variables:

• $context.$triggers.EMAIL.$input.content - email body

• $context.$triggers.EMAIL.$input.fromAddress - sender

• $context.$triggers.EMAIL.$input.attachments[0].context - extracted text from attachments

That combination makes document ingestion workflows easy to wire up.

What Document Ingestion Actually Looks Like

The partner training materials had use cases that give you a sense of how far this can go:

• P.O. to Sales Order: Customer purchase order arrives as a PDF attachment. The workflow ingests the document, classifies it as an order, extracts customer details, products, pricing, and terms, runs a catalogue and pricing check with exceptions flagged for human review, then creates and fulfils the sales order in Order Management.

• Supplier Quote to Purchase Requisition: Same pattern, different extraction - supplier details, items, quantities, UOMs, currency and amounts. Confirm the supplier and line count, then create the requisition in Procurement.

• Court Order to Payroll Garnishment: A court order received via secure email triggers a workflow that identifies the employee, case number, and amounts, checks HR and payroll records for exceptions, then applies the deduction and updates payroll.

• FDA Recall to Inventory Quarantine: An FDA recall notice triggers identification of affected item codes, lot numbers, and facilities, matches against current inventory, then quarantines items and blocks distribution.

These are exactly the kind of processes where someone had to touch every step manually.

Two practical constraints to know upfront. First: each workflow can monitor only one unique inbound email account. You can’t have a single workflow listening to multiple mailboxes. Second: you cannot reuse the same inbound email account across multiple workflows. One inbox, one workflow - that’s the model. This means dedicated, purpose-specific inboxes rather than a shared mailbox with filtering logic.

It’s also worth configuring error notification destinations early. You can specify error destination emails with context expressions - meaning if the workflow fails, the right person gets notified with the relevant context automatically rather than the failure disappearing silently.

To verify your email trigger is working, go to the Monitoring and Evaluation tab, open the Activities subtab, and check Inbound Emails. You’ll see the trigger email contents and can verify whether the workflow was actually initiated. Same approach works for schedule triggers - the Schedules view under Activities shows whether your scheduled runs are firing.

File Upload via Chat: UCM and the 26B Simplification

Not every document processing scenario starts from an email. Sometimes it starts from a user uploading a file during a conversation.

In 26A, you added the MultiFileProcessor tool to an agent. Users could upload up to five files at a time, combined size limit of 50 MB, across formats including PDF, XLSX, DOCX, PPTX, CSV, JSON, XML, and images. Third-party cloud storage uploads from Google Drive, Dropbox, or OneDrive were also supported.

In 26B, the mechanism was simplified. Instead of the MultiFileProcessor tool, you add a Tool node to your workflow and select “Chat Attachments Reader” as the type. Cleaner approach - the file reading becomes a node in the workflow rather than a tool attached to an agent.

For UCM-based document processing - where the file is already an attachment on a Fusion business object - the Document Processor node handles retrieval. You configure the metadata (family, product, business object fields) and the function used for retrieval (such as get_document_for_processing). The node retrieves the file from UCM and sends it to the document-processing backend for text extraction.

The Schedule Trigger: Governance on Autopilot

The schedule trigger is the quietest of the three, and probably the most useful for keeping things running properly on an ongoing basis.

It supports two patterns:

• Interval scheduling fires on a repeating, time-based cadence - seconds, minutes, hours, or days from a defined anchor point. Good for continuous monitoring: checking headcount exceptions every four hours, or monitoring approval queue ages and escalating anything past a threshold.

• Recurrence scheduling works on calendar-based patterns, either one-off or repeating. Good for structured operational rhythms: weekly payroll reconciliation, monthly compliance attestation reminders, quarterly audit preparation.

You can combine both trigger types on the same agent to suit different automation needs simultaneously.

Multi-Step Use Cases Across Fusion Pillars

The training materials had detailed scenarios showing how schedule triggers connect to broader workflow patterns:

• HCM - Leave/Accommodation: Evaluates eligibility against dates and policy constraints, determines required docs and routing path, routes to HR/Legal/Benefits, handles approvals and exception reviews, creates the leave case, updates time and payroll, notifies stakeholders.

• SCM - Supply Disruption Recovery: Fires on a late/shortage/quality alert, identifies impacted orders, assesses inventory constraints, determines best recovery option (cost vs SLA), reallocates and reroutes, updates ATP allocations, publishes a summary.

• ERP - Dispute > Credit/Rebill: Customer dispute raised, evidence gathered from orders/shipments/terms, credit vs rebill vs deny decision, proof assembled and comms drafted, credit threshold approval, then issue credit/rebill, update AR, notify customer, close.

• CX - Case-to-Resolution: New case from any channel, intent and severity classified, next-best fix and escalation criteria determined, troubleshoot steps executed, high-risk/VIP approvals, case updated, customer summary sent, closed with audit trail.

One configuration detail that’s easy to overlook: the user who creates a scheduled workflow must be assigned the FAI Batch Job Manager Duty role (ORA_DR_FAI_BATCH_JOB_MANAGER_DUTY). This isn’t obvious from the UI and it will block your scheduling job from being created. Raise it with your security team early - before you get to testing.

Teams and Slack: Meeting Users Where They Already Are

For a lot of organisations, the biggest deal in 26A isn’t a trigger in the technical sense - it’s the native channel integrations for Microsoft Teams and Slack.

These move agent interaction out of the embedded Fusion chat widget (which requires users to be in Fusion) and into the collaboration tools they’re already in all day. If user adoption of AI capabilities has been slow in your organisation, this is often the difference between something people actually use and something they forget about.

Teams Setup: Step by Step

The Teams configuration is more involved than most trigger setups, so it’s worth laying out the steps. You start by creating an Azure Bot via Azure Portal (Create Resource > Azure Bot, selecting Single Tenant as the creation type and “Create new Microsoft App ID”). Then in AI Agent Studio, navigate to Credentials > Channels > Microsoft Teams and configure the channel with the bot details. AI Agent Studio generates a manifest ZIP file, which you download and upload to the Teams Admin Center (admin.teams.microsoft.com) under Teams apps > Manage apps > Upload new app. Finally, enable the app organisation-wide via Teams apps > Setup policies > Global.

One gotcha: if you modify the channel configuration in AI Agent Studio after initial setup, you need to regenerate and re-upload the manifest ZIP to Teams. The old manifest won’t reflect the changes.

Slack Setup

Slack follows a similar manifest-driven approach. Navigate to Credentials > Channels > Slack, generate a manifest from AI Agent Studio, then go to api.slack.com/apps and create a new app “From a manifest.” Choose your workspace, paste in the manifest JSON, and complete the setup. Extract the Bot User OAuth Token from the app configuration, then return to AI Agent Studio and enter that token in the Slack channel configuration. In Slack itself, add the app to your workspace.

Security: The Channel Permissions

A new duty role in 26A groups all channel-related permissions for both Teams and Slack. The permissions are granular: create, read, update, and delete for both ChannelManifest and ExternalChatCorrelation. That’s eight individual permissions. Any user configuring channel integrations or interacting with agents through these channels needs this role assigned. Factor it into your security review ahead of go-live, not during UAT.

Embedded Workflows: Composability Through Reuse

This is a capability that sits alongside trigger design and I think will become increasingly central to how people build.

The Workflow node and Agent node allow a running workflow to call other published workflows or reusable agents as part of its execution. The Workflow node calls a published workflow or agent team; the Agent node calls a reusable agent. Think of them as building blocks for composable automation.

The training materials showed a customer support bot whose main workflow handles the initial query, and when escalation is needed, a Workflow node calls a separate Ticket Creation workflow. That child workflow logs the issue, returns a ticket ID to the parent. Variables and messages can be passed through - these appear as input variables if the called workflow has a webhook trigger with defined variables.

Important constraint: workflows containing human-approval nodes or wait nodes cannot currently be called as embedded workflows. The wait node restriction is noted as being addressed in 26B, but the human-approval constraint remains. Makes sense architecturally - an embedded workflow that blocks waiting for a human would create unpredictable timing for the parent - but it’s something to design around early.

Output of the embedded workflow is accessible via $context.$nodes.<NODE_CODE>.$output.output, which means you can capture results and route subsequent logic accordingly.

The A2A Protocol: Looking Beyond Fusion

Beyond the invokeAsync API, the Connecting the Ecosystem training session introduced the A2A (Agent-to-Agent) protocol - a standardised REST interface for agent discovery and communication. The flow is discover-then-interact: search for available agents, retrieve an agent’s metadata and capabilities via its agent card, send a message to initiate a task, poll for results.

The interesting part is that Fusion agents aren’t just being called by external systems here - they’re discoverable by other agents. If you’re running a multi-platform environment, this is where agents actually start talking to each other across platforms.

Alongside A2A, 26A also introduced MCP client support - allowing agents to connect to MCP-compliant external servers using a standardised bidirectional protocol. Where the External REST tool requires you to configure each API endpoint manually, MCP lets the agent discover available tools from an external server automatically. It’s early days, but the direction is clear: agents that can find and use capabilities they weren’t explicitly configured for.

Where Users Actually Find Your Agents

One aspect of trigger and channel design that doesn’t get enough attention is how end users discover and access published agents. Beyond the Fusion chat widget and the Teams/Slack integrations, there are several embedding paths worth knowing about:

Deployment Path Best For Context-Aware Setup Effort Agent Explorer Users discovering all available agents No Zero - it’s built in Guided Journeys Step-by-step tasks embedded in Redwood pages Partial Two-step config VB Studio / Smart Actions Module-specific contextual AI Yes - auto-detects page context Developer-level Triggers Automated background processing N/A AI Studio config External Access (invokeAsync) Agents called from external apps N/A OCI IAM token setup

Agent Explorer is the simplest path - it’s essentially a personal AI app store inside Fusion. Users navigate to Me > Show More > AI Agent Studio, or hit the direct URL (/fscmUI/redwood/human-resources/ai-studio/agent-explore). It has two tabs: “Needs Attention” for ongoing conversations and history, and “Explore” for searching all published agents. End users only see agents where the security configuration matches their role.

Smart Actions via VB Studio offer the deepest integration. The agent is context-sensitive - it can automatically detect and pull data from the page the user is currently viewing. No manual input required. But availability is limited - it’s not universal across all modules. Check product-specific documentation before planning around it.

Guided Journeys got a useful enhancement in 26B: you can now trigger a workflow agent on journey task completion or task save, which opens up scenarios where completing a guided step automatically kicks off background processing.

The AI Agent Marketplace (26B) is the new addition to keep an eye on. It’s embedded natively within Fusion - users can discover, test, and deploy third-party agents directly. For partners, this is the distribution channel.

Where you deploy the agent matters because it changes whether people actually find and use it. An agent embedded via Smart Actions in the right Redwood page at the right moment will get used. The same agent, only accessible through the standalone chat widget, probably won’t.

What to Make of All This

Trigger design doesn’t get enough attention, and it should - because the trigger basically defines how the whole integration works:

• Webhook-triggered workflows are designed for system-to-system communication. They need to be solid, parameterisable, and optimised for reliability.

• Email-triggered workflows are designed around document ingestion. Their success depends on how well the extraction handles real-world content.

• Schedule-triggered workflows are designed for periodic governance. Their value depends on running reliably at the right cadence.

If you think about this upfront, the architecture stays clean. If you don’t, you’re reworking integration logic after the fact.

These trigger types don’t need to be used in isolation either. A common pattern is a schedule-triggered workflow that runs a periodic check, with a Workflow node inside it that calls a webhook-triggered agent to handle exception processing. The layering gives each component a clean responsibility - and with embedded workflows, those components become properly reusable across different contexts.

Security Roles: The Full Picture

Since triggers, channels, and external access all have role requirements, here they are in one place. The admin roles are pillar-specific:

• HCM: ORA_DR_FAI_GENERATIVE_AI_AGENT_HCM_ADMINISTRATOR_DUTY

• SCM: ORA_DR_FAI_GENERATIVE_AI_AGENT_SCM_ADMINISTRATOR_DUTY

• ERP/FIN: ORA_DR_FAI_GENERATIVE_AI_AGENT_FIN_ADMINISTRATOR_DUTY

• PRC: ORA_DR_FAI_GENERATIVE_AI_AGENT_PRC_ADMINISTRATOR_DUTY

• CX: ORA_DR_FAI_GENERATIVE_AI_AGENT_CX_ADMINISTRATOR_DUTY

End users need ORA_DR_FAI_GENERATIVE_AI_AGENT_RUNTIME_DUTY (with the HRC_ACCESS_AI_AGENT_CHAT_PRIV privilege) to interact with agents through Explorer or chat. For the External REST tool, you need ORA_FND_TRAP_PRIV (Create and Edit Backends for Visual Builder Studio). And as mentioned above, scheduled workflows require ORA_DR_FAI_BATCH_JOB_MANAGER_DUTY.

A user only sees an agent in Agent Explorer if the security assigned to that agent matches their access criteria and the agent has been published. This is by design - but it means your security review needs to happen before your UAT, not during it.

Disclaimer: The views here are my own and draw on Oracle's partner training sessions and publicly available documentation. All screenshots in this article are from Oracle's AI Agent Studio Partner Training (March 2026) and remain the property of Oracle Corporation. Oracle's guidance evolves - always verify with official docs and test in your own environment before making production decision