The Claude Code leak exposed something more important than Anthropic’s unreleased features. It exposed what production AI systems are actually made of — and why that matters for everyone building or buying PLM software today.
Earlier this week, Anthropic’s Claude Code accidentally leaked its internal source code. The predictable reaction followed: people rushed to inspect hidden feature flags, unreleased capabilities, and internal product clues. That is what always happens when a high-profile AI product exposes its internals. Everyone looks for the roadmap.
But the roadmap was not the most important thing in that leak.
What mattered was the architecture it exposed. Claude Code is not simply a smart model attached to a coding environment. The LLM call is only a fraction of the system. The real product lives in session persistence, permission pipelines, tool registries, context management, error recovery, and operational observability. The intelligence is not only in the model. It is in everything built around the model.
That distinction matters far beyond AI coding tools. It matters to everyone currently claiming that the future of PLM is about “adding AI” to existing platforms. Because once you understand what a production AI system actually looks like, three assumptions that drive most of today’s PLM AI strategy start to fall apart. I want to challenge each of them directly.
Why a Smarter AI Model Does Not Make PLM Intelligent
This is probably the most widespread belief in enterprise software right now, and it is wrong in a way that is easy to miss.
The reasoning goes like this: AI models are improving at a remarkable pace. Each generation handles more complex reasoning, longer context, better nuance. So if you connect a sufficiently capable model to your PLM system, intelligence will emerge from the combination. The platform becomes smart by association.
The Claude Code leak points directly at the flaw in this logic.
What the analysis of that leak made clear is that even Anthropic, which builds some of the most capable models in the world, does not rely on model capability alone to produce a working AI system. The numbers tell that story directly. The leaked source comprises 512,000 lines of TypeScript across 1,906 files. The query engine alone — the module that handles LLM calls, streaming, caching, and orchestration — runs to 46,000 lines. The base tool system definition adds another 29,000. The LLM call itself is a small fraction of what makes Claude Code work. The rest is the architecture wrapped around it: session state, permission-gated tool execution, a three-layer memory system, multi-agent coordination, context budget management, error recovery, and operational observability. And in a detail that should give every PLM vendor pause, the system is explicitly designed not to trust its own memory — every agent is instructed to treat what it remembers as a hint and verify it against the actual source of truth before acting. Remove that surrounding architecture and the model alone cannot produce reliable, actionable behavior in a real environment.
In PLM terms, this translates directly. Smarter prompts on top of brittle product data and disconnected workflows do not produce an intelligent product system. They produce smarter-looking guesses. A model connected to a legacy PLM database will confidently summarize stale records, generate plausible-sounding recommendations without knowing which data source is authoritative, and fail in ways that are harder to detect precisely because the outputs look coherent.
Intelligence in a production system is not a property of the model. It is a property of the operational architecture the model operates inside. Most PLM vendors are still selling the opposite assumption. I wrote about this pattern earlier in Building PLM Agents: Why Everyone Is Announcing AI and Why Almost Everyone Is Missing the Point — the gap between what vendors announce and what the architecture can actually support is wide, and it is not closing fast.
AI Copilot vs AI Agent: Why PLM Needs More Than a Copilot
The second assumption has two versions worth separating.
The copilot version is at least honest about what it is. A copilot sits alongside a user, summarizes content, answers questions, and helps navigate a system. It does not change the platform. It helps the user interact with the platform that already exists. That can be useful and reduce friction. But it is a productivity tool, not a platform transformation.
The agent version is where the assumption becomes seriously misleading.
An agent is not a more capable copilot. An agent is a fundamentally different kind of system participant. It has to hold state across a work session that may span hours or days. It has to decide what to do next based on context that evolves. It has to act on systems, not just advise users. It has to recover when something fails halfway through. It has to ask for permission before taking consequential actions and explain what it did afterward. It has to know the boundaries of what it is allowed to touch and respect them reliably.
None of that is a UI enhancement. None of it is an additional workflow you can configure in an existing process engine. It is a platform behavior change. The platform itself has to become something different: less a database of records waiting to be accessed by humans, and more a workspace where work is actively in progress, context is live, and machine participation is a first-class mode of operation.
This is the distinction most PLM vendors are blurring right now. They are using the word “agent” to describe what is functionally a copilot, because agent sounds more transformative in a product pitch. But the underlying architecture has not changed, and neither have the workflows.
That second part matters more than it might seem. Existing PLM platforms are built around prescribed workflows designed for human interaction with data. A human opens a change request, fills in fields, attaches documents, submits for approval, waits for a response, and moves to the next step. The workflow was designed assuming a person is driving every stage. It was designed assuming someone reads the screen, interprets the context, and decides what to do next.
An AI agent does not fit into that model. It does not wait at a form. It does not follow a prescribed sequence of human handoffs. It holds state, evaluates context, decides, acts, recovers from failure, and coordinates across systems — often across steps that the existing workflow engine never anticipated and was never designed to support. Dropping an agent into a workflow built for human screen interaction does not make the workflow intelligent. It creates friction, brittleness, and gaps that the agent has to work around rather than through.
Building for real agents means rethinking what the platform is for. It means treating the live state of work in progress as the center of the system rather than the approved record, and it means redesigning workflows not as prescribed human interaction paths but as adaptive, machine-participable processes where agents are first-class participants from the start. I explored this tension in depth in PLM’s OpenClaw Moment: How AI Agents Will Break Closed Systems — the question is not whether agents can query PLM data, but whether PLM systems can provide the kind of open, structured, relationship-aware context that agents need to do real work.
Why Legacy PLM Data Models Are Not Ready for AI Agents
Legacy PLM systems organize product knowledge around files, revisions, approvals, and object tables. That structure was designed for human navigation: an engineer opens a part, checks the revision, reviews the BOM, follows the change order. The information exists in discrete records that humans know how to interpret from experience and context they carry in their heads.
An AI agent cannot operate that way.
An agent needs to know what is authoritative and what is not. It needs to know what changed and why, not just that a new revision exists. It needs to understand what depends on what, so it does not recommend a substitution that breaks a downstream assembly. It needs to know what actions are permitted in the current context, what evidence supports its reasoning, and what should be remembered for the next step in a workflow that may run for days.
But the deeper problem is structural. Most PLM data models were designed to support granular, transactional operations: create a part, update a field, attach a document, submit a change, release a revision. These are discrete CRUD operations, each one isolated, each one performed by a single human actor at a specific moment in time. The data model was built around that assumption. It was never designed to support the kind of work agents actually do.
An agent does not perform a sequence of isolated transactions. It works across a context that accumulates over time, where multiple actions are in flight simultaneously, where humans and agents are both contributing to the same evolving state. That requires something closer to a workspace than a database of records. A workspace where a change is not a single transaction but a collection of contributions — from engineers, from automated checks, from agents gathering context across CAD, BOM, and ERP — that builds toward a decision rather than recording one that has already been made. Most PLM systems have no native concept of that kind of shared, accumulating, multi-actor work context. And without it, an agent has nowhere to operate except at the edges of the real work.
This maps directly to what I have been developing as the concept of Product Memory. Most PLM systems today capture the outcome of decisions. They record the released revision, the approved BOM, the signed-off change order. What they do not capture is the reasoning that produced those outcomes: the alternatives considered, the constraints that shaped the choice, the assumptions made, the tradeoffs accepted. That context disappears into email threads, meeting notes, and the memories of engineers who may not be on the project next year.
As I argued in PLM Single Source of Truth: Why It Was Never the Final Answer, status is not memory. A system that records what was approved cannot tell you why it was approved, what alternatives were rejected, or what assumptions will break if the context changes. For a human navigating PLM, that loss is frustrating but manageable. For an AI agent, it is disabling. An agent operating without provenance-aware context will be forced to reason over disconnected artifacts and stale records. It may produce plausible outputs. It will not operate reliably. And in engineering and manufacturing, unreliable is not acceptable. A wrong recommendation about a part substitution, a revision change, or an approved deviation has consequences that propagate across organizations and across time.
How File and Object Centric PLM Architecture Blocks AI Agents
I want to be concrete about the gap, because “add AI to PLM” means something different depending on what the architecture underneath actually looks like.
Most existing PLM platforms are file-centric, workflow-centric, and transaction-centric. Files are the primary carriers of product knowledge. Workflows are predefined sequences of human approvals. Transactions are the unit of system interaction: create a part, submit a change, release a revision. That architecture made sense for the problem PLM was originally designed to solve, which was bringing discipline and control to increasingly complex product development processes.
But that same architecture creates a ceiling for AI agents. A file-centric system does not expose the relationships between pieces of knowledge in a form an agent can navigate. A workflow-centric system assumes a human is driving each step and waiting for the next gate to open. A transaction-centric system treats each interaction as isolated, with no persistent understanding of the work context that surrounds it.
What agents need instead is a workspace. Not a database you query and update one record at a time, but an environment where a coherent body of work can accumulate across multiple objects, multiple relationships, and multiple actors over time. A workspace where an engineering change is not a single transaction but a live context: parts being evaluated, relationships being traced, alternatives being compared, constraints being checked, and contributions arriving from both humans and agents working in parallel. A workspace where the system understands that all of these activities belong to the same evolving effort, and maintains that context reliably until the work is ready to be formalized.
Most PLM systems have no native concept of this. They can record the outcome of a change once it is approved. They cannot hold the space where the change is actually being worked out. An agent trying to participate in that environment is constantly working against the grain of how the system was built, forced to simulate workspace behavior on top of a platform that was designed for something fundamentally different.
What AI Agents Actually Need from a PLM Platform
Rather than abstract principles, let me translate what production AI systems actually need into PLM-specific terms, using the architectural patterns the Claude Code analysis made visible.
Session persistence in PLM terms means persistent engineering and change work context. An agent working on an engineering change needs to carry the full context of that change across interruptions, across days, and across the contributions of multiple participants. That is not a session cookie. It is a durable, structured representation of work in progress that the agent can resume, inspect, and build on without starting over.
Permission layers in PLM terms mean policy-controlled product actions. An agent must know the difference between reading a released BOM, proposing a vendor substitution, modifying a manufacturing structure, creating a formal change request, and sending instructions downstream to a supplier. These are not the same action. They carry different risk profiles, different authorization requirements, and different consequences if they go wrong. Legacy PLM has role-based access control, but that is a human permission model. An agent permission model has to govern machine participation in live workflows at the level of individual actions, not just screen access.
Workflow idempotency in PLM terms means reliable long-running engineering changes. A change that touches multiple systems, multiple parts, multiple disciplines, and multiple approvers cannot be treated as a single transaction. If an agent is coordinating that change and something fails partway through, the system has to be able to recover to a known state without corrupting what was already completed. Most PLM workflow engines were not designed for that. They were designed for human-driven sequential approval, not machine-coordinated long-running execution with safe recovery semantics.
Provenance-aware memory in PLM terms means trusted product memory. This is the concept I keep returning to because I think it is the deepest architectural gap. An agent needs to know not just what information exists in the system, but where it came from, how current it is, whether it has been validated, and how it relates to adjacent information. A part record in a PLM database tells you the part number, the revision, and the approval status. It does not tell you why this design was chosen over alternatives, what supplier constraints shaped the decision, or what assumptions will break if the design context changes. That missing layer is what Product Memory is meant to address. I explored the foundations of this in What It Takes to Build a PLM Brain: From Product Data to Enterprise Product Memory and in AI Harness for PLM and Manufacturing: Files, Workflows, or Product Memory? — the harness architecture matters as much as the model, and PLM systems have not been designed as agent harnesses.
A tool registry in PLM terms means a safe action model across CAD, BOM, ERP, and supply chain systems. An agent operating across the full product lifecycle needs to know what systems it can interact with, what operations each system supports, and under what conditions those operations are permitted. Today, integrations between PLM, ERP, CAD, and supply chain systems are mostly point connections built for human-initiated synchronization. They were not designed for continuous machine participation. An agent-safe action model means making those capabilities explicit, bounded, and auditable.
Event logging in PLM terms means explainability and compliance. When an AI agent participates in a decision, changes a record, or coordinates a workflow, it is not enough to know what changed. The system needs to capture what the agent saw, what it considered, what policy path it followed, what tools it invoked, and why it stopped or escalated. In regulated industries, that is not optional. Explainability is part of operational trust. An agent that cannot account for its own actions is not deployable in a serious engineering environment.
Why Legacy PLM Was Not Built for Agentic AI
The reason most PLM platforms cannot simply evolve into agent platforms through incremental updates is that their core architectural assumptions run in the opposite direction from what agents need.
Legacy PLM was optimized for object records, not workspace and memory. The system captures approved states of discrete objects: a part at a specific revision, a BOM at a specific release, a document at a specific lifecycle state. Each object is a record. Each record is a snapshot. The system was designed to manage those snapshots with precision and control, and it does that well. What it was never designed to do is maintain the living context that surrounds those objects: the work in progress, the relationships under evaluation, the decisions being considered, the reasoning that connects one object to another. An agent does not need a better way to query approved records. It needs a workspace where product knowledge is active, connected, and accumulating — and a memory layer that carries the context of that work forward rather than discarding it the moment a transaction closes.
It was optimized for approvals, not exploration. The workflow engine was designed to move decisions through gates toward release. An agent needs to participate in the exploratory work that happens before a decision is ready to be formalized, which is territory most PLM systems treat as outside their scope.
It was optimized for transactions, not stateful agents. Every interaction with a traditional PLM system is essentially an isolated operation: fetch this record, update this field, submit this form. An agent needs continuity. It needs to accumulate context across many interactions and use that context to inform what it does next.
It was optimized for modules, not context graphs. Legacy PLM organizes product knowledge into separate functional areas: CAD management, BOM management, change management, document management. Those modules do not naturally expose the relationships between pieces of knowledge in a form an agent can traverse. A context graph would let an agent follow a dependency from a design decision to a part to a supplier to a risk flag to a pending change. A modular database makes that kind of traversal slow, brittle, and often impossible without custom integration work.
It was optimized for human screens, not machine reasoning. The primary interface assumption of most PLM systems is that a trained human will open a UI, navigate to a record, interpret what they see, and take an action. APIs exist, but they are often afterthoughts built to mirror the human workflow rather than to expose product knowledge in a form machines can reason over efficiently.
PLM Re-Architecture: What Needs to Change
If PLM is going to support real agents, the platforms need to be rethought around a different set of foundational capabilities. This is not a feature roadmap. It is a different architecture.
A workspace and product memory layer is the starting point. Not a database of objects with granular CRUD operators, but an environment where product knowledge is active, connected, and maintained across the full arc of the work — from early exploration through formal release. The workspace is where humans and agents collaborate on changes before they are ready to be approved. The product memory layer is what makes that workspace trustworthy: a continuously maintained, provenance-aware representation of product knowledge that an agent can reason over rather than just retrieve from. This layer carries not just the what but the why, the when, the who, and the confidence level behind every piece of information. It is the difference between a PLM system that stores the outcomes of decisions and one that supports the reasoning that produces them. Without both of these foundations in place, everything else built on top — the agents, the assistants, the AI-generated recommendations — will be operating without the ground beneath their feet. I have written about this foundational shift in Product Memory Is the New Enterprise PLM Strategy and in Product Memory for PLM: Building Agentic AI in Reverse.
Graph and relationship-aware context is what makes that memory navigable. Product knowledge is inherently relational. Parts depend on other parts. Designs encode constraints from requirements. Manufacturing structures reflect decisions made in engineering. Supplier selections carry risk context. A flat record store cannot expose those relationships in a form agents can use. A graph-aware context model can.
Agent-safe permission and policy models replace role-based access with action-level governance. The system needs to know not just who is allowed to open a screen, but what actions a machine participant is authorized to perform, under what conditions, with what escalation paths when authorization is unclear. This is a new kind of infrastructure that most PLM platforms do not have today.
Event-driven architecture replaces the transaction-and-poll model with a continuous stream of typed system events. When an agent is coordinating work across multiple systems, it needs to know what is happening in real time, not just what was recorded after the fact. Event streams also provide the observability layer that makes agent behavior auditable and explainable.
Workspace-before-approval changes the center of gravity of the system. Instead of treating the approved record as the primary artifact, a workspace-first architecture treats the live context of work in progress as the primary artifact. Changes are explored, coordinated, and validated in a workspace before they are submitted for formal approval. That is where agents actually add value: not in the approval pipeline, but in the exploratory and coordination work that happens upstream of it.
APIs and services designed for machine participation means rebuilding integration surfaces not as bridges between human-facing systems, but as first-class interfaces for agent interaction. That means structured, semantically rich, action-oriented services rather than CRUD endpoints that mirror the human UI. It means making product knowledge accessible in forms that agents can consume without extensive prompt engineering to compensate for poorly structured data.
Conclusion: From PLM System of Record to AI-Native Product Workspace
The Claude Code leak was not primarily a story about Anthropic’s unreleased features. It was an accidental demonstration that production AI systems are operational architectures, not smart models with interfaces attached.
PLM is heading toward the same reckoning. The current strategy of adding AI to existing platforms preserves the architecture while expecting new behavior from it. But the architectural assumptions of legacy PLM — records over memory, approvals over exploration, transactions over stateful agents, modules over context graphs, human screens over machine reasoning — are not neutral. They actively resist what agents need.
The vendors and teams that recognize this now will not be building PLM with AI added on top. They will be building a different kind of platform: one where product memory, agent-safe policy, event-driven context, and workspace-first change management are foundational, not features.
Let me be direct about what this means for everyone else. Current PLM platforms will remain what they are. The underlying object models, the transaction-centric data architecture, the prescribed human-driven workflows, the file and revision vaults — none of that changes because a vendor adds a chat interface or rebrands their search as an AI assistant. Calling an existing PLM platform “agentic” or “intelligent” without changing the architecture underneath is marketing, not engineering. The system is still organized around records and approvals. The agent, if there is one, is still a guest operating at the edges of a platform that was never built to support it.
This is not an upgrade path. It is a re-architecture. And that distinction matters enormously for anyone evaluating PLM platforms today. If you are making decisions about PLM investments and the conversation stays at the level of AI features, copilot capabilities, and assistant integrations without anyone talking about workspace models, product memory, agent permission frameworks, and event-driven architecture — you are being misled. The architectural questions are the ones that will determine whether the platform you choose can support the way product development actually works in five years. The marketing questions are the ones that will make the demo look impressive next quarter.
The sooner that conversation becomes honest, the sooner the industry can start building systems that will actually work.
Just my thoughts…
Best, Oleg
Disclaimer: I’m the co-founder and CEO of OpenBOM, a collaborative digital thread platform that helps engineering and manufacturing teams work with connected, structured product data, increasingly augmented by AI-powered automation and insights.
