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