From Connected Systems to Intelligent Engineering

Why AI agents need more than access to data

For years, digital transformation in engineering has focused on integration.

We connected CAD to PLM, PLM to ERP, and engineering to manufacturing, quality, suppliers, and service.

That work is still necessary. But connecting systems is no longer the hardest problem.

The harder problem is preserving engineering context as information moves across those systems.

A requirement is not just text. A design is not just geometry. A change is not just a revised object. Each carries context, including product configuration, revision, dependencies, ownership, approvals, and the decisions that came before it.

When that context is lost, systems may still be connected, but engineering knowledge is not.

Traditional integration is designed to move information between systems. But moving data does not guarantee that the receiving system or team understands what the data means.

Can a requirement remain connected to the design, test, risk, and certification evidence it affects?

Can a design change be understood across software, hardware, manufacturing, quality, and service?

Can teams determine which product, customer configuration, and revision the information applies to?

Can they identify which information is authoritative and which is only a copy?

The real challenge is no longer simply moving information. It is preserving the relationships that make that information useful.

Why engineering context matters more than system integration

The digital thread is often described as a connection between lifecycle systems. That description is incomplete.

A meaningful digital thread must allow people and systems to understand what changed, why it changed, what is affected, which configuration it applies to, who approved it, and what evidence supports the decision.

This requires persistent identities, traceable relationships, configuration awareness, ownership, provenance, and authority.

The goal is not to move every engineering discipline into one system. Modern engineering environments will remain distributed. Mechanical design, electronics, software, systems engineering, simulation, manufacturing, quality, suppliers, and service will continue to use different tools.

The goal is to keep information distributed without losing the context that connects it.

AI is making this more important.

The first generation of engineering AI has mostly operated as a copilot. Copilots help people search, summarize, generate content, compare information, and recommend next steps. The person interprets the result and decides what to do.

The next phase is the move to agents.

Agents do not only answer questions. They participate in workflows.

An engineering agent may prepare a change, identify affected items, update information, assemble supporting evidence, or route work for approval.

That creates a much higher bar for the underlying data environment.

A copilot can still be useful with partial context. An agent cannot safely act without knowing which product, variant, and revision it is working on, which information is authoritative, what depends on the item being changed, which rules apply, and where human approval is required.

Connecting an agent to several systems does not mean it understands the relationships between the information inside them.

An agent may make a locally correct change that creates problems elsewhere. A requirement change may affect software, hardware, tests, manufacturing instructions, suppliers, and certification evidence. The same change may be valid for one product configuration and wrong for another.

This is why access to data is not enough. AI needs product context.

The opportunity is not unrestricted autonomy. It is controlled delegation.

AI can prepare proposed work, identify dependencies, evaluate impact, create supporting evidence, and route the work to the right reviewer. People retain judgment, approval, and accountability.

For this model to work, the product environment must define what the agent can access, what it is allowed to change, which dependencies it must evaluate, which rules it must follow, and who must approve the result.

Without that foundation, engineering agents will remain limited to isolated and low-risk tasks. With it, they can begin to support meaningful engineering workflows.

Building a PLM foundation for AI agents

PLM has traditionally served as the system of record for product structures, revisions, documents, and processes. That role remains important, but it is no longer sufficient on its own.

PLM must increasingly help preserve product context across a distributed engineering environment. Its value is not simply in storing more information. Its value is in maintaining the relationships needed to understand the product, evaluate change, and support decisions.

This becomes even more important when AI begins to participate in those decisions and workflows.

For engineering and PLM leaders, the question is no longer only whether systems are connected.

The more important question is whether engineering context survives across them.

Can dependencies be understood before a change is made? Can product configuration be determined reliably? Can AI distinguish authoritative information from merely available information? Can every proposed action be traced to its evidence and approval?

The companies that solve these problems will be in a much stronger position to manage product complexity and scale AI responsibly.

Integration remains essential. But integration is not the destination.

The destination is a coherent, governed, and actionable understanding of the product, strong enough for people to trust and for AI agents to act upon.

For more on this topic, read Building the Foundation for AI in Product Development.