AI Agents Need a Product Context Graph, Not a Pipeline

Review builds context. Agents put it to work. Decisions write it back. Why AI agents in manufacturing need a Product Context Graph, and how OpenBOM BOM Review and Launch Master turn it into a flywheel.

Earlier this summer Mark Burhop published an essay asking who will control AI-native engineering. It is one of the clearest maps I have seen of where AI is taking engineering software. His argument is that foundation models are moving the center of gravity above CAD, CAE, and PLM applications. For decades the application owned the interface, the model state, and the customer relationship. Now an engineer can describe an objective instead of selecting a command, and an agent can plan the work, call the tools, check the results, and come back with a recommendation. The strategic question, Mark writes, is “which system receives the engineer’s intent first,” because that system becomes the control plane for engineering. He then walks through four very different bets on owning it, from Microsoft, Anthropic, NVIDIA, and Meta.

I agree with most of his map. But I wanted to share one observation. Mark points out that the control plane could accumulate a history of engineering intentions and decisions that may be more valuable than the final geometry. Later, in his advice to manufacturers, he warns that an agent cannot recover context the organization never recorded, and that companies should keep their engineering memory independent of whichever model is in fashion.

Put those observations side by side and a second question appears underneath his. Before we ask who controls the agent, we should ask what an agent needs in order to control anything well. My answer is product context, and more specifically a Product Context Graph that is continuously built, checked, and used. A Product Context Graph is the connected record of what a product is, what was decided about it, by whom, and why, across every system and company that touches it. The more interesting question is how that graph gets built, because it does not get built the way most AI architectures assume.

A Data, Agent, Action Pipeline Is Open-Loop Control

Most discussions about AI agents in engineering assume a pipeline. Data goes in, an AI agent reasons over it, and an action comes out. It is easy to draw and easy to demo, and with APIs and MCP servers appearing on more engineering systems every month, it is becoming easy to build.

It is also open-loop control. Mark chose the term control plane deliberately, so let me stay with the metaphor. An open-loop controller acts without measuring the result. Nothing feeds back and nothing corrects the next run. Engineers know what happens to open-loop systems when conditions change. They drift, and nobody notices until something breaks.

That is what happens to an agent that runs as a pipeline. Every time it starts, it reconstructs the product from fragments: a BOM export, a few drawings, a supplier spreadsheet, some email. It has to guess which row is which part and which revision applies. Every time it finishes, what it learned disappears. The next run starts from zero, and so does the next person who needs to know why a decision was made.

Consider a simple question from a program manager: are we ready to build and deliver this product next month? Answering it means knowing which configuration and revision apply, which parts are bought and which are made, what suppliers and contractors committed to, whether a recent engineering change affected those commitments, and what has to happen before final assembly. The answers live in CAD, PDM, ERP, spreadsheets, and conversations. Every one of those systems can be correct, and the company can still miss the date. The problem is not missing data. It is missing context between the data, and a pipeline has nowhere to keep it.

Review Builds Context. Agents Put It to Work. Decisions Write It Back.

The loop we are building at OpenBOM works differently. It has five steps, and the last one feeds the first.

1. Capture. Product data comes in from CAD, spreadsheets, ERP, and suppliers.
2. Review. Checks run against it and produce findings.
3. Reason. Agents work over the connected context against a specific question.
4. Decide. A person who is accountable makes the call.
5. Act. Systems and people carry it out, and the result, whether a corrected BOM, a confirmed supplier date, or an accepted exception, becomes new context for the next turn.

[FIGURE: The Product Memory Flywheel, opened up. Capture, Review, Reason, Decide, and Act around a central Product Context Graph, with an open-loop “Data, Agent, Action” pipeline shown faded beneath it for contrast.]

Look at what is missing from that loop. There is no step called “update the knowledge graph.” Nobody stops working to document anything. Every step writes to the Product Context Graph as a side effect of doing its job. A check that runs leaves a finding. A comment leaves a reason. A task leaves an owner. A re-run leaves proof that the problem is gone. That is why the loop compounds instead of decaying.

What goes into the graph? It starts with the product definition: items, BOMs, CAD models, documents, revisions, and configurations. It adds production reality: suppliers, costs, inventory, orders, lead times, manufacturing operations, and contractors. It adds the work itself: findings, comments, tasks, exceptions, approvals, and the people responsible for them. And it adds time: requested dates, supplier promises, milestones, build quantities, and assembly slots. A graph that tells you what exists is product data. A graph that also tells you what changed, what was decided, who committed to what, and why, is product context. That is also the difference from a classic knowledge graph. A knowledge graph describes how things relate. A Product Context Graph also records what people decided and promised, and it is written by the work itself rather than assembled once by an integration project. Accumulated over the life of a product, that context becomes what I call Product Memory.

If you have followed the OpenBOM Product Memory Flywheel of Capture, Review, and Flow, you will recognize this picture. It is the same flywheel with the Review stage opened up and the graph placed at the hub, where it belongs.

BOM Review Turns the Wheel on the Product Definition

BOM Review is where this wheel turns today. We introduced OpenBOM BOM Review in July as the missing step between creating a BOM and trusting it. The first release shipped four deterministic check cards that every OpenBOM user can run, including trial accounts: property validation, part number validation against your numbering rules, structure validation for circular references, and quantity checks against reference designators. In August we added AI BOM Health, a check card that sends the full hierarchical BOM to a frontier model and reports what looks wrong, including problems nobody wrote a rule for.

The checks are only the entry point. What matters for this argument is what happens after a finding appears. Every finding carries its context and takes you to the exact cell where the problem lives. A person decides whether it deserves a comment, a question, a task with an owner, or nothing at all, because an alert is not a task. When the data is corrected and the check runs again, the finding disappears because the condition that produced it no longer exists. I walked through the details in The Anatomy of a BOM Review Agent.

Now look at that sequence through the lens of the flywheel. A check writes a finding. A comment writes a reason. A task writes an owner. A re-run writes proof. At the end the team has not only a corrected BOM but a record of what was wrong, who looked at it, what they decided, and whether the fix held. That residue is the most valuable output of a BOM review, and nobody had to stop and write it down.

It also matters that a BOM review is not one meeting. It happens at every handoff, from engineering to procurement, from procurement to a supplier, from a supplier to manufacturing. Each group looks at the same product through a different lens, and each handoff is where context usually gets lost. When everyone reviews one BOM in one shared context, the reasons travel with the data instead of staying behind in someone’s inbox.

A Correct BOM Is Not a Deliverable Product

This summer the work on BOM Review pushed us toward a harder problem. Imagine every system is right. CAD says the design is released. The BOM is accurate. Procurement says everything is sourced. ERP holds the purchase orders. And the launch is still at risk, because readiness is not a property stored in any one system. It is a conclusion drawn from the relationships between them. I wrote about this in Is Your BOM Accurate? That May Be the Wrong Question. and Every System Says “Ready.” But Are You Actually Ready to Deliver?

This is also where I want to extend Mark’s map. His most complete example of an agent reads a live assembly, modifies features, runs a solver, updates PLM, and asks for approval before release. That is where his map ends. But a design decision is not verified at release. It is verified when the product ships.

There is a second kind of intent that the control plane debate mostly skips. Mark’s intent is design intent: make this bracket lighter, create a family of connector variants. The intent a launch manager carries is a commitment: this configuration, in this quantity, by this milestone and date. The four strategies Mark describes, and the CAD incumbents defending their ground, are all competing for design intent. Nobody is competing for the commitment. In most companies it lives in a spreadsheet, an email thread, and one person’s head. Design intent has four suitors. Delivery commitments have none.

Launch Master Turns the Same Wheel Backward From a Commitment

Earlier this month I introduced an idea we are exploring under the working name Launch Master Agent. It starts from exactly that commitment and asks what must be true to deliver it.

Every build has to answer six questions: what the parts are, whether they fit together, where they are bought or made, what the lead times are, how they route through the plant, and what happens at each station. A BOM answers the first. CAD answers the second. Sourcing, ERP, routing plans, and process sheets answer the rest. A blocker is an inconsistency between the answers.

Here is the illustrative example from that article, written as a chain:

Module revision → changed interface → harness update → approved drawing → external contractor → contractor lead time → final assembly → integration slot → launch milestone

Nothing in that chain has to be wrong for the launch to fail. CAD can be right. The BOM can be right. The contractor can be following its agreed process. The assembly schedule can be right. What breaks is the path between them. A launch blocker is often not a bad data point. It is a broken path through the Product Context Graph.

That path also crosses company boundaries. Mark describes how Meta built an autonomous assistant into Siemens NX for its own engineers, and it is an impressive example of a manufacturer building its own control plane. But it works inside one company. The harness example involves a module supplier, a harness contractor, and an assembler. An agent built inside one firewall cannot see the contractor’s unanswered question. The context of a delivery is multi-party by nature, which is why it has to live in a shared workspace that several organizations can work in, rather than inside any single company’s stack or any single application.

We already have a small preview of this kind of finding. While we were testing AI BOM Health, the card noticed that a planned build needed four of a part while inventory held two. Nobody had written that rule. The model connected the product structure to the inventory record, two answers to two different questions, and saw that they did not agree. That is a launch blocker in miniature.

So Launch Master turns the same flywheel as BOM Review, from the opposite direction. BOM Review reasons from the product inward and asks whether the product definition is fit for its next handoff. Launch Master reasons backward from the commitment and asks whether every critical path still supports it. It consumes the context that review has built: which revision is valid, which findings were accepted, which supplier data is confirmed. It also writes back. The blocker it raises, the evidence attached to it, the decision to expedite or slip, and the contractor’s confirmed date all become context the next BOM Review will see. When a drawing, a supplier response, or a schedule changes, it should revisit the finding and show whether the issue can close or needs to reopen. Engineering still confirms technical compatibility, and the program manager still owns the delivery decision. A launch review is still a review. It is simply a review of a promise instead of a structure.

I want to be clear about status. BOM Review is shipped and available to every OpenBOM user. Launch Master is an exploration. We are testing which parts of launch coordination can be made repeatable with software and AI, and where judgment has to stay with people.

Every Turn Makes the Next One Smarter

The reason to call this a flywheel rather than a longer pipeline is that each turn makes the next one cheaper and more trustworthy.

On the BOM side, the architecture is designed so that when the AI card keeps surfacing the same meaningful issue and your team confirms it matters, that issue becomes a candidate for a deterministic check card that runs the same way every time. Probabilistic discovery feeds deterministic enforcement. Custom company check cards are how we plan to do that, and we are building them now with design partners. On the launch side, a blocker pattern that recurs across programs would become something the next launch checks on day one.

This also suggests a cleaner way to think about agents. I would define an agent by the question it continuously asks of the Product Context Graph. BOM Review asks whether this product definition is fit for its next handoff. Launch Master asks whether we can still deliver what we promised. A change agent might ask what became invalid because something changed, and a sourcing agent might ask whether every purchased part can still be sourced under current constraints. Those last two are illustrations, not announcements. The point is that the graph is shared, the agents have different missions, and people stay accountable.

It also adds a layer to the architecture Mark draws. At the bottom sit the execution systems, CAD, CAE, ERP, MES, and procurement, each authoritative for what it does. At the top sit the agents. Between them sits a context plane: the connected graph of identity, structure, revisions, decisions, and commitments. A control plane without a persistent context plane is an LLM orchestrating APIs. It can act, but it cannot learn from what happened, and it cannot explain why.

You Own the Product Context Graph. Custody Goes to Whoever Keeps It Turning.

So who will own the Product Context Graph?

For twenty years PLM and ERP vendors argued about who owns the master record. AI agents change that argument. The manufacturer owns its product context, and Mark’s advice to keep engineering memory independent of any model provider points the same way. I have argued before that Product Memory has authority over nothing. CAD owns geometry, ERP owns transactions, MES owns what was actually built. The Product Context Graph does not need to replace systems of record. It needs to connect their truths, keep identities stable across them, and remember what was decided along the way.

The practical question is custody: which system is present, day after day, at the moments when the graph gets written. Those moments are not the prompt. They are the finding someone accepted, the exception approved for the prototype but not for production, the drawing a contractor acknowledged, the supplier date that moved. Custody goes to whoever keeps the flywheel turning.

This is OpenBOM’s position. We believe the BOM and the relationships around it are the natural backbone of that graph, because product identity and structure start there and every downstream organization touches it. BOM Review builds and verifies the graph today. Launch Master is how we are exploring putting it to work against a real commitment. The systems of record stay authoritative. The model stays replaceable. Your data stays reachable through our self-service API. And the graph stays yours.

Mark’s question about who will control AI-native engineering is the right one to ask. I would add one more. Engineering intent eventually has to become a product that someone can build and deliver. The system that connects the two will not be a pipeline. It will be a flywheel, and the companies that start turning it earliest will have the most context when it matters. One of the most important elements that this flywheel delivers is a continuity across multiple organizations. 

Where I Would Like Your Help

If you manage launches or complex deliveries and the harness story sounds familiar, I would like to hear what you had to chase down last week to keep a delivery on track. Share it in the comments or write to me at oleg@openbom.com. We are looking for a small number of teams to test the Launch Master idea with us.

If you want to see the first turn of the flywheel on your own data, run BOM Review on one of your BOMs. The four deterministic checks are free, including on a trial account.

Meantime, REGISTER FOR FREE and check how OpenBOM can help you.

Best, Oleg

Frequently asked questions

What is a Product Context Graph?

A Product Context Graph is the connected record of what a product is, what was decided about it, by whom, and why, across every system and company that touches it. It links product definition (items, BOMs, CAD, revisions) with production reality (suppliers, inventory, lead times), the work around it (findings, comments, tasks, decisions), and commitments (milestones, quantities, dates).

How is a Product Context Graph different from a knowledge graph?

A knowledge graph describes how things relate. A Product Context Graph also records what people decided and promised about the product, including findings, exceptions, approvals, and delivery commitments, and it is written continuously by everyday work such as reviews and handoffs rather than assembled once by an integration project.

Why is a data, agent, action pipeline not enough for AI in manufacturing?

A pipeline is open-loop. The agent reconstructs the product from fragments on every run, nothing verifies the result, and nothing it learns is kept for the next run. A flywheel closes the loop: review builds context, agents reason over it, accountable people decide, and every decision is written back.

What is an engineering control plane?

Mark Burhop uses the term engineering control plane for the AI layer that receives an engineer's intent, assembles context, plans the work, calls CAD and simulation tools, and presents results for approval. OpenBOM's view is that a control plane also needs a persistent context plane, a Product Context Graph, so agents can learn from what happened and explain their findings.

How does BOM Review build product context?

BOM Review runs deterministic check cards and an AI BOM Health card against the BOM. Findings link to the exact data, people turn them into comments or tasks, and re-running the checks confirms the fix. Each step records what was wrong, who decided what, and whether it was resolved, without a separate documentation step.

Is OpenBOM BOM Review free?

The four deterministic check cards (property, part number, structure, and quantity against reference designators) are available to every OpenBOM user, including trial accounts. The AI BOM Health card requires a subscription because of the underlying model cost.

What is the Launch Master Agent?

Launch Master is an idea OpenBOM is exploring under a working name. It starts from a delivery commitment (configuration, quantity, milestone, and date), looks for inconsistencies between the answers held in BOM, CAD, sourcing, and production systems, and produces blockers with evidence and owners. It is not a shipped product.

How do BOM Review and Launch Master work together?

They turn the same flywheel from opposite directions. BOM Review reasons from the product inward and asks whether the product definition is fit for its next handoff. Launch Master reasons backward from a commitment and asks whether every critical dependency still supports it. Both read from and write to the same Product Context Graph.

Who owns the Product Context Graph?

The manufacturer does. The graph should connect systems of record rather than replace them, and stay independent of any single AI model. In practice, custody goes to the system that is present when the graph is written: at reviews, handoffs, and decisions.