This is PLM perspective on enterprise AI, business context, and the challenge of openness.
The two main keynotes at Oracle AI World 2026 made me rethink the relationship between enterprise AI and product knowledge. Oracle presented a strategy in which software takes more responsibility for coordinating and executing business work. From a PLM perspective, the interesting question is how that strategy connects broad business context with the engineering knowledge needed to make dependable decisions.
I came to Oracle AI World 2026 with an engineering and manufacturing perspective. Like many people in the PLM industry, I usually encounter Oracle in discussions about enterprise applications, manufacturing processes, and ERP integration. We talk about releasing items, transferring BOMs, synchronizing revisions, and connecting engineering with downstream operations. Agile PLM (even belonging to Oracle) always was a separate thing.
We spend an enormous amount of time operating software. We search for information, compare records, prepare spreadsheets, ask for clarification, and tell someone what needs to happen next. Oracle presented a direction in which people describe an objective and software coordinates more of the activities required to achieve it.
I will write a separate article about the Oracle Cloud PLM session. Here, I want to focus on what I learned from the two keynotes and the questions they raised about context, enterprise ecosystems, and openness.
What the Oracle AI World 2026 keynotes revealed
The first day made the ambition tangible through business situations. Supply chain planning, employee services, restaurant operations, and healthcare illustrated how AI could participate in daily work. Across these examples, the goal was to reduce the effort people spend assembling information and moving a process forward.
The second day explored the foundations behind that ambition: infrastructure, security, agent identity, business context, and application development. It also brought the collaboration between Oracle and OpenAI into the discussion.
I found the combination interesting. Showing an agent complete a task is one thing. Giving it a dependable operating environment requires a much wider set of capabilities. The two days connected the experience people might have with the architecture needed to support it.
Of course, a keynote presents a company’s direction through carefully selected examples. It cannot demonstrate all the complexity customers will encounter. But those examples provide a useful starting point for asking where enterprise software is going and what will determine whether the vision works in practice.
Oracle’s enterprise AI strategy beyond ERP integration
In PLM, we have spent decades discussing the connection between engineering and ERP. Manufacturing companies need engineering definitions to become usable information for purchasing, planning, production, and financial processes. But treating Oracle primarily as an ERP integration destination gives us a limited view of its strategy.
The keynotes brought together applications, databases, analytics, cloud infrastructure, identity, security, and tools for creating applications. They prompted me to think about how Oracle approaches the enterprise and how that differs from the starting points familiar to the PLM industry.
How PLM heritage shapes enterprise AI strategy
Much of enterprise PLM traditionally developed around MCAD and PDM. PTC, Siemens, and Dassault Systèmes illustrate that heritage, with engineering models, product structures, configurations, revisions, and changes forming an important foundation. Aras represents another path, emphasizing an adaptable platform for modeling product information and lifecycle processes.
These are starting points, not complete descriptions of today’s platforms. All these companies have expanded their scope. Still, heritage influences which problems a vendor sees first and how it organizes information to solve them.
Oracle brings a perspective shaped by databases, ERP, and a broad portfolio of business applications. Through that lens, the product participates in transactions, supply chain commitments, costs, and operational processes. Engineering knowledge needs to contribute to decisions across that environment.
An engineering-centered discussion might begin with a component change and examine its downstream consequences. A business-centered discussion might begin with a customer delivery at risk and work backward to identify the product decisions needed to resolve it. Both require engineering and operational knowledge, approached from different directions.
This is what makes Oracle’s enterprise AI strategy interesting to a PLM audience. The question becomes how broad business coordination can work with the engineering depth needed to make a technically valid decision. AI creates an opportunity to connect these perspectives more closely, provided the systems involved can preserve meaning and respect each other’s authority.
AI agents move from applications to business outcomes
The Day 1 shipping demonstration provided a concrete example. The starting point was an operational objective: improve a load plan while respecting business constraints. The demonstration moved through analysis, proposed actions, optimization, and execution, with some situations requiring human review.
What caught my attention was the relationship between these steps. People routinely perform this coordination themselves, carrying information between applications and checking whether a recommendation can actually be implemented. Oracle showed an ambition to give software more responsibility for that coordination.
The Day 2 supplier-disruption example connected even more directly to manufacturing. A threatened customer order required a recovery plan involving product specifications, an alternative product, warehouse availability, delivery requirements, and information from meetings and team conversations.
The entry point was a customer commitment. Resolving it required working back into product knowledge. This reverses the direction of many familiar PLM discussions, where an engineering change is the starting point and business consequences follow.
Watching the demonstration, I immediately started asking engineering questions. Is the proposed alternative approved for this configuration? Which revision applies? Does the customer’s specification permit the substitution? Is an engineering change required?
These are questions prompted by the example. A commercially attractive substitute may need validation against materials, interfaces, compliance, or customer-specific qualification. Warehouse availability cannot establish engineering suitability. How will broad enterprise AI platforms work with the specialized systems that maintain this knowledge?
Why enterprise AI needs trusted product context
The discussion of business ontologies was especially interesting to me. Oracle described using AI to help establish and maintain business context, with business and technical experts retaining ownership and control. (Oracle’s business context announcement)
I have been fascinated by knowledge graphs since the early days of the semantic web. The attraction is straightforward: information becomes more useful when we can understand the relationships around it. Engineering and manufacturing provide countless examples.
A part number identifies something. To make a decision, we may also need its revision, lifecycle state, applicable configuration, supplier relationships, and connection to an order. A drawing can be accurate and still be the wrong drawing for the situation being evaluated.
An ontology can help describe entities and relationships consistently. Maintaining agreement about what those relationships mean is an ongoing organizational responsibility. Engineering, purchasing, and service can use similar words while referring to different things.
Consider an approved alternative. Does approval apply everywhere, or only to a particular assembly, customer, factory, or period? An agent needs access to that distinction before it can use the approval correctly. Finding a document containing the word approved does not establish applicability.
This expands what we should expect from PLM and ERP integration. Exchanging items, BOMs, and lifecycle states remains necessary. Coordinating a decision also requires understanding which system establishes demand, which establishes engineering applicability, and who can approve the proposed action. The integration must support that shared decision while keeping responsibility clear.
AI governance before and after execution
One detail in the shipping demonstration stood out: the system checked the current state before executing the plan. That might sound like a technical detail, but it has important business meaning.
A recommendation is based on conditions observed at a particular time. Inventory can change. Another order can consume capacity. Engineering can release a new revision. A supplier can withdraw a commitment. By the time an action is approved, the assumptions behind it may already be outdated.
Read is forgiving. Acting is not.
The keynotes also connected execution with outcome receipts, agent identity, and restricted access. Together, these ideas raise practical questions about who acted, what authority they had, which procedures applied, and what evidence supported the action.
For a product substitution, I would want the record to connect the decision with the relevant configuration, source revisions, approval, and conditions checked before execution. A transaction log tells us something happened. Understanding whether it was appropriate requires the surrounding context.
The Spectrum HR example offered a useful organizational lesson. Repeatable work governed by clear policies could be delegated, while sensitive decisions and exceptions remained with people. The boundary matters because it defines where software can proceed and where judgment is required.
Manufacturing will need equally explicit boundaries. An agent might investigate alternatives, collect evidence, and prepare a change proposal. Authority to approve it may belong elsewhere. Greater autonomy will depend on making those responsibilities understandable and enforceable.
Oracle and OpenAI connect enterprise applications with frontier AI
The Oracle and OpenAI collaboration was another important observation from the second day. Oracle AI Workspace was presented as a way to bring OpenAI models together with Oracle applications, enterprise data, and cloud services through a unified experience. (Oracle’s introduction to AI Workspace)
For me, the strategic interest is how these capabilities come together. Enterprise platforms bring business applications, operational data, permissions, and established processes. Frontier AI companies bring models and tools that change how people reason, interact with information, and create software.
The boundaries are evolving. AI can operate inside an application, provide an interface across applications, or help someone create a new application around a business need. The same person might use all three approaches during a working day.
This raises an interesting question for enterprise software vendors: where will the relationship with the user begin? A person facing a supplier disruption may start in an AI workspace, even when the evidence needed to resolve it sits in several specialized systems.
For PLM, the implication is that product knowledge must be usable wherever that interaction begins. Its usefulness will depend on whether another system can understand its meaning, establish its authority, and apply it within the appropriate controls.
I also see a reason to watch these partnerships carefully. A joint demonstration can show a compelling experience. Customers will need to understand how the responsibilities are divided as the services evolve, particularly when several vendors participate in the same business process.
Openness and interoperability across PLM and ERP systems
This brings me to a question that deserves more attention: how open will these ecosystems be in practice?
Most manufacturers I know operate across multiple software environments. Different departments choose different tools. Acquisitions add systems. Customers impose requirements. Suppliers maintain their own environments. Historical investments remain in use because they continue to support important work.
An enterprise AI strategy has to accommodate that diversity. Engineering authority may reside in one vendor’s PLM, inventory in another ERP, and customer requirements in documents outside both. Oracle’s breadth makes coordination interesting; connecting it with specialized engineering environments makes openness essential.
I would evaluate openness through several practical questions.
First, how far can the ecosystem reach? Can an agent work with authoritative information in other vendors’ CAD, PLM, ERP, and manufacturing systems? Access must include enough meaning to support the intended decision.
Second, can context remain distributed? Some information will be indexed, cached, or copied. Customers need to understand what is being replicated, how changes propagate, and how an agent checks the current revision or lifecycle state before acting.
Third, who resolves conflicting meaning? Two systems may be misaligned about part identity, approval status, or which configuration applies. Establishing a connection does not resolve the disagreement. Someone must own the rules and the exceptions.
Fourth, how does authority cross boundaries? Permission to read a record in one system does not automatically grant permission to change an order in another. Approvals and execution records need to remain understandable across the complete process.
Fifth, how much choice and portability do customers retain? Can they change models, use specialist agents, or reuse their accumulated business context elsewhere? Ontologies, skills, and decision history represent a growing investment.
Finally, what happens across company boundaries? Suppliers and customers need to contribute relevant information while controlling what they disclose. Collaboration cannot depend on every participant adopting the same platform.
APIs, standards, partnerships, and access terms all matter here. The test is whether companies can accomplish useful work across the environments they actually operate. The Oracle and OpenAI collaboration makes this a timely question; it does not settle all these issues by itself.
Creating applications becomes easier
The Day 2 discussion of APEX and App Composer added another dimension. AI is changing how software is created while also changing how it is used. Oracle presented tools intended to connect application creation with enterprise governance and deployment. (Oracle’s OpenAI collaboration announcement)
This has practical appeal. A person who understands a recurring business problem may be able to create a focused application without waiting for a large development project. A workflow used to recover one customer order could become something a team reuses.
In manufacturing, I can imagine specialized tools for reviewing shortages, collecting supplier commitments, or examining the consequences of a proposed change. These are possibilities I take from the direction presented, rather than claims about applications shown on stage.
The challenge grows as more people build. Applications need owners, permissions, maintained dependencies, and a way to be retired. They also need dependable product definitions. Ten useful applications can create ten conflicting interpretations of a released item if each builds its own assumptions.
As creating an interface becomes easier, I expect more attention to shift toward the information and operating rules behind it. A shared product foundation becomes valuable because many applications can use it consistently. I explored this question further in my article on AI and PLM software moats.
Implementation knowledge becomes executable
The Fusion Setup and Configuration Registry deserves attention for a related reason. Oracle described making setup and configuration knowledge available as machine-readable, executable AI skills through a public repository. (the public configuration registry)
Implementation expertise has traditionally been distributed across documentation, consultants, project experience, and the people who understand dependencies between settings. Capturing more of that knowledge in maintained skills could help agents perform configuration and validation work more consistently.
For PLM, implementation effort has always influenced adoption. If agents can accelerate routine setup and checking, specialists may have more time to address the organizational decisions that determine whether a system is useful.
Those decisions remain substantial. Who owns an item? What does release mean? When is an exception acceptable? How should engineering and purchasing resolve a disagreement? Software can help document and enforce an answer, but the organization still needs to agree on it.
I see this as an opportunity to make implementation knowledge more reusable while bringing the human decisions into clearer focus. Faster configuration will deliver value when it supports an operating model people understand and accept.
What is my conclusion?
Oracle’s keynotes offered a useful perspective for a PLM audience precisely because the starting point was broader enterprise work. The engineering definition of the product remains essential. Increasingly, it needs to participate in decisions initiated by a shortage, a customer commitment, a production problem, or a service event.
This connects to what I call product memory. Engineering systems retain knowledge of what was designed, changed, and approved. Operational systems record what was ordered, purchased, built, and delivered. Product memory connects those histories with the decisions and rationale linking them. Understanding why a substitution was accepted for one order and rejected for another can inform the next decision.
The opportunity is to connect engineering intent with operational experience across the systems where each is maintained. Oracle’s enterprise ecosystem and its collaboration with OpenAI provide an interesting setting for watching this develop. Their practical value will depend partly on how they accommodate other systems and preserve customer choice.
As software starts doing more work, product knowledge needs to become usable context for that work. Distributed authority, connected context, and governed action provide a useful direction. The measure will be whether people can resolve problems sooner and make dependable decisions without repeatedly reconstructing the product story across disconnected systems. That is an opportunity worth exploring.
Just my thoughts…
Best, Oleg
Disclaimer: I’m 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.
Publishing metadata
SEO title: Oracle AI World 2026: When Enterprise Software Does the Work
URL slug: oracle-ai-world-2026-enterprise-ai-strategy
Meta description: My Oracle AI World 2026 takeaways: enterprise AI strategy, trusted product context, Oracle–OpenAI collaboration, and openness across PLM and ERP systems.
Primary topic: Oracle AI World 2026
Supporting topics: Oracle enterprise AI strategy; AI agents in enterprise software; PLM and ERP integration; business context; enterprise AI interoperability
Tags: Oracle, Oracle AI World, Enterprise AI, PLM, ERP Integration, Product Memory
