The Context Layer That Makes AI Agents Useful in Engineering
Every new AI agent session starts from zero. LLMs are powerful reasoning engines, but by default they don’t remember your product. Every prompt begins with whatever context you provide at that moment.
No memory of the last task. No awareness of the constraints already agreed. No understanding of why the last decision was made. Someone has to fill that gap and that someone is always a person, explaining the same context they explained yesterday, and the day before, and the day before that.
This is not a limitation of any particular AI model. It is a structural problem. And understanding it is the key to understanding what Product Memory is, why it matters, and why it is becoming one of the most important architectural questions in engineering and manufacturing.
The AI Agent Harness: Why the Model Is Not the Product
Over the past two years, most discussions about AI have focused on models. Which model is better? GPT or Claude? Gemini or something else? Benchmarks, reasoning scores, token costs.
But if you look a bit deeper, something more interesting emerges.
The model is only the brain. What actually determines how useful AI becomes in real work is the environment built around it. This environment — what practitioners are now calling the AI harness — includes the systems the model can access, the data it can see, the tools it can operate, and the memory it can accumulate over time.
Nate B. Jones made this point sharply in a recent analysis of AI agents and their plugin architecture. He demonstrated that the same model, with identical weights and identical training, produced dramatically different results depending on the harness where it ran. In one environment it scored around 78%. In another, the same model dropped to 42%. Not because the model changed. Because the environment changed.
The harness is the structured environment you build around an AI agent so it can do real, repeatable work — not just answer one-off questions. Understanding its layers is essential for anyone thinking seriously about AI in engineering.
I created a diagram that gives you a perspective on the components of the AI agent / plug-in architecture Nate described. This is not PLM, but rather a growing architectural pattern for building AI agents. Think historically about SQL architectures, client-server architectures, microservices, and similar shifts.
Nate identifies five components that make up an effective harness, each serving a distinct purpose:
The prompt is the simplest unit — a one-off instruction for a single, specific, non-repeating task. Most people start here, and many never leave. The problem is that prompts carry nothing with them. No tools, no permissions, no connectors, no memory of previous sessions. If you find yourself typing the same instructions more than twice, a prompt is not the right home for that knowledge.
The skill is where reusable process lives. A skill is a clear document — often just a structured markdown file — that teaches the agent how to do a specific kind of work your way. Your team’s approach to reviewing a BOM. Your standard for writing an engineering change description. Your process for evaluating a supplier substitution. A skill is invoked again and again, across the whole team, with any agent tool. It is the encoded knowledge of how work gets done, made inheritable rather than re-explained each session.
The MCP connector (Model Context Protocol) is the plug that gives the agent access to live data in external systems. Without a connector, the agent only knows what you paste into the conversation. With one, it can reach into a PLM database, an ERP record, a supplier portal, or a BOM management platform and pull real, current data. Many enterprise tools now expose their own MCP connections. The connector is not a workflow — it is the live data pipe that a workflow draws from.
Hooks and scripts handle the parts of a workflow where the model’s judgment should never be trusted alone. If a schema must be valid before it is committed, validate it with a script — do not ask the model to imagine doing so. If a check must pass before the output reaches a human reviewer, enforce it mechanically. Hooks and scripts are deterministic: the same input always produces the same result. They are the quality gates and compliance checks of the harness, and they run whether or not the model remembers to apply them.
The plugin is the full harness assembled into one installable unit. It wraps skills, connectors, hooks, scripts, prompts, commands, and assets into a named workflow that any team member can install without manually reconstructing the setup. A plugin has a job — a bounded, repeatable unit of work — and it packages everything needed to do that job reliably. The key insight Nate emphasizes is that real work rarely lives inside a single prompt. It lives in the connectors that pull live data, the skills that define how to process it, and the scripts that verify the result before it reaches a human. A plugin is all of that, packaged, shareable, and repeatable across sessions and team members.
At the base of all of this sits the LLM — the model itself. It is intelligent, capable, and increasingly powerful. But it is also context-blind without the harness around it. Each session starts from zero. The model has no memory of previous work, no awareness of your team’s standards, no understanding of why a previous decision was made. The harness is what changes that. It is what makes the agent’s work inheritable rather than reconstructed from scratch every time someone needs to get something done.
The key insight that follows from this architecture: the bottleneck is no longer the model’s intelligence. It is whether the context is organized well enough for the model to inherit and use. When the workflow lives only in a human’s head — when someone has to explain standards, sources, constraints, and failure modes every time a new session starts — the human becomes the operating system. The agent is powerful, but permanently dependent.
This is the problem the harness is designed to solve. Not by making the model smarter, but by making the context inheritable.
Four AI Harness Architectures for Engineering: From Tool-Centric to Product Memory
For all PLM developers, implementers, and consulting – this is a moment which is very important. If harness design already matters enormously in simple examples, it matters even more in engineering, where context is far more complex and decisions unfold across long product lifecycles.
That led me to ask a question I think is largely missing from current discussions: not how to build AI-native PLM, but which AI harness should engineering organizations actually build around?
In an earlier Beyond PLM analysis – AI Harness for PLM and Manufacturing: Files, Workflows, or Product Memory on this topic, I identified four distinct harness architectures that represent both the current landscape and a natural progression of how engineering organizations are connecting AI to product work.
The tool-centric harness is where most engineering AI lives today. AI is embedded inside a single application — a CAD design assistant, a PLM chatbot, an ERP suggestion engine. The assistant sees only what that tool sees and helps users operate it more efficiently. Every PLM vendor’s current AI offering lives here. It delivers real quick wins, but the intelligence remains local. Products do not exist inside one tool, which means tool-centric AI can only ever understand a fragment of the product.
The file-centric harness is the next step. AI operates on the artifacts engineers already produce — CAD exports, drawings, specifications, BOMs in spreadsheets, PDFs, and documents. This approach is easy to adopt because it aligns with how many engineering organizations already store information. No infrastructure change required. But files are snapshots. They capture outputs of engineering work rather than the relationships that define the product. When AI operates only on files, it must reconstruct those relationships every time — and often guesses.
The workflow-centric harness is stronger because it connects AI to the processes that govern engineering activity — change requests, release approvals, compliance checks, impact analysis. This allows AI to help coordinate work across teams and identify dependencies between changes. But workflow-centric systems still rely on the quality of the underlying data. Workflows improve coordination. They do not provide product understanding.
The product memory harness is where the progression leads. In this architecture, AI operates on a persistent, connected representation of the product and its lifecycle relationships — structures, revisions, decisions, dependencies, and the reasoning that links them. The agent no longer needs to infer relationships between artifacts because those relationships already exist. It can help engineers understand consequences: what components are affected by a design change, which suppliers are exposed to a revision update, how a modification propagates through manufacturing configurations.
This is where AI moves from answering questions to understanding the product.
Looking at this progression, something becomes clear. The first three harness types are where most engineering organizations are experimenting today, and they deliver genuine value. But each one hits the same ceiling — the absence of a persistent, connected product context layer. The tool-centric harness is siloed by the boundary of the application. The file-centric harness is limited by what files can express. The workflow-centric harness moves information through a process without making it understandable. All three are, in a sense, working around the missing layer.
AI Scaffolding in Engineering Example
Benedict Smith, an AI researcher and former PLM expert, published a detailed analysis of what he calls “scaffolding systems” in his newsletter. He explained the structured frameworks with examples applied to engineering, CAD, and PLM demonstrating what he is building around AI assistants to compensate for their known limitations.
His description of the problem is precise. Large language models have no persistent memory. Each response is generated fresh, conditioned on whatever happens to be in the context window at that moment. For self-contained tasks, this does not matter. For complex work that unfolds over hours, days, or months, the kind of work engineering actually requires – it is debilitating.
The scaffolding patterns Benedict identifies is a good example how to answer to this problem. He describes five: context engineering, where structured project files are loaded fresh into each agent session to provide consistent foundational information; task decomposition, where complex workflows are broken into atomic units each completable in a single AI interaction; structured prompting, where explicit formats reduce ambiguity and improve consistency; sub-agent execution, where fresh AI instances handle each discrete task rather than letting context degrade across a long session; and atomic commits, where AI outputs are captured as discrete, versioned artifacts that can be reviewed, approved, or rejected independently.
These patterns are, in Nate’s vocabulary, a harness built by hand from first principles. I can see how the approach used by Benedict can expand and be adopted by PLM service providers and implementers as they adopt AI technologies and work with customers.
What makes Benedict’s analysis particularly useful here is that he names the limit of his own system. When engineering work is distributed across dozens or hundreds of repositories such as CAD code in one place, simulation results in another, supplier qualification notes in a third, change history in a fourth, the work becomes searchable but not understandable. Traditional search finds documents. Engineering requires causal chains.
He writes: “Why is this flange dimension 5mm?” Keyword search returns forty-seven documents mentioning flange and 5mm. What you need is the specific reasoning – vibration analysis identified resonance at 3mm, which necessitated reinforcement, which drove the 5mm specification to satisfy a damping requirement from the customer’s operating environment. That causal chain spans multiple repositories, multiple commits, multiple decision points. No amount of scaffolding retrieves it automatically.
Benedict’s answer to this is a Context Graph – a system that stores not just facts but decision lineage: why something changed, who changed it, what constraint drove the decision. He describes it as the layer that provides “epistemic glue” between distributed engineering work. And he acknowledges it directly: this layer is emerging, not mature.
His scaffolding patterns are great examples and direct to the absent layer in existing systems. To me it is an evidence that the solution is needed.
Every Product Already Has a Memory — It’s Just Not Organized
Every product has a memory. In my earlier article I went back to my childhood experiencing the work engineers did with drawing boards and human interaction before computers, CAD and PDM/PLM software existed. Check it here – Before Software: How Engineering Was Always a Human Memory System.
Fast forward to our days. The problem is that most companies do not manage product as a memory. They manage CAD files. They manage drawings. They manage BOMs. They manage revisions, change orders, ERP transactions, and supplier records. But the actual memory of the product — why decisions were made, how alternatives were considered, what trade-offs shaped the design, and how the product evolved over time — is usually scattered.
Some of it is in PLM. Some are in ERP. Some are in Excel. Some are in emails, Slack messages, meeting notes, supplier quotes, and PDFs. A lot of it exists only in the heads of experienced engineers who were present when the decisions were made.
For many years, this fragmentation was painful but manageable. Companies compensated with experienced engineers, tribal knowledge, document reviews, and manual coordination. When a new engineer joined a project, someone explained the history. When procurement evaluated a supplier substitution, someone explained what had been tried before. When manufacturing reviewed a design change, someone explained which parts of the EBOM mattered for the MBOM. When service investigated a field issue, someone explained which design assumption may have failed.
In every one of these situations, the product memory existed. It simply was not organized as memory. It had to be reconstructed manually, every time.
That reconstruction is expensive. It slows down people. It creates dependency on experts. It increases the risk of decisions made without full context. And it is exactly the problem Benedict’s scaffolding tries to solve at the individual workflow level.
AI agents make the absence of organized product context architecturally expensive in a new way. When an AI agent is asked to review a BOM, prepare an ECO, assess supplier impact, or validate a product release, it needs more than files and records. It needs context. Without it, the agent produces answers that look confident but miss the real product meaning. And someone — always a person — has to fill the gap by loading context manually into each new session.
This is the product equivalent of the human becoming the operating system.
From CAD Files to Product Memory: The Evolution of Product Data in Engineering
The history of engineering software is a gradual expansion of what we consider product data.
At the beginning, the product was mostly represented by drawings and CAD files. PDM systems emerged to manage those files: versions, check-in and check-out, vaults, permissions, and release packages. This made sense when mechanical design dominated the product definition and the primary challenge was controlling documents.
PLM expanded the scope. It introduced items, BOMs, lifecycle states, workflows, change orders, approvals, and cross-functional processes. PLM helped companies formalize product development and manage the official state of product information.
The Digital Thread was an important further step. It recognized that product information does not live in one place and attempted to connect requirements, design, manufacturing, quality, service, and operations into a continuous thread of traceable data.
Each step added something real. But at every stage, the same layer was missing.
Digital Thread connects data. Product Memory explains data.
It is not enough to know that a part changed. We need to know why it changed. It is not enough to know that a supplier was replaced. We need to know what risk, cost, availability, or compliance issue drove the decision. It is not enough to see an EBOM and an MBOM relationship. We need to understand the assumptions and trade-offs that shaped the transformation from engineering design to manufacturing reality.
This is the move from product records to product memory.
PLM Remembers What Was Approved. Product Memory Remembers How the Product Became What It Is
Traditional PLM systems are very good at capturing formal outcomes. They can tell us which revision was released, which ECO was approved, who signed off, and what lifecycle state an item currently holds.
But product development is not only a sequence of formal approvals. A large part of product knowledge is created before and around the approval event.
Why was this part selected over the alternatives? Why was this material changed? Why did engineering accept this manufacturing constraint? Why was this alternate component approved? Why was a design simplified at this point in the program? Why was this supplier rejected? Why was this requirement interpreted the way it was?
Most of these answers are not stored as structured product memory. They are buried in comments, meeting notes, emails, documents, or simply remembered by the people who were there. When those people leave, the memory leaves with them.
This is the distinction that matters:
PLM remembers what was approved. Product Memory remembers how the product became what it is.
This does not mean PLM is wrong or obsolete. It means the next layer of value is not only managing states and approvals. The next layer is preserving the context that makes those states understandable — to the next engineer, the next supplier, the next audit, and the next AI agent.
What Product Memory Stores: A Definition Built for AI-Native Engineering
Product Memory is a persistent, connected, and explainable layer of product context. It captures not only product data – parts, BOMs, files, revisions, suppliers, and changes, but also the relationships, decisions, rationale, assumptions, and history that explain how a product evolved over time.
Stated more simply: Product Memory is the organized memory of how a product came to be, how it is changing, and why those changes matter.
It is important to be precise about what Product Memory is not. It is not another database. It is not a new version of “single source of truth.” The future of product development is not one giant system that absorbs everything. Products are too complex. Organizations are too distributed. Engineering, manufacturing, procurement, service, and suppliers all use different systems for legitimate reasons.
CAD remains CAD. ERP remains ERP. PLM and PDM may remain in place. Excel may continue to exist in parts of the workflow. The problem is not that these systems exist. The problem is that the context between them is weak, fragmented, and often invisible.
Product Memory is a connected memory layer across these systems. It does not replace every source of truth. It organizes context across many sources of truth — in the same way that a search engine does not replace the web but makes it findable, connected, and usable.
The architectural positioning matters. Product Memory is a PLM concept — it lives in the product development domain and addresses a product development problem. But it is designed using the same principles that AI-agent harness architecture has identified as essential for any system where AI does real, complex, consequential work: persistent context, structured rationale, connected relationships, and agent-ready packaging.
Concretely, Product Memory stores several classes of context working together:
Product identity captures parts, assemblies, files, drawings, requirements, specifications, suppliers, and documents — the foundational objects of the product.
Product structure captures EBOMs, MBOMs, SBOMs, service BOMs, configurations, alternates, substitutes, and system-level relationships — how components connect and depend on each other across different views of the product.
Change history captures what changed, when it changed, who changed it, and what previous state it came from — the traceable record of product evolution.
Decision rationale captures why a change was made, what alternatives were considered, what trade-offs existed, and what constraints drove the outcome. This is the layer that PLM has historically underserved. It is also the layer Benedict calls the Context Graph and identifies as the essential missing piece in AI-assisted engineering workflows.
Operational context connects engineering decisions to cost, availability, lead time, quality, compliance, and serviceability — because a product is not only designed but purchased, manufactured, assembled, shipped, maintained, and eventually retired.
Verification context captures what was checked, what failed, what passed, and what remains uncertain — the state of confidence in the product at any given moment.
Agent context packages all of the above in a form that AI agents can load, interpret, and act on reliably. An agent cannot safely review a BOM or recommend an ECO based only on a table of numbers. It needs to know what the BOM means, what state it is in, what assumptions are valid, what rules apply, and what checks must pass before any action is trusted.
Product Memory as the Context Layer for Engineering AI Agents
Returning to the harness architecture: the harness works when it has something meaningful to load. Skills are only as useful as the knowledge they encode. Connectors are only as useful as the data they reach. Context engineering — Benedict’s first and most fundamental scaffolding pattern — is only as useful as the context that has been organized and preserved.
Product Memory is what the engineering AI harness loads.
It is the persistent context layer that allows an agent to inherit product understanding rather than reconstruct it. And it transforms what each type of AI task can actually accomplish.
An AI agent reviewing a BOM needs to understand the product structure, the release state, the sourcing strategy, the required attributes, the downstream ERP expectations, and the applicable change rules. With Product Memory, that context is available at the start of the session. Without it, a human must provide it manually — or the agent works with an incomplete picture.
An AI agent preparing an ECO needs to understand not only what changed, but why it changed, what else might be affected, which downstream systems need to be updated, and what approval process applies. With Product Memory, the rationale and impact relationships already exist. Without it, the agent is guessing about the consequences.
An AI agent supporting procurement needs to understand approved suppliers, qualified alternates, lead times, compliance risks, and the history of previous sourcing decisions for this part family. With Product Memory, that operational context is structured and accessible. Without it, someone has to reconstruct it from emails and spreadsheets.
An AI agent helping manufacturing needs to understand the relationship between the EBOM and the MBOM, the process plan assumptions, the production constraints, and the history of manufacturing feedback on similar designs. With Product Memory, those relationships exist as structured data. Without it, the manufacturing engineer becomes the context layer — manually.
In each case, Product Memory is not just helpful. It is the difference between an AI agent that can be trusted to participate in consequential engineering decisions and one that produces plausible-sounding answers that require exhaustive human verification.
This is also what shifts the human role. Product Memory does not remove people from product development. It removes the need for experts to repeat themselves. Engineers stop spending their time reconstructing and re-explaining context that already exists somewhere — in someone’s head, in an old email thread, in a meeting note from two years ago. They start governing the memory layer instead: defining it, reviewing it, improving it, and ensuring it remains accurate as the product evolves.
The goal is not an autonomous PLM. The goal is explainable product work — product decisions that are understandable to the next person, the next team, the next supplier, and the next AI agent that needs to act on them.
Why Product Memory Matters Now: Three Forces Changing Engineering AI
Product Memory is not a new idea. Engineering organizations have always needed to preserve product reasoning. The challenge has always been that the tools available – PLM systems, document repositories, email archives were not designed to organize context as a first-class concern. They were designed to manage states, control documents, and enforce processes.
Three things are happening simultaneously that make the problem urgent in a new way.
Products are becoming more complex. Mechanical, electronic, software, firmware, cloud, supplier, and service data are increasingly intertwined in ways that no single system captures. The product is no longer a file. It is a changing network of decisions, dependencies, and representations.
Organizations are becoming more distributed. Product work spans teams, systems, geographies, contractors, and supply chains. Context that once lived in a team meeting now needs to be accessible across time zones, organizational boundaries, and partner companies.
AI agents are becoming capable enough to participate in real engineering and manufacturing workflows, but only when the context is organized. The limitation is not the model. It is the harness. And the harness is only as powerful as the product memory it loads.
This is also the observation Benedict makes from the scaffolding perspective, and it is the observation implicit in every tool-centric, file-centric, and workflow-centric harness that hits its ceiling: the missing layer is not a better tool, a better file format, or a better workflow. The missing layer is organized product context that persists across sessions, systems, people, and time.
PDM was designed for files. PLM was designed for lifecycle control. Digital Thread was designed for connection. Product Memory is designed for context and reasoning.
Product Memory in Practice – Emerging AI Stack
This architecture is not only theoretical. The pattern is already being built — from different directions, by different practitioners, arriving at the same structural conclusion.
Benedict’s scaffolding examples shows what practitioners can construct from project files maintained, additional context, structured prompts for specific tasks, outputs committed as discrete artifacts. This is strong evidence that the solution is needed in this space.
A complementary perspective comes from Adam Keating – CEO of CoLab, whose analysis of the emerging AI stack for industrial companies describes the same architecture from the top down. Rather than a single AI system replacing existing tools, Adam argues that the future will be built from dozens of specialized AI agents working together organized around four layers: AI agents that bring specific capabilities, product and knowledge data sources, an orchestration layer that coordinates agents, and a human interface where people collaborate to make decisions. Product memory is the data layer in these solutions that makes this stack coherent. Without it, each agent operates in isolation. With it, agents get a context to understand the product they are acting on.
This four-layer architecture maps cleanly onto the harness concept. The agents are the skills and connectors. The orchestration layer is the plugin and workflow logic. The human interface is the review and approval surface. And the product and knowledge data sources – the layer Adam places at the foundation is precisely what Product Memory provides.
OpenBOM’s Collaborative Workspace is another example of how a product memory harness might look like.Two capabilities illustrate the pattern directly.
CoLab Design Review is a structured engineering review environment where product context such as CAD data, geometry, 3D models, drawings is persistent and shared across all participants. Rather than requiring each reviewer to reconstruct product understanding from scattered files and emails, the context is already organized and present. An AI agent participating in the review inherits the same product context a human reviewer sees, without anyone having to load it manually into a prompt. AutoReview takes this further by running AI-assisted analysis directly against the product memory layer.
At ACE 2026, Aras offered one of the clearest signals yet that established PLM vendors are beginning to architect around the same missing layer. CPO Igal Kaptsan described a dependency graph that captures rich relationship context across the full product lifecycle, naming hidden dependency visibility as one of the largest unaddressed costs in manufacturing. CTO Rob McAveney extended this toward Adaptive PLM — where AI agents are the new user, knowledge graphs are the structural substrate, and the goal shifts from managing data to preserving what he called organizational and product memory. The direction is unambiguous. Whether the execution matches the ambition is what the next product releases will answer. My article about it is here – From Flexible Data Model to Adaptive PLM.
All examples illustrate the same principle – to design the context layer as a first-class concern of the product data environment itself, which is persistent, connected, and accessible to both people and agents as a natural part of how product work gets done.
The broader point is this. The organizations that build their AI harness around product memory concept will be able to connect intelligence directly to the product lifecycle. AI will not only analyze documents or assist inside individual tools. It will help engineers navigate complex product relationships and lifecycle decisions because it will have access to the organized memory that makes those decisions understandable.
And in the long run, that difference will matter far more than which model happened to perform slightly better in the latest benchmark.
Conclusion: The Future of PLM Is Memory, Not Just Data
Here is how the engineering software stack evolved: CAD files, PDM, PLM, Digital Thread, and Product Memory. The future of PLM will not be defined by better workflows, better dashboards, or better integrations. These things matter, but they are not the constraint.
The future will depend on whether companies can preserve and use the memory of their products.
What was decided? Why was it decided? What changed? What was learned? What context must be preserved for the next person, the next team, the next supplier, or the next AI agent?
AI did not make PLM less important. It made product context more important. It showed that managing files, records, and approvals is not enough when people and agents need to reason about complex products over time.
Product Memory is the missing context layer between CAD files, PLM records, digital threads, and AI agents. It is the harness layer that engineering AI has always needed and that AI adoption has finally made impossible to defer.
It is how a product becomes understandable — not only as a set of files and records, but as a living history of decisions, changes, relationships, and meaning.
Just my thoughts…
Best, Oleg
Oleg Shilovitsky is the co-founder and CEO of OpenBOM and the author of the Beyond PLM blog, where he writes about the future of product development, PLM, and manufacturing technology.
