Category: Generative AI

Oracle’s HCM Professional Concierge: What It Is, How It Works, and Why It Matters for HR Teams

~ K8 Mead ~ Leave a comment

Oracle has been steadily building out its AI story in HCM Cloud, but the HCM Professional Concierge is one of the first examples that really feels tangible for HR teams. This is not AI added for the sake of it. It is a set of purpose-built, role-aware conversational agents, built directly into the HCM Redwood experience. For me, it stands out as one of the more considered uses of AI Agents in enterprise HR.

If you work in HR operations or as an HR Business Partner, the scenario will feel familiar. A manager wants to understand where their team sits on compensation ahead of a salary review. They open Employment Info, scroll through individual records, try to piece together performance data from one place, compensation history from another, and absence data from somewhere else. It is not a difficult task, but it is a fragmented one. Before long, ten minutes have passed just getting a basic view.

The HCM Professional Concierge simplifies this by bringing everything into a single conversational experience, embedded wherever the HR user is already working. Instead of navigating between screens, they ask a question. The agent brings together the relevant data, guides the next step, and in some cases can even trigger the action directly from the conversation.

It is worth understanding that this is not a single AI agent working behind the scenes. Oracle has taken a supervisor and sub-agent approach, where a top-level Concierge Supervisor receives the user’s query, interprets the intent, and then routes it to the most appropriate specialist agent.

Within the HR Professional Concierge, those specialist agents each focus on a particular area of HR. For example, the Compensation Advisor brings together key information such as compensation data, compa‑ratios, time since the last salary change, and pay grade details for a manager’s direct reports. The Talent Advisor focuses on performance, helping to summarise ratings and support more informed performance conversations.

Other agents support core HR data and processes. The Employment Details Assistant provides access to employment history, assignment information and worker details, while the Leave and Absence Analyst helps identify and manage absence across a team. There is also support for understanding organisational design through the Workforce Structures agent.

In addition, the Concierge can surface policy and guidance through the Policy sub-agent, review personal worker data where needed, and launch reporting through the Reports sub-agent. For broader, team-level insight, the Team Data Hub helps bring data together to support analysis.

What this means in practice is that the user experiences a single, coherent conversation, even though multiple specialist agents may be working in the background to fulfil the request.

So when a manager asks, “show me the most recent performance rating and time since the last salary change for my direct reports”, the Manager Concierge Supervisor recognises that the query spans both compensation and talent data. It then coordinates across the Compensation Advisor and the Talent Advisor behind the scenes. What comes back is a single, joined-up view, rather than two separate outputs that the manager has to reconcile themselves.

That orchestration across multiple agents is where the real value starts to show. Conversational assistants in enterprise applications are not new in themselves. What is more interesting here is the ability to coordinate specialist agents within a single interaction, carry context across the conversation, and route requests intelligently based on both the topic and the data required.

Oracle has introduced three distinct Concierge experiences, each designed around a specific user group and how they typically work. The HCM Professional Concierge is aimed at HR specialists and HR Business Partners. It sits within the HCM Professional Activity Centre, which has become the central workspace for HR service delivery, and supports the sort of queries an HR analyst would usually run. That includes pulling together workforce data for individuals or manager populations, reviewing compensation and employment history, running reports, looking up policies, and guiding HR actions within the flow of work.

The Manager Concierge is focused on line managers who need quick, straightforward access to information about their teams. It brings together compensation, absence, talent and employment data without the need to navigate into individual worker records. The experience adapts based on both the question being asked and the context of the manager’s team, giving them a practical way to not only view information but also complete common HR tasks directly.

The Worker Concierge, meanwhile, is designed for employees themselves. It brings together support for areas such as leave, payroll, benefits and compensation into a single, consistent experience. Behind the scenes, it routes queries to the relevant specialist agent, whether that relates to absence, benefits, pay, or compensation, so the employee does not need to think about where to go to get the answer.

A simple scenario helps bring this to life. A line manager has been told that budget has been allocated for pay rises and promotions across the organisation. Before making any decisions, she wants a clear view of where her team currently stands. Using the Manager Concierge, she can ask a straightforward question in natural language, such as “how long has it been since my direct reports received a pay rise?” The Compensation Advisor returns the answer in a structured, easy-to-read format. She then follows up with a more specific question, “what is Elaine’s compa-ratio?”, and gets a direct response.

Within the same conversation, she can ask for performance ratings through the Talent Advisor and pull through grade information using the Employment Details Assistant. It all happens in one place, without needing to navigate between screens. Multiple specialist agents are working in the background, but from the manager’s perspective it feels like a single, joined-up interaction.

The HR specialist perspective is just as telling. If someone is working on an Employment Info page for a specific worker, they can open the Concierge panel and ask something like, “what is the salary history for Ravi?” or “where is Ravi located?” The response comes back as structured data pulled directly from HCM, without the need to navigate away or open multiple pages.

One question that comes up consistently when Oracle’s AI features are discussed is around data access and security. It is an important one, and the answer here is reassuring. The HCM Professional Concierge works within the same data and functional security model already applied across the HCM Redwood experience. If an HR specialist does not have permission to view a particular employee’s salary in the core application, they will not be able to access it through the Concierge either. There is no separate access layer being introduced. It simply operates within the role-based controls that are already in place.

For organisations working across multiple geographies, the same principle applies. The agent respects the existing configuration of Redwood pages, including any geography-specific policies and legislative requirements. There is also flexibility to tailor how the agent behaves by refining prompts to reflect your organisation’s terminology or local nuances.

The Concierge also sits within a broader shift in how Oracle is shaping the HR user experience. It is alongside the HCM Professional Activity Centre, which acts as a unified Redwood workspace for HR administration. The Activity Centre brings together a more flexible approach to worker search, with filtering, saved views and personalised results. From there, HR specialists can move straight into transactions from a worker’s profile without switching to a separate area. Common actions are surfaced directly in the interface, including access to areas such as the Recruiting Activity Centre, Mass Assignment Change, Mass Legal Employer Change, Payroll Activity Centre and Attendance Violations, which makes it easier to act on information as soon as it is identified.

The Concierge is always present within the Activity Center, giving HR specialists access to conversational support in the context of the work they are already doing.

It also sits within a much broader direction Oracle is taking with role-based, agent-led HR applications. The HR Specialist Workspace is a good example of where this is heading. It builds on the same foundations, but moves towards a Redwood workspace where multiple specialist agents work together to surface relevant insights more proactively.

In that model, the workspace brings together a view of workforce priorities, potential restructuring impacts, compliance alerts, attrition risk and open HR cases. These are drawn from coordinated agent outputs across areas such as Workforce Management, Talent and Learning. The shift here is subtle but important. The agents are not just responding to questions, they are actively identifying what might need attention and presenting it to the user.

There is also a clear emphasis on governance. Audit trails, controls and human oversight are built into how actions are handed off. Oracle is quite deliberate in positioning this around measurable outcomes, with coordinated agent activity and clear decision points. That creates an important distinction from more autonomous AI models. Here, the agents surface and recommend, but people remain firmly in control of decisions and actions.

From an implementation perspective, the HCM Professional Concierge and its supporting agents are delivered as part of Oracle HCM Cloud Release 26C. There is no need to build these capabilities from the ground up. They are available out of the box, with the ability to adapt behaviour through prompt configuration so that it reflects your organisation’s terminology and ways of working.

As ever, I will keep a close eye on how this develops across the HCM suite and share updates as new capabilities emerge. If you are starting to think about how this fits into your wider HCM AI strategy, or you are planning for a 26C upgrade, now is a sensible point to begin that conversation.

Please note all screenshots are the property of Oracle and are used according to their Copyright Guidelines

Getting Started with Oracle Payables Agent: Inbox to Invoice, Touchlessly

~ K8 Mead ~ Leave a comment

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

Oracle Fusion App Builder: Streamline Your Agentic Applications

~ K8 Mead ~ Leave a comment

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

Oracle Expenses Agent: The Touchless Future of Employee Expense Management

~ K8 Mead ~ Leave a comment

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

Reinventing How Work Works: The Business Case for Oracle Fusion Agentic Applications

~ K8 Mead ~ Leave a comment

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

Going Deeper with Oracle AI Agent Studio: Connecting, Triggering, and Building with Confidence – Part 4

~ K8 Mead ~ Leave a comment

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

Going Deeper with Oracle AI Agent Studio: Connecting, Triggering, and Building with Confidence – Part 3

~ K8 Mead ~ 1 Comment

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

Going Deeper with Oracle AI Agent Studio: Connecting, Triggering, and Building with Confidence – Part 2

~ K8 Mead ~ 1 Comment

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

Going Deeper with Oracle AI Agent Studio: Connecting, Triggering, and Building with Confidence – Part 1

~ K8 Mead ~ 1 Comment

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

Oracle Enterprise Data Management Cloud: Where AI Readiness Actually Starts

~ K8 Mead ~ Leave a comment

If you’ve been working in Oracle Cloud for any length of time, you’ll know that data governance quality determines the quality of everything downstream. Reports, forecasts, consolidations, AI outputs: they’re all only as good as the master data behind them. Following the EDM London Spotlight I attended, here’s where the product stands and where it’s heading.

What EDM is (and isn’t)

The naming matters. EDM is “Enterprise Data” Management, not Enterprise “Data Management.” It’s not a database tool or storage layer. It’s a governed system of reference for managing the data that describes your enterprise: hierarchies, dimensions, master data, reference data, data maps, taxonomies, reporting structures.

The problem it solves is one most Oracle customers will recognise. Without EDM, a chart of accounts change request starts with an email to IT, fans out to half a dozen application admins, and ends somewhere between a hierarchy mismatch in Planning and a data kickout in Financial Consolidation and Close (FCC). No audit trail, no systematic workflow, no single point of control. EDM replaces that with a governed, collaborative process where changes are requested, validated, approved, and propagated in a controlled sequence.

EDM versus Oracle DRM

DRM was built for waterfall implementation: gather requirements, build the model, deliver, train, repeat. EDM is designed for an agile, incremental approach. Turn it on, start using it, add rules and policies as they become evident. The traditional MDM big-bang approach has a well-documented failure rate, and EDM’s application-centric model sidesteps it. You start with one application, demonstrate value, and grow from there. New applications are onboarded incrementally without disrupting what’s already in place. For organisations still on DRM, the migration path is practical: users continue in DRM while it’s registered inside EDM as an application, and the legacy system is archived once the transition is complete.

Implementation design patterns

The London session was clear on which pattern works best. Nominate an originating application rather than using a master application as the front door to all changes. The originating application pattern keeps data, objects, and validations scoped to the application that owns them. Downstream applications subscribe to changes. This avoids the problem where a single undifferentiated data model makes it impossible to isolate which rules belong to which application. The master application pattern can work if you reduce it to canonical properties only, but it adds complexity and makes onboarding new applications more disruptive.

EDM and AI

Oracle’s AI approach in EDM operates at two levels.

Internal assistants work within EDM’s existing request and approval model. The Registration Assistant (25.12) generates application metadata and configuration artefacts from a sample data file, accelerating new application setup considerably. The Conversational Request Assistant lets users query master data in natural language, ask questions about existing requests, and generate bulk update actions, all within normal governance controls. Future internal assistants on the roadmap include a Data Profiling Assistant and a Data Matching Assistant using hybrid string, fuzzy, and semantic match rules.

Foundational data governance for AI is arguably the most consequential angle. When enterprise data objects lack clear intent in their descriptions, AI models infer incorrectly. Conflicting hierarchies across ERP, EPM, SCM, and HCM produce inconsistent answers. EDM’s governed descriptions, properties, hierarchies, and cross-application mappings become the ground truth that AI models rely on, reducing hallucination risk and making outputs auditable. If your organisation is investing in enterprise AI, getting master data governance right isn’t optional preparation: it’s what determines whether your AI outputs are trustworthy.

Multi-domain MDM and the roadmap

EDM was built domain-agnostic from day one, which is a genuine competitive differentiator. Competitors largely started in a single domain and expanded. EDM covers Party, Product, Location, Finance, and other domains natively. For Fusion ERP customers, CDM (Customer Data Management) remains the right starting point for mastering customer party records. EDM enriches those with alternate hierarchies, data maps, and cross-application alignment before distributing to EPM and Analytics. For heterogeneous environments with multiple Salesforce instances across regions, EDM can act as the central master customer data hub.

If your Oracle Cloud implementation hasn’t included an EDM conversation yet, it probably should. And if you’re planning an AI initiative on top of Oracle Fusion, EDM is where the trusted data foundation that makes AI outputs reliable actually gets built.

Please note all screenshots are the property of Oracle and are used according to their Copyright Guidelines