Oracle’s been moving quickly with its agentic finance capabilities, and the Payables Agent is one of the more practical outcomes so far. If you’re looking after accounts payable or running a shared services function, it’s worth taking a closer look at what it can do and what’s involved in getting up and running.
The Payables Agent is focused on the day-to-day reality of accounts payable, helping with invoice intake, compliance and control. It works to take invoices from wherever they come in and move them through to payment-ready with as little manual handling as possible. It sits alongside a wider set of Oracle AI agents across Payments, Expenses, Ledger and Customer Payments, each one aimed at a specific finance outcome.
At the heart of it is Document IO, which handles invoice ingestion across different channels and formats. It routes everything through a consistent process and flags anything that needs a closer look, so exceptions can be picked up and dealt with quickly.
Document IO works a bit differently to traditional approaches. It reads the whole invoice rather than picking out individual fields, then extracts and maps the information straight into the right attributes in Oracle Fusion. It can handle different formats, multi-page documents and multiple languages without needing templates set up for each supplier, and you don’t have to change how invoices are sent in, as your existing email channels can stay as they are.
The Streams UI gives you a single place to keep on top of everything, bringing together all your active invoice streams. You can quickly see what’s coming in, what’s already been processed, and what needs attention. Out of the box, there are two streams available. The first covers invoice image documents, handling supplier invoices sent by email in different formats, across multiple pages and languages. The second is partner e-invoice integration, which connects to e-invoices via Thomson Reuters. That one does require a commercial agreement with Thomson Reuters to get started.
Converged streams bring your existing channels into the same view as well, including bulk uploads and manual entry. It means you get a single, consistent way of seeing and managing every invoice type in one place.
For suppliers with a consistent invoice layout and high volumes, document training makes things even smoother. You set the format up once, the system extracts the data using GenAI, you check and save it, and that format is then recognised going forward. After that, every invoice in the same layout is processed automatically, without the need to retrain.
All of that is handled automatically in the background, with policy-driven validation, anomaly detection, PO matching, approval routing and budget checks applied to every invoice. A full audit trail is maintained throughout. Anything that needs attention is surfaced in the Invoice List UI, giving you a single place to manage invoices, handle exceptions and respond to queries. It means your team can focus their time where it really matters, rather than working through everything manually.
So, how do you get started? The Document IO Agent is already switched on by default, so there’s nothing you need to enable. From there, it’s really about setting up three key areas: where your invoices are received, how your streams are connected into the Streams UI, and, for higher-volume suppliers, putting a bit of time into training the system to recognise their invoice formats.
The best way to approach it is to take things in stages. Start with getting your invoice ingestion set up, then bring in converged streams and training, and finally test and refine at scale across different formats and volumes.
Stepping back, this is really about making day-to-day accounts payable that bit easier. A lot of the routine work is taken care of in the background, so your team can spend more time on the things that genuinely need their input. If you’re already using Oracle Fusion, it’s definitely worth exploring what this could look like in your own environment and where it might take the pressure off your team.
Please note all screenshots are the property of Oracle and are used according to their Copyright Guidelines
Over the bank holiday weekend, with the heat driving me indoors, I opened up my Fusion demo environment and decided to try building my first Oracle Agentic Application. Within a few minutes, it was up and running. That is not marketing spin, it is genuinely how quick and straightforward the experience was. It also gave me a good reason to sit down and share what I found.
Officially, the Agentic Application Builder does not arrive until Release 26C. However, if you are already familiar with AI Agent Studio and have access to a non production pod, there is more than enough available today to start building something meaningful and to get a feel for where this is going. Over the weekend, I put together two applications. The first used one of Oracle’s out of the box prompts, and the second was based on a custom prompt I created with support from Microsoft Copilot. Both came together quickly, which is really the point.
Before getting into what I built, it is worth being clear on how this fits together architecturally. AI Agent Studio, which is included within your Fusion Applications subscription, will introduce the Agentic Application Builder in Release 26C. It provides a low code way to create and extend agentic applications directly within Fusion. What makes it different is the starting point. Rather than beginning with code or a process diagram, you simply describe the business outcome you want to achieve, and the builder identifies the right agents, creates the initial structure, and connects to your enterprise data. It is also important to understand the licensing model. While you can explore, test, and build in non production environments without any additional cost, a separate licence is required to deploy and run these agentic applications in production. This means there is nothing to stop you getting hands on now and understanding the art of the possible before making any investment decisions.
Applications built in this way run natively within Fusion Applications, using your existing business objects and data, and operating under Fusion’s role based security. That is worth pausing on, because it means you are not creating something separate or bolting on additional functionality. These agents are working within the same security and access model your users already rely on in their day to day roles.
The builder brings applications together using reusable agent teams. These can be provided by Oracle, developed by partners, or created in house to suit your own needs. Each team is designed to handle a specific role, and the builder assembles them into a single application that works towards a common business outcome.
For my first build, I started with one of Oracle’s out of the box example applications. From selecting the template to having a working framework in front of me took only a few minutes. The App Builder presents a range of example agentic applications from the outset, giving you something tangible to work from straight away. You can select one, use it as a foundation, adapt it to your needs, and build from there. In my case, I chose the Talent Review and Insights application.
The steps are: go to AI Agent Studio, open the Apps tab, select Add, enter the name, code, and description for your agentic app, and navigate to the App Builder. Select one of the example apps and you’re looking at a working framework almost immediately.
That speed was the first thing that stood out to me. The framework clearly sets out the agent teams involved, the different sections of the application, and how everything fits together. You are not faced with a blank canvas. Instead, you can immediately see which published workflow agent teams are available to include, and the structure gives you a clear sense of how the application will operate before you have made any changes.
What really caught my attention was the quality of the insights it produced. This is not a static report. The agents actively draw on the data in your environment and present findings in a way that is designed to prompt action, not just provide information. For an HR practitioner used to working with standard Talent Review dashboards, the difference in how those insights are surfaced is immediately noticeable.
The second build is the one I found most interesting, and it was just as quick to put together. I used Microsoft Copilot to help shape a detailed natural language prompt, then passed that into the App Builder through the Ask Oracle interface to generate a completely custom agentic application from scratch.
The prompt set out an application designed for Payroll Administrators, bringing everything into a single workspace to monitor payroll activity and improve processing accuracy. The aim was to give payroll teams a clear, action focused view of exceptions, anomalies, and key changes that need investigation before payroll is finalised. In practice, that means removing the need for administrators to piece together that picture across multiple pages and reports.
The App Builder works through three clear phases: intent, assembly, and refinement. You start by describing the business objective in plain language, the builder then suggests the most relevant agents and proposes an initial structure, and from there you refine the application through layout changes, naming, and added detail before publishing. The whole journey, from a simple prompt to a structured application framework, moves quickly. If anything takes time, it is shaping the prompt itself rather than waiting for the builder to respond.
What I found is that the quality of the prompt makes a real difference to what the builder produces. The prompt I created with Copilot was clear about the user persona, the business context, and the type of information needed, focusing on a Payroll Administrator working in a pre finalisation scenario and looking for exceptions, anomalies, and priority changes. The application that came back reflected that level of clarity. In many ways, it is no different to working with any AI tool. The prompt is the critical part. The clearer and more specific you are, the more useful and relevant the outcome will be.
For those looking to get familiar with the structure ahead of 26C, an agentic application is built from three core elements: agent teams, communications, and actions. Agent teams sit at the heart of it. Only published workflow agent teams that have been enabled for use in applications are available to select, which helps ensure consistency and control over how these applications are put together.
Communications allow the application to send emails and messages using predefined templates. These templates can take the form of PowerPoint, PDF, email, or simple text. For email templates, the agent can be given the ability to suggest recipients, generate a subject line, and complete sections of the content. For PDF and PowerPoint templates, the agent can generate titles and populate the content, helping to streamline how information is produced and shared.
Actions define what happens as the application runs, including where human approval is needed along the way. The flow itself is straightforward. A widget or user interface element triggers a command, that command determines which action to run, and the action then executes its steps in sequence. There is a good level of flexibility in how those steps are defined. You can keep an action visible in the interface after it has run, navigate users to another application, send a command to an agent, refresh what the agent is showing, or switch the application context. Taken together, these steps allow you to shape how the application behaves and how users interact with it.
Once built and tested, you publish the app. Users can then access it from the AI Agents page, reached via Me > Quick Actions > Show More > AI Agent Studio > AI Agents.
I realise I am starting to sound a bit like an Oracle advert, so it is worth being honest about the experience. In its current pre release state, not everything behaves as you would expect from a finished product. Some agent team options are not yet fully populated, and there are limits to how far you can test the end to end flow in a sandbox without complete data. That is to be expected at this stage.
What is clear, though, is the direction of travel. The App Builder is designed to enable functional consultants and technically minded administrators to create agent driven applications without writing code, and to do so quickly. Starting with natural language removes much of the usual barrier, building from reusable agent teams means you are not starting from scratch each time, and the inclusion of example templates means you can have something up and running in the time it takes to make a coffee. For organisations investing in the Fusion Agentic Apps Platform, this is where a great deal of tailored capability is likely to be developed over the coming releases.
If you have access to a non prod pod and want to get ahead of 26C, it is well worth spending some time in AI Agent Studio now. The core concepts you will be working with, including agent teams, sections, communications, and actions, are already in place and align with what will be available in the full release.
I will share a more detailed walkthrough once 26C is live and the full feature set is available. In the meantime, if you are interested in where this is heading, it is worth taking a look at my earlier write up on AI Agent Studio and what it means for Oracle Fusion HCM.
Please note all screenshots are the property of Oracle and are used according to their Copyright Guidelines
With Release 26B, the Oracle Expenses Agent is now generally available to all customers. There are no promo codes or pilot requirements to worry about. If you are using Oracle Fusion Cloud Expenses, you can start using it straight away. The Expenses Agent is part of a much broader set of Oracle-built agents embedded across Fusion Applications, alongside Oracle AI Agent Studio for building your own agents, AI Workflows, and an AI Agent Marketplace for partner solutions. It is included as part of your existing Fusion Cloud Expenses licence and is updated by Oracle each quarter, so you continue to benefit from ongoing enhancements without additional effort.
Across the Financials suite, Oracle has introduced a range of agents covering Payables, Expenses, Accounting Operations, Payments and Cash Processing. Each is designed to streamline processes, cut down cycle times and reduce the level of manual effort required from finance teams.
At its core, the Expenses Agent is designed to deliver a touchless experience. An employee simply makes a purchase and forwards the receipt by email, and the agent takes it from there. It reads the receipt, extracts the key details, matches it to the card transaction, creates the expense line, and submits it for approval. If anything is missing, it reaches out to the employee directly. Where everything is complete and compliant with policy, it moves straight through without any manual intervention. Employees can also interact with the agent using natural language to ask questions about policies and processes, making it much easier for infrequent travellers to find the information they need without unnecessary friction.
Oracle reports a 70-80% reduction in the effort required to create and submit expenses, along with 99% accuracy when matching card transactions. Just as importantly, compliance checks happen upfront rather than after submission. In a traditional process, approvers often have to send non-compliant claims back for correction. With the agent, expenses are checked before they reach the approver, helping to avoid rework and keep the process moving smoothly.
I have seen the Expenses Agent in action first hand, and it really brings the experience to life. Recently, I was out for lunch with an Oracle colleague who showed me how they submitted the expense. They simply took a photo of the receipt and, by the time we had walked up the escalator, the expense had already been checked against company policy and confirmed as compliant. It was then automatically matched to the corporate card transaction. It is a small moment, but it shows just how quick and effortless the process can be in practice.
The 26B release broadens support across all corporate cards and personal expense types, building on earlier versions that were limited to J.P. Morgan Chase corporate cards. It also introduces a number of enhancements, including email-based expense completion, the ability to query policies through Oracle AI Agent Studio, automatic receipt itemisation, mobile attachment of pre-approved spend authorisations, and more detailed location information within the Expenses page.
One point to be aware of is that the Expenses Agent uses a non‑premium large language model by default, so there is no additional cost to use it. If you find that performance does not fully meet your requirements, you do have the option to switch to a premium model. This can enhance capability, but it does come with a cost based on token usage.
Oracle recommends a structured, four-stage approach to adoption. It starts with laying the right foundations by simplifying expense types, refining policies and encouraging the use of corporate cards, as cleaner and more consistent data improves automation accuracy. From there, organisations can move to a phased rollout by business unit, typically starting with a pilot group before expanding more widely, supported by auto‑provisioning of the ERP Self Service role. The next step is to focus on employee experience and adoption, ensuring users are comfortable with receipt forwarding and interacting with the agent in natural language. Finally, it is about embedding operational best practices, such as enabling auto‑submission and using line-level attachments to support a smooth, efficient process.
There are a few practical points to be aware of before going live. If Touchless Expenses is not visible on the configuration page, you will need to opt into the relevant FSM feature before enabling it at business unit level. If you encounter a blank page after configuration, or the interface falls back to the classic landing page, it is worth reapplying any custom theme, checking the root menu configuration for stray spaces, and running the Retrieve Latest LDAP Changes and Import User and Role Application Security Data processes. If emailed receipts are not being processed, make sure the Create Expenses from Email Receipts process is scheduled to run at regular intervals, as it does not trigger automatically.
Looking ahead, the 26C release will introduce further enhancements, including support for Cost Allocations and Additional Information such as monthly and yearly limits, along with Cash Advance Applications and email-based completion for Classic Expenses customers who have not yet moved to Touchless. Beyond that, Oracle has outlined plans for a new Redwood Expenses page for employees and delegates, an Audit Workspace Agentic application, and expanded agent capabilities covering Cash Advance Requests, Mileage, Per Diem and more advanced attendee requirements.
If you have not yet looked at the Expenses Agent, it is worth starting with the basics. Taking time to simplify policies and increase corporate card adoption will deliver immediate improvements to your current process, while also setting you up to get the most value from the agent when you choose to enable it. If you would like to understand what this could look like in your organisation, now is a good time to start the conversation and explore how to get value from it early.
Please note all screenshots are the property of Oracle and are used according to their Copyright Guidelines
Oracle has been making a clear and increasingly consistent argument over the past few months: enterprise software has reached the limits of what a system of record can do. I’ve written before about the introduction of Agentic Applications at AI World London, and about the specific HCM applications that were announced alongside them. But there’s a broader story here that I haven’t fully explored yet, and it’s one that I think matters for every Fusion customer, not just those focused on HCM.
This post draws on the “Reinventing How Work Works” webinar, which stepped back from individual applications and made the architectural and commercial case for why the shift to agentic is happening, what it actually looks like in practice, and where Oracle is taking this next. If you’re trying to build internal momentum for agentic adoption, or if you’re trying to explain to a leadership team why this is different from previous AI announcements, this is the post to share.
The framing that Oracle used throughout this webinar is, I think, one of the clearest explanations of what has actually changed. Traditional enterprise systems, including Fusion as it has historically operated, are systems of record. They follow fixed rules, capture what happened, retrieve information when asked, and complete transactions. They document the business. What they don’t do is run the business.
Agentic Applications represent a move to what Oracle calls systems of outcomes. Rather than waiting for a person to interpret data and decide what to do next, a system of outcomes works toward objectives, makes things happen, solves problems, and achieves results. The underlying system of record doesn’t go away. The data, governance, approval hierarchies, role-based access control, and audit history are still there, and in Oracle’s case, they’re still the source of truth for every transaction. What changes is the layer operating on top of that foundation.
This architecture diagram is worth studying if you haven’t seen it. Agentic Applications sit in a new composable layer above the existing ERP, HCM, and CX transactional applications. That layer is powered by teams of AI agents coordinated through Oracle AI Agent Studio, drawing on the full enterprise data model, security model, and process history that already exists in Fusion. Beneath all of this, Oracle Cloud Infrastructure (OCI) provides the AI data platform, and a range of large language models (LLMs), including those from OpenAI, Cohere, Meta, Anthropic, xAI, and Google, are available depending on the task and preference.
Every Fusion Agentic Application is built around four core dynamic areas. Understanding these is useful when you’re evaluating a specific application or explaining the concept to stakeholders.
The first is the Advisor, which is the “Ask Oracle” conversational interface. This is where a user can ask natural language questions and get contextual, data-aware responses rather than navigating to a report. The second is the Information Summary, which provides an intelligent, prioritised view of what’s happening right now in that area of the business, surfaced automatically rather than requiring the user to run queries. The third is Priority Actions, a curated queue of recommended next steps that the agents have identified based on current conditions, risk signals, and business objectives. The fourth is Communications, which handles notifications, responses, and outbound actions within the appropriate governance boundaries.
These four areas appear consistently across all 22 applications, which is deliberate. Oracle’s position is that once a user understands the structure in one application, they can navigate any other agentic application without relearning the interface.
One of the most practically useful concepts introduced in this webinar is what Oracle calls the Autonomy Dial. It’s a spectrum with three positions, and it addresses one of the most common concerns I hear from customers and consultants: how much control do we give up?
At the “Human in the Loop” end, the agent assists and a person decides. The agent drafts, recommends, and prepares; the human reviews and approves. This builds trust, improves speed and consistency, and keeps people firmly in control. The business impact is described as immediate productivity gains.
In the middle is “Human in the Lead”, where the agent executes and a person monitors. The agent handles routine work and manages to policy; a person steps in for genuine exceptions. This scales output without adding headcount and frees teams for higher-value work. The impact here is scaled operations.
At the “Autonomous Execution” end, the agent drives and a person owns. End-to-end execution happens within policy, continuous real-time optimisation takes place, and human involvement is reserved for true exceptions. The impact is described as business transformation.
What I find compelling about this model is that it isn’t prescriptive. Oracle isn’t saying every organisation should start at one end or aim for the other. Each position on the dial represents a valid operating model depending on the process, the risk tolerance, and the maturity of the organisation. A payroll close process might comfortably sit at Human in the Lead. A workforce scheduling decision for a critical shift might warrant Human in the Loop until confidence is established. A high-volume procurement matching task might be a good candidate for Autonomous Execution relatively quickly.
My earlier posts covered the eight HCM applications in detail. The full announcement of 22 applications in releases 26B / 26C spans ERP/SCM, HCM, and CX, and it’s worth understanding the breadth of this, because it signals how Oracle is positioning agentic across the entire Fusion suite rather than as an HCM-specific capability.
On the ERP and SCM side, the applications include Design-to-Source Workspace, Product Readiness Workspace, Production Shift Operations Workspace, Sales Order Command Centre, Batch Process Manufacturing Workspace, Logistics Execution Command Centre, Maintenance Operations Workspace, Warehouse Operations Workspace, Cost Accounting Close Workspace, Sourcing Command Centre, Collectors Workspace, and Security Command Centre.
The Design-to-Source Workspace is a useful example of the transformation logic. Previously, product design and bill of materials work happened in separate systems. Sourcing relied on items entered manually. Negotiation delays accumulated when information was missing or unresolved. With the agentic application, product specifications translate automatically into qualified supplier lists, bills of materials are generated directly from CAD files, at-risk negotiations are flagged automatically, and bids are evaluated across cost, lead time, quality, and risk in a single view. The outcome is faster time to market and improved sourcing cycle times.
On the CX side, three applications have been announced: Cross-Sell Program Workspace, Contract Compliance Workspace, and Sales Command Centre. For CX teams, the Sales Command Centre in particular brings together the kind of deal health monitoring, risk flagging, and next-step recommendation that previously required significant manual analysis across multiple reports.
I’ve written in detail about Oracle AI Agent Studio in previous posts, but the webinar highlighted several new capabilities that are worth calling out specifically, because some of them genuinely change what’s possible for teams building custom agentic applications.
The most significant new addition is the Agentic App Builder, which is released in 26C. This is what Oracle describes as a “no-code agentic brain”: you describe your objective in natural language, the system explains and builds the workflow, generates agents and the underlying code automatically, and allows you to diagnose and fix issues in real time. In the demo, a user types a description of a sales opportunity health and risk management app, and within moments a structured agentic application is assembled from reusable agents, with a Deal Summary Agent, a Risk Agent, a Customer Insights Agent, and a Process Agent already in place and connected. It’s a significant step forward from the existing builder experience.
Alongside this, several other capabilities have been marked as new in the current release: Workflow Orchestration, Content Intelligence, Contextual Memory, Multi-Modal support, an Agent ROI Dashboard, and enhanced Security, Auditability, and Governance controls. Contextual Memory is worth paying attention to particularly, because it allows agents to retain information across interactions, which is what enables genuinely personalised, continuous support rather than stateless responses to each individual query.
The studio now also supports full interoperability through MCP (Model Context Protocol) and A2A (Agent-to-Agent) protocols, which means agents built in Fusion can exchange context with agents or tools running outside the Fusion estate, provided the appropriate governance controls are in place.
One thing the webinar made very clear is that Oracle isn’t building this alone. The Fusion AI ecosystem now includes 73,400 certified builders, 10,000 developers actively building agents, and over 100 pre-built agent templates in the AI Agent Marketplace, which is now open to all partners for submissions. Open standard support includes native MCP integration across connectors and an agent-to-agent registry within Oracle AI Agent Studio itself.
For customers, this matters because it means the pool of available agents and expertise is growing rapidly. You don’t need to build everything from scratch, and you don’t need to rely solely on Oracle to extend the platform. The open partner submission model for the marketplace is a meaningful shift, and it’s one that will accelerate the availability of domain-specific and industry-specific agents over the coming months.
The summary that Oracle closed with is a useful way to frame internal conversations: Fusion is moving from systems of record to systems of outcomes. Agentic Applications get work done. Oracle AI Agent Studio lets you build, deploy, and scale agents specific to your organisation. OCI AI Advantage runs it all securely at scale.
What I’d encourage any Fusion customer to take from this is that the window to start is now. The pricing model has already been simplified significantly (covered in my earlier post), the tooling to build and extend has matured substantially, and the evidence base from production deployments is solid. Starting with one application in one process area, positioned at Human in the Loop on the autonomy dial, is a low-risk, high-value entry point that builds organisational confidence while delivering measurable results.
If you’re thinking about where to start or how to make the case internally, I’m happy to talk it through. In the meantime, why not check out my earlier post on the HCM-specific Agentic Applications announced at AI World London? You can find it here. And if you missed the original announcement post covering the architecture, the maturity model, and the updated pricing, that’s a useful starting point too, and you can find it here.
Please note all screenshots are the property of Oracle and are used according to their Copyright Guidelines
Today I had the opportunity to attend and present at a partner enablement event hosted by the Oracle AI Success Navigator product team, focused on how partners like Version 1 can best use Oracle’s tooling to bring genuine, measurable value to our customers. The session brought together presentations, product demos, hands-on labs, and open discussion, covering Oracle Cloud Success Navigator and Oracle Guided Learning (OGL). It was a useful day, and I wanted to share some of the key takeaways while they’re fresh.
If you haven’t come across Cloud Success Navigator yet, it’s Oracle’s digital engagement platform, provided free to Oracle Fusion Cloud customers, designed to help organisations design, implement, and accelerate their cloud and AI roadmaps. It sits at the centre of Oracle’s broader AI Factory offering, which Oracle launched as a bundled set of partner and customer services aimed at speeding up AI adoption.
At its core, Cloud Success Navigator gives customers a single place to discover new features, plan adoption, track key milestones, and access Oracle Modern Best Practice (OMBP) guidance. The sunburst visualisation is particularly useful: it surfaces relevant features based on your production profile, so your team isn’t wading through capabilities that don’t apply to your configuration. You can tag features across Now, Next, and Later columns, which gives a clean, structured view of your innovation roadmap.
A significant addition to the platform is AI Assist, which was made generally available in late 2025. AI Assist is a generative AI-enabled assistant embedded throughout Navigator. It goes beyond a standard chatbot: it provides tailored recommendations, surfaces relevant documentation, highlights release roadmap changes based on your context, and flags project milestone risks. For partners, the practical implication is that our customers now have a self-service layer of intelligent guidance that can accelerate feature discovery and planning without always needing to raise a support request or wait for a consultant touchpoint.
How should Partners be using Success Navigator? This was, for me, the most valuable part of the day. The Oracle product team was clear that Navigator is not just a tool for customers to log into independently. The expectation is that partners should be actively bringing Navigator into their delivery model, whether that’s during implementation, post go-live optimisation, or ongoing managed service.
In practice, that means a few things. During implementation, your partner should be walking you through Navigator as part of onboarding, not treating it as a nice-to-have that gets mentioned at the end of a project. Feature planning sessions are more productive when they’re anchored in Navigator’s release data and OMBP content, rather than relying on spreadsheets or static documentation that goes out of date.
Post go-live, Navigator becomes a continuous value tool. The AI Assist agents can help customer teams stay ahead of quarterly release content, plan for Redwood migration milestones, and identify AI features that fit their production profile. Partners who are actively guiding their customers through this ensure their customers are in a much stronger position than those who are leaving customers to self-serve without direction.
One thing to note: Oracle has indicated that the platform continues to evolve, with enhancements planned around streamlined account management for customers with multiple accounts and improved programme management views. It’s worth keeping an eye on the in-application release announcements for Navigator itself.
The second major focus of the day was Oracle Guided Learning (OGL), Oracle’s digital adoption platform (DAP) built natively for Oracle Cloud applications. OGL delivers in-application guidance, directly overlaid onto the Oracle Fusion interface, so users get real-time, contextual help without having to leave the system or refer to separate documentation. The core capabilities OGL brings to a customer environment are worth spelling out clearly, because I still encounter organisations that underestimate what the platform can do.
Process guides provide step-by-step walkthroughs for complex transactions, walking a user through the exact steps required to complete a task within the application. Smart tips and beacons offer contextual pop-up hints and visual cues at key points in the UI. The Help Panel gives users access to self-service guidance and documentation from within the application. In-app messaging allows administrators to send announcements, policy updates, and maintenance communications directly to users as they work, rather than relying on email campaigns that often go unread. Analytics then close the loop: OGL captures how users are engaging with content, where they’re dropping off, and which features or processes need additional guidance investment.
What’s particularly relevant for customers right now is the AI integration within OGL. The OGL 26A release introduced generative AI capabilities into the content authoring experience: content developers can use an AI assistant within the Full Editor to generate and rephrase step text for process guides, smart tips, beacons, and messages. This significantly reduces the time needed to build and maintain a library of guides, which has historically been a barrier to adoption on smaller or resource-constrained engagements.
OGL also extends beyond Oracle applications. It can be deployed across third-party applications including Salesforce, ServiceNow, Microsoft SharePoint, and others, which is useful context for customers running a mixed application estate.
A thread running through both topics today was change management, and it’s one that I think partners sometimes treat as a soft add-on rather than a structural part of delivery. The reality is that both Navigator and OGL exist precisely because technology adoption is a change management problem as much as a technical one.
Navigator gives you the roadmap visibility and planning structure to keep customers engaged with what’s coming and why it matters. OGL gives you the in-application mechanism to reinforce new behaviours, communicate changes, and support users at the moment of need. Used together, they cover a significant portion of the adoption lifecycle: from feature discovery and prioritisation, through to in-system guidance and analytics-driven optimisation.
The enablement message from Oracle today was straightforward: partners who embed these tools into their delivery model are better placed to demonstrate continuous value to customers. Customers who have a structured adoption programme, supported by Navigator and OGL, tend to see higher feature utilisation and lower support overhead than those who treat go-live as the end of the engagement.
It was a practical and well-structured day. The Oracle AI Success Navigator product team clearly has a strong vision for how the platform should be used within the partner ecosystem, and the investment Oracle has made in AI Assist and the broader AI Factory infrastructure is evident. For those of us working in Oracle Fusion Cloud implementations and managed services, the message is clear: these tools are available, they’re free as part of the Oracle subscription, and using them well is increasingly a differentiator in how we position value to our customers.
If you’re currently working on an Oracle Fusion Cloud engagement and you haven’t had a detailed look at what Cloud Success Navigator and OGL can offer, now is a good time to start that conversation.
Please note all screenshots are the property of Oracle and are used according to their Copyright Guidelines
Oracle has rebranded Oracle Cloud Success Navigator as Oracle AI Success Navigator, and while a name change might sound like a cosmetic exercise, what’s happening underneath is far more interesting. Oracle is actively strengthening the partnership between AI Success Navigator and Oracle Guided Learning (OGL), and for those of us who have long championed both products, this new direction is very exciting!
Oracle AI Success Navigator (formerly Oracle Cloud Success Navigator, or CSN) is Oracle’s platform for helping customers plan, implement, and continuously innovate with Oracle Cloud Applications. It’s included as part of your Oracle Cloud subscription, so if you’re not using it, you’re missing a trick to get more from your Fusion instance.
The AI Success Navigator platform gives you four key areas to work with: Latest Feature Innovation, a consolidated view of release readiness materials across your product pillars; Adoption Roadmaps, a personalised and prioritised feature backlog managed directly in the platform; Adoption Centres, theme-based content hubs covering topics like AI and Redwood; and AI Assist, an OCI Generative AI-powered chat interface that I’ll come back to in some detail.
AI Success Navigator, OGL, and MyLearn are all interconnected and Oracle’s Customer Success Services sits in the middle of each. AI Success Navigator is the planning and intelligence layer and OGL is the point-of-need delivery mechanism inside the application. During implementation, OGL is primarily the concern of the project team and partner. Post-go-live, it becomes relevant to all users. MyLearn is the key mechanism for users to learn about Oracle Fusion and therefore is an important consideration.
What’s changing is that these products are no longer operating in isolation. OGL content is now surfaced within AI Success Navigator in the Oracle Modern Best Practice (OMBP) area as job aids, and within Starter Configuration. AI Assist is also being increasingly trained on OGL best practices and project success indicators, meaning the recommendations it produces are grounded in what good OGL adoption actually looks like.
Are you aware of the opportunity to use Success Navigator’s AI Assist to help produce OGL Content? On a recent webinar the presenter asked AI Assist to produce a prioritised list of Recruiting 26B features ranked by end-user impact, with a recommendation on which should have an OGL strategy assigned. The output was a ranked list classifying features as high, medium, or low impact, with a clear rationale for each. Features like Career Coach Enhancements (Interview Management Agents) and the Redwood Experience changes to candidate data management were flagged as high impact, with specific reasoning around setup requirements and workflow changes for end users.
The next step was even more useful. Having identified that the Interview Management Agent feature needed OGL coverage, the presenter asked AI Assist to produce a sample OGL flow. The output was a structured, step-by-step guide covering navigation path, UI element locations, and accessibility notes. When the presenter asked for it in an Excel-ready format, AI Assist reformatted the output into a table with columns for Step Number, Step Title, Step Instruction, UI Element/Location, and Notes/Accessibility, ready for an OGL developer to pick up directly.
So what does this mean in practice? An OGL team no longer has to start from a blank page when a quarterly release drops. AI Success Navigator can triage features, identify which ones need OGL attention, and produce a first-draft flow that a developer can then validate and publish. That’s a material reduction in the time between a feature dropping and users having contextual guidance in the application.
One thing to note: AI-generated flows still need validation against the actual application UI and tailoring to your specific user roles and configuration. The AI is a starting point, not a finished product. But it’s a very good starting point.
The webinar also covered the Testing Agent, which I think gets overlooked. It lets you create test cases from scratch using AI, upload existing test scripts for conversion, and refine them through AI Assist. The connection to OGL is practical: well-structured test cases describe real user workflows, and those workflows are exactly the raw material you need to build accurate OGL guides. If your testing and OGL content creation are happening in silos today, AI Success Navigator gives you a way to bring them closer together.
I’ve always felt that AI Success Navigator and OGL were solving related problems without talking to each other enough. What Oracle is doing now is starting to close that gap, and it’s a direction I’m very happy about.
If you’re not already using Oracle AI Success Navigator and you have an Oracle Cloud subscription, start exploring it. If you’re an OGL practitioner, the AI Assist capability is worth your attention specifically. And if you want to understand how the two products can work together in your programme, now is a good time to start that conversation.
Please note all screenshots are the property of Oracle and are used according to their Copyright Guidelines
Over the last three blogs, I’ve explored how AI Agent Studio connects to the wider enterprise, how agents are triggered and interacted with, and how workflows are designed to be reliable and production‑ready. In this final part of the series, I want to pull those threads together and focus on the capabilities that help agents scale safely and operate with confidence over time. This is where governance, control and operational discipline really come into play, and where the newer 26A and 26B features start to show how Oracle is shaping AI Agent Studio for long‑term, enterprise use rather than short‑lived experimentation.
Choosing the right document or memory node is an area where I see a lot of confusion in conversations with clients, so it is worth being very clear about what each one is designed to do. The Document Processor node is intended for runtime documents, attachments that arrive as part of a specific workflow execution, such as a supplier quote received by email, an invoice uploaded through chat, or a UCM attachment linked to a Fusion business object. Its job is to retrieve the file, extract the text, and pass that content on to the next node in the workflow. It is not designed for querying a stable or long‑lived corpus of documents, such as policy or reference material that you want to reuse and search repeatedly over time.
The RAG Document Tool node is designed for exactly that stable, reusable collection of information. You curate a set of documents within an Oracle AI Agent Studio Document Tool, move them through the lifecycle from Ready to Publish to Published, and the RAG node then performs semantic retrieval against that content to ground downstream LLM reasoning in your own policies, playbooks or manuals. To get the best results, it is important to use specific queries with clear discriminators such as module, process area, country or version, which helps improve retrieval precision. It is also good practice to include an explicit “no results” fallback path in your workflow, rather than allowing the LLM to guess when retrieval confidence is low.
The Vector DB Reader and Writer nodes serve a different purpose again, providing durable semantic memory that persists across workflow runs. They are best used to store normalised, reusable knowledge units such as validated resolution summaries, previous exception details, or extracted entity representations. Entries should be kept short and semantically focused, enriched with meaningful metadata to support filtering, and assigned stable document IDs to avoid duplicates. Raw PII or permission‑restricted data should never be stored without a deliberate access control design. When reading from the vector store, metadata filters should always be applied, and low‑confidence matches should be treated the same as no result at all, routing the workflow to a deterministic fallback rather than continuing on uncertain ground.
One theme that came through strongly in the partner training sessions, and one I think represents genuinely good discipline, is treating Workflow Agent testing as a first‑class concern rather than something bolted on at the end. Oracle’s evaluation framework for Workflow Agents, often referred to as Workflow Evals, is based on supplying structured JSON test inputs and asserting expected outputs. These evaluations are intended to be run as a regression suite whenever you change a prompt, adjust a node configuration, swap a tool, or update a policy, helping you catch unintended side effects early and keep agent behaviour stable as it evolves.
A good starting point is to define around five core paths through the workflow: the happy path, two or three of the most common exception scenarios, and at least one case that deals with missing or poor‑quality input data. From there, you should be tracking things like overall pass rate, branch accuracy, schema validity, and retry or escalation behaviour. The aim is not simply to prove that the workflow reaches an end state, but to make sure it routes correctly and predictably under every condition that genuinely matters in production.
For anyone building more complex workflows, the full context variable reference is well worth bookmarking. In practice, a small set of variables tends to do a lot of the heavy lifting, such as $context.$nodes.<nodecode>.$status to check whether a preceding node succeeded or failed, and $context.$nodes.<human_node_code>.$actionPerformed to capture whether a Human Approval step resulted in APPROVE, REJECT or REQUEST_CHANGES. You can also use $context.$nodes.<human_node_code>.$feedbackReceived to pick up any comments provided by the approver, and $context.$workflow.$traceId to generate idempotency keys or include trace references in error notifications. For conversational workflows, $context.$system.$chatHistory is particularly useful, as it exposes the full session history and allows the agent to reason about what has already been discussed.
The 26A roadmap also includes several upcoming capabilities that will significantly extend what is possible in the near term. Support for the Model Context Protocol, or MCP, means Workflow Agents will be able to invoke tools exposed by MCP servers, broadening the integration landscape well beyond traditional REST APIs. The Agent Studio Help Assistant, an AI‑driven guide embedded directly within the studio, should also make agent design far more accessible, particularly for practitioners who are new to the tooling. Alongside this, multi‑modal enhancements, including end‑user Q&A over images and documents uploaded in chat and semantic search across non‑text assets, open up an entirely new set of document understanding and reasoning use cases.
Looking a little further ahead, the roadmap includes capabilities such as breakpoint‑style debugging, automated prompt engineering, multi‑user development environments, and a Bring Your Own LLM option, alongside additional interaction channels including WhatsApp, SMS and telephony. Taken together, these signal a sustained level of investment in the platform and a clear focus on making AI Agent Studio more powerful, more accessible, and more suitable for enterprise‑scale use. The overall direction is a positive one, and it is clear that Oracle is building towards a mature, long‑term agent platform rather than a short‑term experiment.
The partner training sessions that informed this post covered a lot of practical ground, and I genuinely believe they will save teams a significant amount of time as they start building in earnest. If you are already exploring AI Agent Studio and would like to talk through any of these patterns in more detail, I would be very happy to continue the conversation. And if you have not yet read the earlier posts in this series, it is worth starting at the beginning with the overview of how Workflow Agents are structured, which sets the context for everything covered here.
Please note all screenshots are the property of Oracle and are used according to their Copyright Guidelines
In the first two blogs, I looked at how AI Agent Studio connects to the wider enterprise landscape and how agents are triggered and engaged, whether by systems, schedules or users. In this third part, I want to step back slightly and focus on what happens inside the agent itself, specifically how workflows are structured, how context is managed, and how you start designing for reliability rather than experimentation. This is the point where agent design shifts from “can we make it work?” to “can we trust it to run consistently in production?”, and the 26A capabilities give you far more control here than many people realise. To check out the previous blog, please click here.
The Wait node, which is being introduced as part of the 26B release, addresses a long‑standing gap in workflow design, where there was no clean way for a workflow to pause and resume later without either completing immediately or blocking indefinitely. When a Wait node is reached, the workflow moves straight into a Waiting state and pauses execution for a configured period of time, up to a maximum of 60 minutes. Once that wait period expires, the workflow can optionally loop back to an earlier point before continuing, allowing it to re‑evaluate conditions or check for updates. This looping behaviour is controlled through two simple settings: the Loop Back Node, which defines where execution returns to, and Maximum Iterations, which limits how many times the workflow can loop before it continues forward regardless.
In practice, this enables a clean polling pattern that is otherwise difficult to model. For example, imagine a workflow that creates a receipt request in Fusion and then needs to confirm that the receipt has been posted before it can move on. By using a Wait node configured for five minutes and looping back to a Business Object read node up to ten times, the workflow effectively gives itself a 50‑minute window to detect the receipt posting automatically before either continuing or escalating. During each wait cycle, the node outputs ORA_USER_INPUT_REQUIRED, and once all iterations are exhausted it returns WAIT_TIME_EXPIRED_AND_MAX_ITERATIONS_REACHED, both of which can be evaluated in downstream If Condition nodes to route the flow appropriately.
The Code node is one of the most powerful building blocks in a Workflow Agent, and also one of the most commonly underestimated. It executes JavaScript and returns a single value, whether that is an array, boolean, number, object or string. Its real value lies in handling the deterministic work that you should never push into an LLM node, such as data normalisation, threshold calculations, schema validation, array filtering and payload shaping. Used well, it provides a clean separation between predictable logic and probabilistic reasoning, which is a key ingredient in building workflows that behave consistently and are easier to trust in production.
There are a few important constraints to be aware of when designing logic for the Code node. Execution is limited to five seconds, with an upper limit of 100,000 statement executions, and functions cannot be defined within the code, which means recursion is not supported. Most built‑in JavaScript methods are available, but there is no external access, so no REST calls, file system operations, console logging or library imports. The code can read from $context, $currentItem and $currentItemIndex, but it cannot modify the $context object directly. Instead, it simply returns a value, and that returned output is the sole result of the node.
Some of the most effective patterns I’ve seen make particularly good use of the Code node for this kind of deterministic work. Common examples include normalising inconsistent date strings and currency values into canonical formats before passing them to a Business Object write node, or calculating variance percentages for three‑way match validation so that an If Condition node receives a simple boolean rather than needing to express complex arithmetic. Other strong patterns include generating idempotency keys using a combination of $context.$workflow.$traceId and object identifiers to prevent duplicate writes during retries, and filtering arrays returned from Business Object reads so that only active or primary records are passed into a For Loop for further processing.
For workflows that are triggered through the AI chat interface, 26A also introduced support for file uploads during conversations with an agent, allowing users to attach up to five files with a combined size of 50 MB. A wide range of formats is supported, including PDF, DOCX, XLSX, PPTX, PNG, JPEG, HTML, Markdown, JSON, XML, CSV and ZIP. To work with these attachments inside a Workflow Agent, 26A required the delivered MultiFileProcessor tool to be added to an agent and that agent then included within the main workflow. This capability significantly expands what chat‑driven workflows can handle, particularly when dealing with documents, structured data and supporting evidence provided directly by the user. In 26B, this has been simplified significantly. Rather than introducing a separate agent, you can now add a Tool node directly into your Workflow Agent and select Chat Attachments Reader as the tool type. This keeps the workflow much cleaner and removes an unnecessary orchestration step. The tool reads the files uploaded in the current chat session and exposes the extracted content directly to downstream nodes, making it easier to act on user‑provided documents without additional plumbing or indirection.
Support is also in place for third‑party file storage, allowing users to upload files directly from Google Drive, Dropbox or Microsoft OneDrive, provided those credentials are configured under the Chat Experience tab in Credentials. Enabling this involves registering an OAuth application with the relevant provider, obtaining the client credentials, configuring the account in Credentials, and then switching on the option to allow users to upload files from connected cloud storage accounts on the agent’s Chat Experience tab. Once configured, this gives users a seamless way to bring external documents into agent‑driven workflows without needing to download and re‑upload files manually.
This third blog has focused on what really makes Workflow Agents robust in practice, from pausing and polling patterns, through deterministic logic in Code nodes, to handling documents and attachments cleanly inside workflows. These are the building blocks that move agents beyond experimentation and into something you can rely on day to day. In the final post in this four‑part series, I’ll bring everything together and look at the remaining 26A and 26B capabilities that round out the platform, focusing on how they support governance, scale and long‑term operational confidence when running AI agents in production.
Please note all screenshots are the property of Oracle and are used according to their Copyright Guidelines
In the first blog, I focused on how AI Agent Studio connects to the wider enterprise landscape, but once those connections are in place, the next question is how and when agents are actually set in motion. I touched briefly on triggers in an earlier post, but the depth available here really deserves a closer look. In AI Agent Studio, a published Workflow Agent can be kicked off in three distinct ways: via a webhook, through email, or on a schedule. Each option supports very different use cases, from event‑driven automation to time‑based controls, and understanding how to use them effectively is key to building agents that fit naturally into day‑to‑day operations rather than feeling bolted on.
The webhook trigger is the mechanism behind the invokeAsync API call discussed earlier, but it also supports a more flexible and powerful pattern. When configuring a webhook trigger, you can define named input variables, which are passed into the REST call as part of the parameters object. Within the workflow, those values are exposed via $context.$triggers.REST.$input.<InputName>, allowing you to build parameterised workflows that adapt their behaviour based on what the calling system provides. This is particularly useful when you want a single workflow to handle multiple variations of a process, with the external system supplying the context that determines how the agent responds.
The email trigger is one I find particularly practical. You configure a Google or Microsoft email account under Credentials, set the account type to Inbound, and from that point on, any new email arriving in the inbox automatically kicks off the workflow. The email body, sender address, subject, headers and even attachment content are all exposed as context variables, such as $context.$triggers.EMAIL.$input.content, $context.$triggers.EMAIL.$input.fromAddress, and processed attachment text via $context.$triggers.EMAIL.$input.attachments[0].context. This makes document ingestion workflows genuinely straightforward to build. For example, a supplier can email a quote to a monitored inbox, the email trigger fires, a Document Processor node extracts the line items, and the workflow creates a purchase requisition in Fusion, with no human involvement unless an exception is identified.
The schedule trigger supports two distinct patterns, depending on how you want your workflow to run. Interval scheduling fires on a repeating, time‑based cadence, configured in seconds, minutes, hours or days from a defined anchor point, while recurrence scheduling uses more familiar calendar‑based patterns, either one‑off or repeating, such as weekly on specific days. One practical point to be aware of is that the user creating a scheduled workflow must be assigned the FAI Batch Job Manager Duty role (ORA_DR_FAI_BATCH_JOB_MANAGER_DUTY) for the scheduling job to be created successfully. It is an easy detail to miss during initial setup, but one that is worth flagging early to your security or roles team to avoid unnecessary delays.
The 26A release also introduced native channel integrations for both Microsoft Teams and Slack, and I expect these to become the primary way many organisations interact with AI agents, rather than relying on the embedded Fusion chat widget. At a high level, the Microsoft Teams setup involves configuring the channel under Credentials, supplying the Teams bot or app details, generating and downloading the app manifest, and then uploading it to Teams as a custom application. Once this is in place, users can discover and select available agents directly within Teams and interact with them in exactly the same way they would through the native Fusion chat experience, but in a collaboration tool they already use every day.
One final point worth calling out is that a new duty role has been introduced to group all channel‑related permissions for both Microsoft Teams and Slack. This role includes permissions such as ChannelManifest and ExternalChatCorrelation, and it is required for any user who needs to configure channel integrations or interact with agents through Teams or Slack. As with any new security object, it is worth factoring this into your role review and security planning early, so it does not become a blocker when 26A goes live in your environment.
This blog is the second in a series of four exploring the latest capabilities in Oracle AI Agent Studio introduced in 26A. In this part, I’ve focused on how Workflow Agents are triggered and how those triggers shape real‑world usage, from event‑driven integrations through to scheduled and collaborative interactions. In the next post, I’ll move on to another key area of the platform, building on these foundations and looking at how the newer features work together to support robust, production‑ready agent solutions.
Please note all screenshots are the property of Oracle and are used according to their Copyright Guidelines
I’ve written quite a bit recently about Oracle AI Agent Studio and what it can do at a high level, and those posts have led to some really valuable conversations. A question that keeps coming up, though, is a very practical one: “This all sounds great, but how does it actually fit into the rest of my technology landscape?” Closely followed by, “How do I build something that’s reliable and production‑ready, rather than just impressive in a demo?” This post is my attempt to answer both, drawing on the training content from the AI World partner sessions, which goes into a level of detail that genuinely changes how you think about building with AI Agent Studio, particularly when it comes to integration, robustness and real‑world use. I should say up front that this series is a little more technical than my usual blogs, but it feels important to share, because this is the detail that turns AI from an interesting idea into something you can confidently run and scale.
One announcement I haven’t covered yet is the invokeAsync REST API, introduced in 26A, which allows external applications to programmatically call published Agent Teams in Fusion, and this is a significant step forward for organisations where Fusion sits alongside other enterprise systems. It means those systems can now trigger Fusion AI agents directly, without a user ever needing to open the chat interface. The process works in two stages: an external application sends a POST request to the invoke endpoint, passing either a user prompt or structured data, and because AI agents may need time to reason or retrieve information, the call returns a job ID rather than an immediate response. That job ID is then used to poll a separate status endpoint, which returns the final output along with useful metadata such as status, conversation ID, trace ID and timing information. For development and testing, adding ?invocationMode=ADMIN to the status endpoint provides detailed debug output, including the full node execution trace, which is invaluable when you are building and troubleshooting. Authentication follows the standard OAuth 2.0 bearer token approach used across Fusion APIs, so if you are already familiar with OCI IAM and IDCS, there is nothing fundamentally new to configure.
For those looking for a more standardised integration approach, Oracle also introduced support for the A2A, or Agent‑to‑Agent, protocol in 26A. A2A allows a client to discover agents through a well‑known metadata endpoint, often referred to as the agent card, initiate a task by sending a message, and then poll for the result using the same job ID pattern. The agents search endpoint makes it possible to query for published agents by name, which is particularly useful when you are building orchestration layers that need to dynamically discover and delegate work to specialist agents. The agent card itself returns the agent’s capabilities and supported methods in a structured format, making it much easier to establish interoperability between Fusion agents and third‑party systems without relying on custom, point‑to‑point integrations.
The relationship between Fusion and the outside world does not just work in one direction. In 26A, Oracle introduced Data Source Applications within the Credentials tab of AI Agent Studio, allowing administrators to configure OAuth connections to non‑Fusion systems such as EPM Cloud, WMS, or any external application with a compatible identity provider. Once a Data Source Application is set up with the base URL, IDCS URL, client ID, scope and key pair, it becomes available as a selectable source when creating a Business Object using the resource type “Other Data Source Application”. This makes it much easier for AI agents to securely reach out to external systems, bringing data back into Fusion in a controlled and repeatable way rather than relying on custom or hard‑coded integrations.
At runtime, when a Business Object function within a workflow needs to call an external system, the platform simply uses the saved configuration to obtain an OAuth token and invoke the target API behind the scenes. From the workflow designer’s point of view, it behaves exactly like any other Business Object node, with no additional complexity to manage. This opens up some genuinely powerful patterns, such as an HCM Workflow Agent that validates a job requisition in Fusion, checks headcount or budget in EPM, and then writes the outcome back to a Fusion record, all within a single, governed automation that remains transparent, secure and easy to maintain.
This blog is the first in a short series of four, where I will walk through some of the latest and most important functionality in Oracle AI Agent Studio introduced in 26A. In this opening post, I’ve focused on how agents connect to the wider enterprise landscape, because integration, reliability and governance are what ultimately determine whether AI delivers real value. In the next blogs, I’ll build on this foundation and explore other new capabilities in more detail, looking at how they work in practice and how you can apply them confidently in real‑world scenarios.
Please note all screenshots are the property of Oracle and are used according to their Copyright Guidelines
K8 Mead 