Robert Hauser asks why AI systems keep reconstructing knowledge they have already analyzed. In engineering, the answer depends on where memory comes from and what keeps it accurate.
In his article “What If AI Knew What It Knows?”, Robert Hauser asks a question I keep returning to: why should an AI system repeatedly reconstruct knowledge it has already analyzed?
Robert starts from a recent Netflix Technology Blog post on checking whether synopses of movies and series are factually accurate. As he describes it, the Netflix team replaced a single holistic review with specialized judges and targeted checks of uncertain claims. Robert then takes a step the Netflix post does not take. As a thought experiment, he proposes a persistent memory for each series: shared principles for good synopses, series-level knowledge of characters and chronology, and episode-level detail. That memory is updated as new seasons arrive and checked against original sources when it falls short.
He connects this idea to Product Memory, and he shares some very valuable ideas about what it would take. Stored knowledge needs provenance. Interpretations should not harden into facts. Memory has construction and maintenance costs that must be measured before anyone claims an efficiency gain. I agree with all of it.
I want to add an engineering perspective on one question his architecture raises: where does the memory come from, and what keeps it accurate? A released episode does not change after it airs. A product changes every week. That difference is why I believe Product Memory has to be produced by the same work that uses it.
A released episode stays fixed while a product keeps changing
Once an episode is released, its story is settled. A series memory grows season by season, and earlier facts rarely change. The hard problems are interpretation and timing, which is why his example of a character whose identity is revealed in season four is so useful. The fact is true, but it must not leak into a synopsis of season one.
Engineering has the timing problem too, and a harder one on top of it: the underlying reality moves. Components reach end of life. Suppliers change processes and materials. Requirements are renegotiated with customers. A design approved for one configuration becomes wrong for the next one.
Most engineering decisions are conditional. They hold under assumptions about temperature, volume, supplier, cost, or schedule, and those assumptions can quietly stop holding. Memory in this environment cannot be built once and refreshed at intervals. It has to keep pace with the product, and the only activity that runs at the pace of the product is the engineering work itself.
Current data shows what was decided and rarely shows why or where it applies
A reasonable objection is that agents can query PLM, ERP, and supplier systems at the moment they need something. Why keep a separate memory at all?
Access answers questions about the present: the current BOM, the current supplier, the open change orders. Revision history shows what changed and when. What is kept far less reliably is the reasoning: why a component was selected, which alternatives were rejected, and under what conditions the decision was considered valid. When that reasoning exists, it often lives in free text, email threads, meeting notes, or the memory of the engineer who made the call.
Imagine an agent reviewing BOM history. It finds that a substitute component was approved and used in production. The record is accurate. It is also incomplete in exactly the way that matters, because it shows the approval and hides its boundaries. I will come back to this agent below.
This also changes the cost comparison in his article. For synopses, the original sources remain available, so a system can always reconstruct context from scripts and episodes, at some cost. In engineering, much of the rationale never entered any system. For that part of the context, reconstruction from current data is impossible, however much reasoning we apply. Memory is sometimes the only place where that context exists.
Memory has to be produced by the work that uses it
This is the role I see for the Product Memory flywheel: Capture → Review → Flow. Each stage needs a precise definition, because loose definitions lead to loose claims.
Capture records context where the work produces it. Each piece is linked to the item, revision, configuration, and source record it concerns, and it carries its status at the moment of capture: observed, stated by a supplier, assumed by an engineer, or generated by an AI.
Review is the set of points where context is checked against evidence and its status or scope changes. It can be confirmed, limited, contradicted, or explicitly left open.
Flow delivers results to the next activity in the form that activity needs, keeps the link back to the context and its status, and brings the outcomes of that activity back.
Two clarifications matter. Unreviewed context is still worth keeping, as long as it is labeled for what it is. And memory should hold more than formal decisions. Rejected alternatives, open questions, and “we tried that in 2024 and it failed” are often the most valuable things an organization can retain.
Capture should link what work already produces and record its gaps
The weakest point in any memory architecture is capture. If every engineering activity creates a new documentation task, participation becomes the bottleneck and the memory goes stale within months. Most of us have seen knowledge management programs fail exactly this way.
A large share of useful context is already produced by the work: BOM differences, revision history, change orders, supplier quotes, review comments, and test results. Capturing it is mostly a matter of linking it to the right item and decision. It does not require copying everything into one central database or migrating systems. Product Memory should connect useful subsets of context across existing systems while preserving links to the authoritative records.
A second share is available at decision points people already pass through. When a substitution is filed, the reason can be requested right there, once, while the engineer still remembers it. When an approval is granted, its conditions can be recorded with it. AI can help by drafting that context from the surrounding material for the engineer to confirm or correct. That takes seconds at the moment of the decision and is nearly impossible weeks later.
The third share will not be captured: hallway conversations, tacit judgment, and things people choose not to write down. Memory should record the gap, for example “rationale not recorded; ask the design owner,” instead of filling it. An empty field filled with a plausible interpretation makes the next decision less reliable than a blank record.
Review changes the status and scope of what memory holds
His article makes an observation that engineering teams will recognize immediately: an ambiguous interpretation should not become an established fact simply because an AI agent stored it.
Engineering has many versions of this problem. A supplier’s datasheet claim, an engineer’s assumption, a calculated result, a measured result, and an approved decision carry different kinds of authority. Memory has to keep those distinctions, along with the scope of each conclusion: who approved it, for which revision and configuration, under which conditions, on what evidence, and what remained uncertain.
Most review should happen at gates that already exist, such as change approval, BOM review, and supplier qualification. Adding a separate approval queue for memory would recreate the documentation burden described above.
This is also where persistent memory and specialized reasoning meet. Memory supplies retained context. Reasoning examines whether that context is relevant, sufficient, and still valid for the task at hand. An agent may retrieve the original evidence, identify a contradiction, or request a human decision. Verified results can then return to memory with their new status. A generated conclusion keeps its status until appropriate verification takes place, because repeated use does not make a statement true.
Returning outcomes makes the loop a flywheel, and the same loop can make memory worse
A workflow moves one task to completion. A flywheel changes the starting point of the next task. That difference comes from what returns after the work is done.
In engineering, the returning material is outcomes linked to the decisions they test: a thermal test result attached to the approval that was conditional on it, a field failure attached to the configuration where it occurred, a supplier change notice attached to every place the part was approved, and a rejected AI recommendation stored with the reason it was rejected.
Memory improves under specific conditions. Outcomes have to be linked to a particular item, revision, and decision, and not simply filed in a folder. Status distinctions have to be kept. The next activity has to consult memory before acting. When those conditions hold, review effort per decision should decline over time, because earlier scoped decisions and their evidence become reusable.
The same loop can also degrade memory, and I would rather name the failure modes than pretend the architecture prevents them. Scope gets stripped when context is summarized, leaving “approved” without its conditions. An unverified interpretation gains apparent authority each time it is reused. The underlying record changes while memory does not, as when a supplier change notice never reaches the earlier approvals it affects. Capture grows faster than review, so the reviewed share of memory keeps shrinking. People work around the system, and outcomes never come back.
A flywheel keeps turning whichever way you spin it. That is why Product Memory needs governance as much as it needs capture: explicit status, explicit scope, links to evidence, and someone accountable for noticing when the loop starts running in the wrong direction.
An approval stays with one product while its evidence carries forward
Here is an illustrative case. It is a composite of situations I have seen, not a specific customer story.
A team building Product A needs to ship on time. The specified electrolytic capacitor, rated to 105°C, has a 26-week lead time. Procurement finds an 85°C part from another supplier that is available now. The design engineer checks the thermal analysis, sees that the board runs below 70°C, and approves the substitute for revision C. The approval is limited to the first 500 units, pending a thermal test on production hardware.
The BOM is updated, the order is placed, and the units ship.
Six weeks later, the thermal test comes back. The capacitor stays within its rating, but the margin is thinner than the analysis predicted: 78°C at the hottest point under maximum load. The engineer extends the approval to all revision C units and records the measured value.
Six months later, the agent from earlier is helping with Product B and looks for available alternatives to the same 105°C capacitor. The BOM history shows that the substitute was approved and used. If that is all the agent can see, recommending it looks reasonable.
With the retained context, the agent sees more. The approval applied to Product A, revision C. It depended on a board temperature first estimated below 70°C and later measured at 78°C. Product B is specified for 95°C operation. The agent should report that the earlier approval does not apply and that Product B needs its own review.
The useful part comes next. The thermal data, the supplier datasheet, and the derating reasoning from Product A are still relevant evidence for that review. The approval stays with Product A, and its evidence gives the Product B review a head start.
Each stage of the loop did its part. Capture linked the substitution to its reasons and conditions. Review set its scope and later revised it. Flow brought the test result back, so the memory improved before anyone needed it.
Robert’s experiment can be run on engineering history
Robert proposes a fair test for his domain: compare a reasoning-first cascade with a memory-first cascade on the same expert-annotated dataset, and measure accuracy, alignment with human reasoning, latency, and total lifecycle cost, including building and maintaining the memory. He is right that the advantage needs to be demonstrated, not assumed.
Engineering has a natural dataset for the same experiment: its own history. Take a year of closed change requests and component substitutions. Replay them with two agents. The first has access to current systems only. The second also has retained context with status and scope. Score both against what engineers actually decided and why.
I would measure three things beyond accuracy: how often an earlier decision is applied outside its original conditions, how long it takes to explain a past decision to someone who was not there, and how much review time each new decision requires. The cost side has to include the time spent answering capture prompts, reviewing context, and maintaining links when records change.
My expectation is that retained context pays off most where the same parts, suppliers, and design patterns recur across products, and least for one-off work. That is a hypothesis, and an experiment like this is how we would find out.
Every engineering task should end by asking what context remains
The article that started this discussion asks how AI can know what it knows, recognize what it does not know, and preserve what is worth remembering. Engineering makes that question harder because the product keeps changing underneath the memory.
The Product Memory flywheel is my answer to how memory can keep up. It works only when ordinary engineering activities leave context behind, when review sets and revises its scope, and when outcomes return to the decisions they test.
So the question I would ask at the end of every task, by a person or an agent, is simple. What useful context remains? Can the next person or agent verify it, understand its limits, and build on it?
Best, Oleg
Disclosure: I am 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.
Acknowledgment: This article builds on Dr. Robert Hauser’s “What If AI Knew What It Knows?” (November 13, 2026). His persistent domain memory proposal is an independent architectural thought experiment inspired by Netflix’s published synopsis factuality work. It does not describe an existing Netflix implementation. The substitute-component case above is an illustrative composite.
