Don’t Add AI to Your Old Release Process: Rethink It with OpenBOM BOM Review

Last week I wrote about adopting OpenBOM one product and one workflow at a time. The idea is simple. Skip the massive PLM transformation, choose a real product and a concrete problem, bring the right people together, and create the first useful result.

In this article I want pick up where where I ended before. Once product data is organized and the team is collaborating, what comes next? For most companies I talk to, the next pressure point is release: the moment engineering data has to become something purchasing and manufacturing can trust and act on. This is exactly where AI creates both an opportunity and a trap.

The trap is to take the release process you already have, with its spreadsheets, email attachments, checklists, meetings, approvals, and manual handoffs, and assign an AI agent to every step. The process looks modern, but the old workflow is simply moving faster between the same old desks.

The opportunity is more interesting. AI gives us a reason to ask why each step exists, what decision the company actually needs to make, and how product information should move from engineering work to a trusted manufacturing release. That is how I think about OpenBOM BOM Review. It is more than a faster way to check a BOM. It is a starting point for rethinking the release process itself.

Automating the interoffice envelope only makes a bad route faster

I recently watched a video by Nate B. Jones that used the old interoffice envelope as a metaphor for enterprise workflows. A document traveled from one department to another. Each person opened it, did a task, added information, crossed out a name, and forwarded it to the next desk.

Email and workflow systems digitized the envelope, but mostly preserved the route. Now AI agents can read the request, summarize it, reformat it, prepare the handoff, and check the next handoff. The envelope still makes the same unnecessary trip around the company.

Engineering release often works exactly this way. An engineer exports a BOM from CAD. Someone cleans it up in Excel. Another person compares it with the previous spreadsheet. Purchasing checks supplier information, manufacturing hunts for drawings, and quality looks for required documents. Someone collects the findings in an email, a meeting gets scheduled, corrections go back to engineering, a new file is exported, and part of the loop starts over.

Putting an agent on each of these activities may save some time. It does not answer the more important question: what outcome does the business actually need?

The answer is not a completed checklist or an approved spreadsheet. The business needs a trustworthy answer to a practical question: is this product definition ready for the next build, purchase, or manufacturing activity, and if not, what specifically prevents it?

Once the outcome is defined that way, we can design the process around the decision instead of automating every inherited step.

Most release steps exist because people cannot see the same product context

Many release activities exist only because people cannot look at the same information in context. Engineering has the CAD structure. Purchasing has manufacturer and supplier data. Manufacturing needs quantities, drawings, and assembly information. Quality needs evidence that required fields and documents are present. Each group builds its own representation because the original files and systems cannot provide a shared, understandable product context.

The result is a chain of translations. The CAD structure becomes an exported BOM, the BOM becomes a spreadsheet, the spreadsheet becomes an email attachment, findings become comments and meeting notes, and corrections are translated back into engineering data. Every translation adds delay, loses context, and creates another chance to work from the wrong version.

OpenBOM changes the foundation of this process. In OpenBOM, a BOM is not a file passed between departments. It is a shared product data object connected to Items, properties, documents, product structure, change history, and revisions. Engineering, procurement, manufacturing, and an AI agent can all review the same information instead of exchanging disconnected copies.

This distinction matters more than any single AI feature. AI is most valuable when it works inside the product context, not when it has to reconstruct that context over and over from attachments and summaries.

“Ready” means something different for a prototype than for production

Before configuring any agent, a company should define what “ready” means for a specific business event. A prototype team may accept a temporary supplier or an incomplete cost. A production release may require approved drawings, manufacturer part numbers, sourcing status, compliance attributes, and formal approval.

I recommend starting with a few plain questions. What decision are we trying to make? Which information is essential for that decision, and which conditions can be checked with known rules? Which findings need engineering or business judgment, who owns each unresolved issue, and what evidence must be kept after approval? The answers give you a review process built on business readiness rather than a generic list of administrative steps.

Consider a small manufacturer preparing an industrial inspection machine for a prototype build. The team needs to know whether every component has an identifiable part number and description, whether quantities match reference designators, and whether drawings and specifications exist for critical components. Purchasing needs enough information to source the optical sensor and the controller. Someone needs to catch structural loops, duplicates, and missing properties, and to see that a proposed substitute is still waiting for engineering approval.

The purpose of BOM Review is to find what prevents the build. It is not to produce a long AI-generated report that nobody reads.

Rules belong to software, judgment belongs to people, and AI works in between

One of the most useful ideas in Nate’s discussion is that not all work requires the same kind of intelligence. This is especially true for BOM Review.

Some checks are deterministic, and software should perform them directly: whether required properties are present, whether a part number follows the agreed pattern, whether quantities correspond to reference designators, whether the BOM contains a structural loop, whether an approved drawing is attached, and whether a component has an assigned lifecycle or sourcing status.

Other questions require interpretation. Is a description clear enough for purchasing? Does a supplier note signal a real delivery risk? Is a proposed substitute technically compatible? Is the BOM complete enough for this prototype milestone even though it is not ready for production?

And some situations are exceptions that need human judgment. A critical component may be unavailable, two data sources may conflict, or a supplier change may affect fit, compliance, cost, and schedule all at once.

A good agentic process does not ask a large language model to rediscover arithmetic or guess whether a required field exists. It combines deterministic OpenBOM checks with AI interpretation and routes consequential exceptions to the right person. That makes the process both more reliable and more economical: intelligence goes where understanding is needed, and ordinary validation stays predictable.

Release should be continuous review followed by a deliberate decision

Traditional release is often a big inspection at the end of engineering. The familiar result is dozens of issues surfacing exactly when purchasing or manufacturing is waiting for the final package. BOM Review makes a different flow possible.

1. Review while the product definition evolves. The agent checks the live BOM as engineering and procurement add information, catching missing properties, inconsistent quantities, incomplete sourcing data, and absent documents before the formal release event.
2. Turn findings into owned work. A useful finding becomes a visible issue, comment, or task connected to the affected product record, so the team knows what is wrong, why it matters, who owns it, and which milestone it blocks.
3. Recheck the product context, not another export. When information changes, the review evaluates the updated product data. Resolved findings disappear, remaining risks stay visible, and new changes are evaluated in context.
4. Escalate judgment, not clerical work. People focus on decisions such as approving a deviation, accepting a sourcing risk, selecting a substitute, or deciding whether a prototype can proceed. Nobody spends the meeting locating files and comparing spreadsheet columns.
5. Capture the approved state. When required conditions are met and human approvals are complete, OpenBOM preserves the released revision as an immutable state. Working data keeps evolving, while manufacturing and purchasing keep a clear reference for the build.

The result is not “AI releases the product.” The result is a shorter, better-instrumented process where automation prepares the evidence and people stay accountable for consequential decisions.

Faster review is worthless if the bottleneck simply moves downstream

Automating one activity does not accelerate the whole value stream. If engineering produces BOMs faster but purchasing still receives incomplete supplier data, the bottleneck moves to purchasing. If BOM Review finds issues faster but nobody owns the follow-up, you have built a bigger queue of findings. If approval gets faster but ERP transfer is still manual re-entry, manufacturing still waits.

Follow the workflow far enough to see where work gets stuck next. This is why I see BOM Review as one stage in a broader OpenBOM adoption path:

1. Organize product data and files.
2. Collaborate in a shared workspace.
3. Review continuously and establish a controlled release.
4. Use released information for inventory, procurement, and production preparation.
5. Connect the trusted product definition to ERP and other systems.

In our Capture, Review, Flow framework, BOM Review is the bridge between shared product data and operational execution. It tests whether the information is actually usable by the next person and the next system.

An agent with real responsibility needs to be measured like a team member

If an agent gets real responsibility, the company needs to evaluate its work. An eloquent review is not necessarily a correct one.

I would measure an agent against outcomes. Did it find the missing or inconsistent data we already knew about? Did it avoid irrelevant findings? Did it connect each finding to the correct Item, BOM, property, or document, and did the right owner receive it? Were blocking findings resolved before release, and did the released structure reach purchasing, manufacturing, or ERP correctly? Most importantly, did the process reduce late discoveries, rework, and time spent waiting for clarification?

Some of these evaluations are objective. Others require feedback from engineers, buyers, and manufacturing specialists, and that feedback should improve the review rules, context, and escalation logic over time. The real measure is not how many findings the agent generates. It is whether the team reaches a correct, explainable release decision sooner.

Start with one product, one release event, and a handful of checks

Do not try to redesign every company workflow at once. Pick one product and one release event, such as a prototype build, a supplier package, or a production handoff, and map the current path from engineering data to the person waiting for the result.

Then question every step on that path. Does it protect a real technical, quality, or business requirement, or does it exist only because information used to be disconnected? Can OpenBOM validate the condition directly? Can an AI agent interpret the context or prepare the next action? Does a person need to make the final call? Can an entire handoff or document simply disappear?

From there, the sequence is straightforward:

1. Configure the first BOM Review around a small number of high-value checks.
2. Assign an owner to each type of finding.
3. Run the review against a real product.
4. Compare its findings with the problems you normally discover during release, purchasing, and manufacturing.
5. Improve the rules and expand to the next release event.

This is the same adoption principle from my previous article: start with one useful result and grow from there.

Conclusion: Don’t automate the envelope, redesign the route

AI gives manufacturing companies a rare chance to rethink how product decisions are made. Placing agents inside every existing step can leave the fundamental process unchanged, and make a bad process faster, more complex, and more expensive.

The better approach starts with the outcome: a trusted product definition that is ready for a specific business purpose. OpenBOM BOM Review brings rules, product context, AI interpretation, human collaboration, and controlled revisions into one connected workflow. It helps teams detect issues earlier, remove unnecessary translations and handoffs, focus people on exceptions, and preserve the evidence behind every release decision.

So the question is not just “How can AI review our BOM?” The better question is this: if people and AI can work together on the same product context, how should our release process work now?

That is the process worth building. If you want to try it with your own product data, register for free to OpenBOM and start with one product and one release event.

Best, Oleg

Frequently Asked Questions

Why shouldn’t I just add AI agents to my existing release process?

Adding an agent to every inherited step makes an old workflow faster without questioning why each step exists. Many release steps exist only because teams work from disconnected copies of product data. Redesigning the process around the release decision removes those steps instead of automating them.

What is OpenBOM BOM Review?

BOM Review evaluates a live bill of materials in OpenBOM against release readiness criteria, combining deterministic checks, AI interpretation, and human approval so teams can decide whether a product definition is ready for a specific build, purchase, or manufacturing event.

Which BOM checks should be rule-based and which need AI?

Required properties, part number patterns, quantity and reference designator consistency, structural loops, and attached documents should be checked by rules. AI is useful for interpretation, such as description clarity, supplier risk, and substitute compatibility. Consequential exceptions should go to a person.

How should a company start using BOM Review?

Choose one product and one release event, map the current path from engineering data to the person waiting for it, configure a small set of high-value checks, assign owners, run the review on a real product, and compare the findings with issues normally found late in release.