I came to Oracle AI World 2026 to catch up on what Oracle is doing and understand where it is taking Oracle Fusion Cloud PLM. The PLM industry has been flooded with announcements and commentary about Agile PLM’s “end of life,” with much of the conversation focused on migration, replacement, and competing vendors offering a new home to Agile customers. With Premier Support for Agile PLM 9.3.6 ending in December 2027, customers have real decisions ahead. I wanted to hear Oracle’s perspective directly and learn what it is building next.
I attended “PLM Product Strategy and Roadmap: AI, Modern UX, and the Move to Cloud” (LRN1080). I was especially interested in hearing from John Kelley, whom I have known for many years and who has long been leading Oracle’s PLM work. John brings considerable experience and continuity to this conversation. His session with the Oracle PLM team was an opportunity to understand how they are addressing customers’ current needs while developing a different vision for how product teams might work.
In my earlier article yesterday, Oracle AI World 2026: When Enterprise Software Starts Doing the Work, I shared my broader observations. The keynotes presented an enterprise software strategy spanning business applications, data, infrastructure, and AI, with software taking more responsibility for coordinating and executing work. Here, I want to look more closely at how that strategy connects to PLM.
That connection is what interests me most. For years, the PLM industry has discussed how engineering information reaches downstream business processes. Oracle’s broader announcements invite us to examine that relationship from another direction: when a business needs to resolve a supply problem, meet a delivery commitment, or prepare a product for launch, how does it bring the right engineering knowledge into the decision?
I went into the session with that question in mind. I wanted to understand how Oracle’s enterprise ambitions translate into the everyday work of managing product structures, evaluating changes, and deciding whether a product is ready, and how the engineering context behind those decisions remains connected.
Oracle Fusion Cloud PLM and enterprise change management
The session began with a practical reminder that the fundamentals still matter. Items, BOMs, effectivity, manufacturing definitions, and change control remain the foundation on which any AI capability must operate.
The team described an expanding scope for enterprise change management, connecting product structures with manufacturing work definitions and configurator rules. Formula management and model/unit effectivity illustrated the needs of different industries. The digital thread extended toward manufacturing execution, genealogy, quality, and operational feedback.
There were also roadmap elements. The slide on propagating EBOM-to-MBOM changes across multiple organizations through a single change order was explicitly labeled future roadmap. These distinctions matter when evaluating the distance between an architectural direction and what a customer can implement today.
The scope reflects Oracle’s perspective. Much of enterprise PLM developed around engineering models and PDM, although today’s platforms reach well beyond those origins. Oracle also has substantial PLM experience through Agile, but Fusion places product information inside a wider business applications environment.
For Agile customers, this makes the cloud discussion more substantial than a change of hosting. Moving familiar objects and workflows is only part of the work. Companies need to determine how their engineering practices fit the wider operating model, including who owns product definitions and how manufacturing or sourcing participates in a change. User experience matters in that transition.
That changes the starting point of some conversations. An engineering team may begin with a component revision. An operations team may begin with a delivery commitment at risk. Resolving either situation can require the same product knowledge, approached through different responsibilities.
For me, this is the significance of enterprise change management: extending the decision across the business while maintaining a precise understanding of what is changing.
Product Readiness Workspace and BOM release decisions
The Product Readiness Workspace demonstration made that connection tangible. The example involved RACK-900, an AI training rack approaching design freeze. New supplier, compliance, and quality evidence triggered a fresh assessment of whether the product was ready to advance.
The analysis examined the BOM across lifecycle, sourcing, compliance, quality, and cost. It identified two cable components with compliance violations that blocked release. The assessment showed a 35-item scope and an overall grade, but the release decision depended on the specific conditions controlling the gate.
That distinction deserves attention. A cost advantage elsewhere in a product cannot compensate for a mandatory compliance failure. An average score helps people navigate complexity, while the decision still requires rules attached to particular parts and their use in the product.
The demonstration also distinguished confirmed violations from gaps in supporting evidence. Missing documentation requires investigation; it does not automatically establish that a component violates a requirement. An engineering organization needs to preserve that difference when assigning work and deciding what can proceed.
The next step compared recovery options, including correcting incumbent parts and qualifying alternative sources. The selected path involved qualified alternatives, with cost, capacity, compliance, and schedule considered together. After approval, the demonstration carried the recommendation into change and sourcing activities and updated the readiness plan.
I found this more interesting than another demonstration of finding information in a BOM. The business question determined which relationships and evidence needed examination.
It also suggests a useful way to think about readiness. Readiness belongs to a particular product configuration, milestone, and moment. A product can satisfy a design review while still lacking the supply conditions needed for a production commitment. New evidence can change the assessment after an earlier approval.
Qualification provides a practical test of the approach. An agent can gather test evidence, check its applicability, identify missing approvals, and coordinate the remaining tasks. The organization still determines what constitutes sufficient qualification. Understanding how the software distinguishes completed evidence from work still required will be essential when evaluating these capabilities in practice.
The demonstration presented a controlled example, rather than proof of performance across real customer environments. Still, it provides a concrete setting for evaluating whether AI can help teams keep those changing conditions visible and coordinate the work required to resolve them.
Fusion Claw and governed agentic PLM
The architecture discussion was equally interesting. The presenters described their progression from embedded generative AI to agent teams and then workflow agents. They also discussed difficulties with nondeterministic collaboration between agents.
Their response was to combine model reasoning and planning with deterministic computation and execution. Fusion Claw was presented as the runtime supporting more complex work, including analysis, simulation, and execution within defined authority.
There is an economic argument here: high-volume calculations do not all need to consume model reasoning. There is also an engineering argument. Once a plan is approved, calculations and transactions need to follow explicit rules at the required scale. Oracle explains this separation in its Fusion Claw announcement.
The session used the idea of an enterprise operating harness to describe what an agent may do, when it must involve a person, and how its actions remain controlled. Oracle’s published architecture further distinguishes the Enterprise Operating Envelope from the Outcome Trust Harness that applies controls to a particular run.
This connects directly to a question I have been exploring: what environment does AI need in order to do useful engineering work? A process description alone cannot answer it. The environment must connect product information with executable operations, validation, permissions, and decision boundaries.
Deterministic execution does not establish that the original plan was correct. If the wrong revision enters an assessment, a perfectly executed workflow can still produce an unsuitable result. The harness therefore needs reliable product context as well as control over actions.
The interface changes fit this picture. Conversational interaction can reduce the effort of navigating application screens, but the underlying semantics remain essential. Which organization, configuration, effectivity, and change state does a request concern?
The presenters also made clear that Redwood remains the interface for the foundational system of record. Meanwhile, the AskOracle routing slide was marked as a draft design for 27A. The direction is toward an intent-driven experience supported by governed application capabilities, with different elements at different stages of delivery.
Outcome Receipts and the history behind product decisions
One of the most interesting parts of the demonstration came at the end: the Outcome Receipt. The screen showed a chain of evidence connecting the outcome with ownership, approvals, operating procedures, execution details, and linked transactions.
This deserves credit. As software takes responsibility for more work, organizations need to inspect the basis on which that work was performed. A completed transaction provides only part of the explanation. The authority, evidence, and decisions behind it also matter.
For PLM, the next question is how useful that explanation remains over time. Consider a component selected because the preferred part could not meet a launch date. Six months later, the preferred part is available again, demand has changed, and an engineer is considering another substitution.
In that hypothetical situation, the approved BOM identifies the selected component. Understanding the next decision also requires knowing which constraints drove the earlier choice and whether they still apply. It may matter that an alternative was rejected because qualification was incomplete, rather than because the part was technically unsuitable.
An outcome receipt can preserve evidence and decisions that help answer these questions. The architectural challenge is making them discoverable and connected to later changes, across the systems and teams involved.
I would therefore examine whether a future assessment can reuse the earlier evidence, distinguish expired assumptions, and identify the person or process with authority to reconsider a decision. Keeping records of completed agent runs is valuable. Connecting their reasoning to the evolving product makes that history useful for subsequent work.
Preserving this context also requires deliberate choices about what to capture. A useful receipt cannot recover an engineering assumption that nobody recorded or made available. The work therefore includes creating moments for people to contribute missing rationale, linking it to evidence, and retaining uncertainty instead of turning every explanation into an established fact.
This is a broader issue than any particular AI runtime. Engineering organizations already create substantial knowledge while resolving exceptions. Too much of the effort must be repeated because the next person can find the result more easily than the reasoning that produced it.
Connecting engineering work with enterprise PLM
The BOM Builder demonstration brought the discussion closer to engineering’s daily work. It showed a workflow for bringing prototype BOM information from files into the enterprise environment, applying item rules, and involving a person in validation before the information was uploaded.
That addresses a familiar source of friction. Product information begins in many places, and translating it into governed records requires more than copying rows. Part numbering, parent-child relationships, required attributes, and existing items all affect what the imported structure means.
But importing a BOM also raises a wider architectural question: how does the enterprise retain a connection to the engineering work that produced it?
A spreadsheet can represent a useful snapshot. The engineering definition may continue changing in CAD, with assembly dependencies, file versions, drawings, and alternative configurations evolving before a formal release. Those relationships influence which information is valid and which checks are necessary.
A saved CAD version, an engineering BOM revision, and an approved enterprise change describe different events. Their relationships need to remain explicit if an agent is expected to assess impact or recommend an action.
This is where I see an important role for an engineering environment connected to enterprise governance. Engineers need to develop and examine product definitions in the context of their tools and work in progress. Enterprise processes need clear conditions for accepting and acting on that information.
The handoff becomes more useful when it preserves the references behind the released structure. A sourcing decision may later require the drawing and revision that established a requirement. A change analysis may need to distinguish a proposed design from the configuration actually released.
AI increases the importance of these connections. The faster software can evaluate and execute a decision, the more consequential an ambiguous engineering handoff becomes. This is one reason I am interested in how the engineering and enterprise layers develop together.
Oracle PLM interoperability and product context
The Q&A provided a useful opportunity to look beyond the boundaries of the demonstration. The team discussed external information, REST access, custom objects, and plans for a Fusion MCP endpoint that could expose context to other agent frameworks.
I see this as an important direction. Manufacturers operate across CAD, PLM, ERP, supplier, and production environments. Some of the information required for a product decision will sit outside the application coordinating the work.
The practical test of openness is what an external participant can understand and do with that information. An API can return a part number and description, while a dependable decision may require the item’s revision, lifecycle state, effectivity, and relationship to a particular assembly.
The same applies to documents. Making a supplier declaration searchable can help someone find it. Using it in a readiness decision requires knowing which manufacturer part, material, product configuration, and period it covers. A relevant document can still be insufficient evidence for the question being asked.
There is an authority question as well. If an agent coordinates work across systems, it must respect which system governs each fact and which organization can authorize each action. Permission to propose a substitute does not necessarily include permission to approve its engineering use.
This is where integration becomes more demanding as AI advances. For years, integrations have concentrated on transferring records and synchronizing fields. Agentic work adds the need to preserve enough meaning for another application to evaluate consequences and act within its authority.
The session’s discussion of external context was encouraging, but the planned MCP endpoint should be evaluated as a direction, with practical behavior still to be examined. Connectivity, semantic depth, and enforceable decision rights will all influence whether customers can coordinate work across their actual mix of systems.
What is my conclusion?
I came to learn what Oracle is doing with PLM beyond the Agile migration discussion. The session gave me a clearer picture of a strategy connecting product definition with enterprise decisions and giving software more responsibility for moving those decisions into action.
The difficult work remains in the relationships underneath that experience. Product identity, configuration, evidence, engineering intent, and decision authority must remain understandable as information moves between teams and applications.
This connects to what I call Product Memory, a subject I am developing in my book, From CAD Files to Product Memory. The opportunity is to connect product records with the history, assumptions, and rationale that make them useful for the next decision. Oracle’s Outcome Receipt provides an interesting point of connection to that discussion.
My interest in Oracle’s broad enterprise strategy and its PLM work comes together here. Better product decisions require engineering knowledge and operational experience to inform each other. The measure of progress will be whether people can resolve problems with less reconstruction of context, while retaining control over the decisions that matter.
Just my thoughts…
Best, Oleg
Disclosure: I am the co-founder and CEO of OpenBOM. My work on connected product data and Product Memory shapes my perspective, and my opinion can be unintentionally biased.
There was also another reason for my trip related to OpenBOM. At the event, we announced the OpenBOM and Trinamix partnership, bringing OpenBOM’s cloud PDM technology together with Trinamix’s Oracle expertise to connect CAD work and engineering BOMs with Oracle Fusion Cloud PLM. Working on that connection gives me a particular interest in how engineering information becomes part of the broader enterprise environment.
