PTC Next 2026: Every Tool Got an AI. None of Them Got the Same Memory.

Fourth and final article in my PTC Next 2026 series. The first asked whether “intelligent” PLM is a rename or an architecture. This one follows the AI across four tools to find out.

The short version, for anyone scanning: At PTC Next 2026, AI arrived in every PLM tool, in CAD, in Windchill, in service, in the new collaboration and data platforms. But each tool captures only a fragment of the product’s reasoning and keeps that fragment to itself. CAD captures design intent locally. PLM captures the change but not the why. Service captures the reasoning because it can’t run without it. PTC’s own AI lead said the agents must be orchestrated on captured decisions, yet the layer that would capture and connect that reasoning across tools, a shared product context layer, is the one piece the event named but did not wire together. That missing context layer, not the count of AI agents, is the real story of PTC Next.

At PTC Next, AI was not a session. It was the air. It showed up in CAD, in PLM, in change management, in service, in collaboration, in parts search. By the end of two days the safe conclusion was the easy one: every engineering tool is getting an assistant, and PTC is shipping them faster than most.

That conclusion is true, and it is not the interesting part.

The interesting part only appears when you stop looking at each assistant on its own and watch them side by side. Because when you do, the same thing happens four times, in four unrelated tools, described by four different people who were not coordinating their language. Each one demonstrates a real AI capability. Each one, if you listen past the demo, runs into the same wall. And each one either solves that wall or fails to, in exactly the same way.

I want to walk through four of them, because one example is an anecdote and four is an argument. The question I carried through every session was not “is this AI any good?” Most of it was good. The question was the one underneath it: what does each of these assistants need beneath it to actually be useful, and is anyone building that?

The answer, by the end, is a single architectural idea. But it earns itself one tool at a time.

CAD: the cleanest case

Start with CAD, because the CAD people were the most honest about the limit.

Darren Henry has been in the CAD industry for three decades, early at SolidWorks and early at Onshape, and he spent his session doing something rare at a vendor event: arguing against the most hyped version of his own category. The hype is text-to-CAD. Point a large language model at a prompt, get a 3D model back. His social feed, he said, is full of it, including a post claiming someone had open-sourced a model that “could end the 150-hour CAD business.”

He doesn’t buy it, and his reasoning is the most useful thing I heard about AI all week.

The generated models, he said, are brittle. They look fine until you try to edit one. Ask an LLM for a washer and it draws a washer, but when you go to resize it, you discover “it missed the intelligence of the sketch. It didn’t know that those circles are supposed to be concentric.” Ask for a Raspberry Pi case and you get a box that falls apart on the first edit, because the model never knew the corners were supposed to be coincident or the walls perpendicular. The geometry is there. The reasoning behind the geometry is not. As Henry put it: “LLMs are great at coding, but they don’t understand sketching and sketch relationships… it doesn’t understand how faces are related.”

Then he named what the market actually wants, and it’s worth quoting exactly: “What the market wants is for AI to understand its domain expertise, its design intent, and make a robust model that’s human, editable.”

Design intent. Not shapes. Intent.

And here is the move that makes this the template for the whole article. Henry’s answer is not a better model. It’s an abstraction layer. Onshape’s FeatureScript, a CAD-specific language that, in his words, “captures design intent” and “regenerates robustly,” sits between the language model and the geometry. The AI doesn’t draw the part; it writes the code that builds the part, and that code carries the intent the raw geometry can’t. His phrase, and it’s the one to remember: “We’re not going text to CAD. We’re really going text to code to CAD.”

Notice what that does. The value was never the generation. You can get generation from any chatbot. The value is the captured-intent layer underneath it, the thing that makes the result robust, editable, and reusable. Henry even draws out the economics: once the AI writes that FeatureScript feature, “AI created a tool and we’re benefiting from it. We’re not using AI tokens anymore.” The captured layer is an asset that persists and gets shared across the organization. Raw generation is a cost you pay again on every edit.

And PTC isn’t treating this as an Onshape curiosity. Henry was explicit that the company is building the same kind of abstraction layer into Creo, “a CAD-specific language, very compact, that will be able to do similar things.” It isn’t shipped yet; he framed it as work in progress, and that distinction matters. But the direction is the tell. FeatureScript was built into Onshape years ago, as Henry notes, “without any indication that we were going to use it for AI.” Now, having watched it become the thing that makes AI-driven design actually work, PTC has decided to build the same intent-capturing layer a second time, in its flagship installed-base CAD system. That is not a feature decision. When a vendor chooses to rebuild the same layer in a second product rather than bolt a bigger model onto the first, it’s telling you where it believes the value lives: not in the generation, but in the layer underneath that remembers why the geometry is the way it is.

Hold that shape in your head, because you’re about to see it three more times:

The AI capability is real. Its limit is that it operates on output, not intent. And it only becomes useful when something underneath it captures the reasoning the generation throws away.

Henry solved this at the level of a single part (capture the design intent, don’t regenerate it), and PTC believes in the solution enough to build it twice. But everything so far lives inside CAD. The layer captures why this geometry. It says nothing about why this part, in this product, for this customer, after this change. That reasoning lives one level up, in PLM, and that’s where the same problem reappears wearing a different face.

PLM: the retrieval ceiling

Move up a level, from the part to the system that’s supposed to know everything about the part.

Mark Lobo, who runs Windchill, opened with a line more honest than most vendors manage about their own flagship: PLM, he said, is “the richest product data system of record” you deal with, and the place where the people who need that data “really struggle in finding it and interpreting it.” Hold those two halves together, because the whole section lives in the gap between them. The data is all there. Getting an answer out of it is the hard part. AI, Lobo argued, is what finally turns “a system of record into a system of intelligence.” (That phrase will sound familiar to long-time readers; it’s a framing I’ve used here for years, now delivered from a PTC stage. I’ll take the validation and keep pushing.)

So what does the AI actually do? Lobo showed two agents, and they’re worth looking at precisely because they’re genuinely useful. The first tackles duplicate parts, the quiet tax every PLM system pays. Using computer vision, it scans the database by 3D geometry, finds the duplicate parts, augments them with metadata, and routes them into a change-management workflow so you can rationalize them. The second is a problem-report agent: a technician takes a screenshot, and an agentic framework turns it into a Windchill problem report and walks the user through the change process. Both are real, both ship, both save time.

Now watch where each one stops. Look at what they operate on: geometry that already exists, metadata that already exists, a change object being created in the moment. The reuse agent is the cleanest example. It finds the two duplicate parts. It can even tell you which products they’re used in and which suppliers made them. The one thing it cannot tell you is why two teams created the same part in the first place, and that “why” is the only thing that would stop it from happening a third time. The agent cleans up the consequence of a decision whose reasoning was never captured. Next quarter, two more teams will make the same call, for reasons the system still won’t hold, and the agent will dutifully find those duplicates too.

This is the same wall Henry hit, one level up. In CAD, the AI had the geometry but not the design intent. In PLM, the AI has the record of what exists and what changed, but not the why behind it. Lobo’s own framing gives the game away: a system of record stores what is true. A “system of intelligence” would have to store why it became true. The agents reach the edge of the record and stop, because the reasoning was never written down anywhere they could reach.

And notice what’s missing that was present in the CAD story. Onshape had an abstraction layer, FeatureScript, that captured intent and made it durable. Windchill’s agents have no equivalent. There’s no layer here that captures why a change was approved, why an alternate was rejected, why the duplicate looked necessary at the time. The agents retrieve; they don’t remember. What this section needs underneath it is exactly what CAD already built and PLM hasn’t: a place where the why is captured, not just the what.

Service: the one place the why survives

So far the pattern has been a wall. Here it inverts, and that’s why this part is the shortest and the most important.

Move to service, where Joseph June described the AI capability in Servigistics. The optimization engines, he said, have always been powerful but opaque. They produce a recommendation and you have “no idea of why you optimize that particular way.” What AI changes is small to describe and large in consequence: you can now ask the engine, in his words, “why did you do that?”, and get an answer about why it made those particular decisions.

Stop on that, because it’s the first time in three tools that the why is actually present. CAD captured intent but kept it inside the part. PLM captured the change but not the reasoning. Service captured the reasoning, and the moment it did, the AI crossed the line from retrieval into something that looks like judgment. June extends the same idea to troubleshooting: not just what you’ve seen, but “what the entire service organization has seen for the history of the entire service organization,” applied to the problem in front of you. That is reasoning over captured decisions, exactly the thing the other two sections were missing.

Here’s the part worth sitting with. It is no accident that the one place the why survives is service. Service is the one domain where you physically cannot do the work on what alone. You can’t dispatch a technician, stock a part, or close a work order without the reasoning behind it, so the industry was forced to capture it. The captured-reasoning layer the other tools lack didn’t appear in service because someone designed it as a context layer. It appeared because the work refused to function without it.

Which raises the question this whole article has been walking toward. If captured reasoning is what makes the service AI qualitatively better, and it is, then why does that capability stop at the edge of service? Why is the why stranded in one corner of the lifecycle, when the bracket-redesign question June himself posed needs reasoning from CAD, materials, quality, and the field all at once? The service section gives us the positive proof: when the reasoning is captured, the AI works. What it doesn’t give us, and what the rest of the event kept circling, is how you’d capture and connect that reasoning across every tool instead of one.

That’s the question PTC’s own AI lead picked up next.

The turn: June names the layer, then almost connects it

Here is where the event stopped being a sequence of demos and became, for about ten minutes, an architecture talk. Joseph June, who runs AI strategy, walked through the platform underneath all the agents, and in doing so he made my argument for me, named the upstream collaboration layer as part of it, and stopped one wire short of the thing this series is about.

Follow the logic, because it’s his, not mine.

He started where the service section ended: the models are commoditizing. The frontier systems are converging, and the difference between the latest releases, he said, “probably doesn’t impact all of you that much.” So what becomes scarce when the model is a commodity? “Data, of course.” Not just data, but data prepared so the AI can reason over it. In his framing, the old world stored data “so that they could be displayed”; the new world stores it “so that it can be reasoned over.” That’s the same line the three tools have been drawing from the other direction.

Then he posed the question that is, almost word for word, the spine of this article. You have specialized agents now, in CAD, in PLM, in service. They’re meant to work together. But, he asked: “If you have a group of 20 agents that are capable of these specialized tasks, who tells them what to do? Agents are great, but who orchestrates them?”

And his answer is the one that should make anyone who has been arguing for a context layer sit up. You orchestrate them, he said, using your data, but specifically the part of the data that is decisions. The product data foundation matters, in his words, because it “represents decisions that a lot of people have made,” from which the AI “can learn decision-making pattern. You can learn from your successes, you can learn from your failures, and then you can encapsulate that into an AI system.”

Read that again with the three tools in mind. CAD captured intent locally. PLM captured the change, not the why. Service captured the reasoning, because it had to. June just said the quiet part out loud: the thing that orchestrates AI across all of those tools is captured decisions, the why, the successes, the failures, encapsulated into a layer the agents can reason over. That is not a description of a system of record. It is a description of a context layer. He named it from the stage.

Now hold that against the two products he placed on this platform. June was explicit that the unified AI platform has “several components,” an agent layer, a data layer, and a model, and that the two flagship launches “will utilize the platform to power its agents and understand its data.” One of those launches aggregates asset data across PLM, IoT, and service. The other, the upstream collaboration platform I wrote about separately, is built, in its own product lead’s words, to capture “the decisions and the intents behind those decisions,” and “why those decisions were made and the reasoning behind it,” sitting deliberately beside the system of record rather than inside it.

So look at what PTC actually has on the table. A platform whose AI lead says it must be orchestrated on captured decisions. A data layer that aggregates records across the lifecycle. And, separately, an upstream layer that captures exactly the decisions and intent June says the orchestration needs. The pieces are all present, named, and on the same slide.

What I did not hear, and I was listening for it, is the wire between them. June described the need for captured decision-context to orchestrate agents. The collaboration layer demonstrates the mechanism for capturing that context upstream. But “both utilize the platform” is a grouping, not an integration. Nobody showed the decision-context captured upstream flowing down to orchestrate the agents in CAD, PLM, and service. The data-aggregation layer answers what the product is. The collaboration layer captures why a decision was made. PTC put them in the same architecture and did not, on stage, connect them into the same context.

That gap is not a criticism of PTC’s vision. It is PTC’s own vision, stated by its own people, with one connection left undrawn: the connection that turns three tool-level assistants and a data platform into a single lifecycle that actually reasons over its own decisions.

What each tool captures, and keeps to itself

Every tool captures a fragment of the product’s reasoning, and every tool keeps its fragment to itself.

The verdict

So let me answer the question I opened this series with, the one I put to a PTC rep on the show floor and have carried through four articles: is “intelligent” a new architecture, or is it toasted?

After four tools, the answer is sharper than either. PTC has the right pieces, named correctly, by the right people. The CAD layer captures design intent, and the company is building it twice. The PLM agents are real. The service AI proves that captured reasoning changes everything. And June stood on stage and said the orchestration has to run on captured decisions: the why, the successes, the failures. Nobody at this event was confused about the destination.

What’s missing is one wire. Each tool captures a fragment of the why and keeps it to itself. The data platform aggregates the what across the lifecycle. The upstream collaboration layer captures the why, and sits beside the record, not connected to the agents that need it. PTC put all of this on the same slide and did not connect it into the same context. That is not a rename. It is also not, yet, an architecture. It is an architecture’s parts, named and un-wired.

Which is exactly what the rep told me in the booth, before any of the keynotes: the intelligent-lifecycle vision becomes real only once the reasoning is captured in connected form, and today, mostly, it isn’t. Four days of sessions didn’t contradict him. They specified him. The missing layer has a precise shape now: not a bigger database, not a better model, but the thing that captures the why each tool produces and connects it across all of them, without collapsing back into the monolith the industry already knows doesn’t hold.

That layer is the real story of PTC Next. Whether it’s one vendor’s un-drawn wire or the direction the whole industry is being pulled, by the same logic, from several sides at once, is a question worth its own article, on its own terms, not filed under any one vendor’s event. I’ll take that one up next.

For now: PTC named the layer. The work is connecting it.

Just my thoughts…

Best, Oleg

Disclaimer: I’m the co-founder and CEO of OpenBOM, an AI-native collaborative digital thread platform connecting engineers and manufacturing teams. My opinion can be unintentionally biased.