
We live in a very interesting time. Over the past two decades, we’ve seen how the internet and mobile technologies have transformed our lives. Now imagine the world before Google, iPhone, Facebook, Airbnb, Uber, Waze, Spotify, and many other tools. Guess what? Most PDM and PLM tools are still the same… and engineers still think in terms of “documents.” In my article today, I want to talk about the end of the Routed Document Era — and what we’re building at OpenBOM to replace it.
Not too long ago, if you looked inside any engineering organization—whether in aerospace, electronics, or industrial machinery – you’d find the same workflow logic in place: design a product, wrap it in a file, route that file for approvals, and pass it along the chain. The system was built on metaphors from the paper world – documents had owners, signatures, folders – and PLM software simply digitized that ritual.
It made sense at the time. Products were simpler. Design cycles were longer. And most companies operated like castles, surrounded by high digital walls.
But times have changed. Today, engineers are collaborating in real-time across geographies. Suppliers and contractors are often more than half of the “team.” And timelines are dictated not by when the drawing is approved, but by how fast a decision can be made with confidence.
So the question is clear: Why are we still routing documents?
In this post, I want to reflect on this transformation and share the architectural and conceptual shifts we’re making at OpenBOM – toward what we call invisible data-driven engineering workflows. It’s not just automation. It’s a foundation built on open data infrastructure, product memory, and intelligent agents—one that’s designed for how modern teams actually work.
Why Engineering Workflows Need a Rethink
In a recent article I wrote on Beyond PLM—“How to Build a Zapier for Engineers”—I broke down the core dysfunctions that haunt modern product development processes. Here’s the crux: most engineering workflows today are held together with duct tape and tribal knowledge.
Let’s start with the fragmentation. Engineers move between CAD systems, spreadsheets, emails, PDM/PLM, and other tools, shared folders, and custom databases. Each tool was introduced to solve a local problem. None were designed to talk to each other.
Then there’s the manual effort. Take something as simple as preparing a BOM for procurement. It involves exporting data from CAD, cleaning it in Excel, looking up part numbers in an ERP system or online, and emailing suppliers. If the design changes in the meantime? Start over.
These workflows are also disconnected by design. CAD speaks one “language”. ERP speaks another. Procurement and supply chain tools often live in yet another universe. And so the same product – say, a robotic arm or a medical device – has five different “truths” living in five different systems, each with its own blind spots.
But perhaps the most harmful issue is that the entire process is document-first, not data-first. Files are treated as the atomic unit of work. And while that worked when products were created using 2D/3D CAD desktop systems and sent off to manufacturing once the design is done, it’s a terrible fit for today’s continuous, collaborative, and much faster cycles that often involve cloud-based services for design work.
So what’s the alternative?
We believe workflows need to reflect how people actually think and collaborate today: dynamically, iteratively, and with help – not friction – from their tools.
OpenBOM’s Vision: Invisible Engineering Workflows
At OpenBOM, we’re rethinking what a workflow even is. Instead of pushing a document through ten boxes on a diagram, we imagine workflows as intelligent interactions between people, systems, and data – all triggered by context and orchestrated by AI-driven agents.
This concept is what we call invisible engineering workflows. “Invisible” doesn’t mean hidden. It means seamless. Helpful. Out of the way, until you need them.
We recently unveiled OpenBOM AI Agent, our first step toward bringing that vision to life. But this isn’t just another assistant or chatbot tacked on to a traditional system. It’s a reimagining of how work gets done.
Here’s what this looks like in action:
- When a CAD model changes, you don’t need to export a BOM manually. The system notices the change, prepares the updated BOM, and alerts procurement if anything impacts cost or lead time.
- When you begin to prepare a sourcing request, the system doesn’t just give you a form. It knows what product you’re working on, what parts are new, which vendors you’ve used before, and which items are under allocation. It helps draft the RFQ – and can even send it if you approve.
- Instead of assigning tasks manually, agents can watch your progress and remind you of next steps. Did you forget to release a drawing that was changed yesterday? The agent has your back.
The underlying principle is simple: move from orchestrating documents to orchestrating outcomes.
No more uploading PDFs. No more guessing which version is right. No more workflows that feel like compliance hurdles. Invisible workflows cut the overhead and amplify the team’s focus.
Beyond SaaS: Introducing Product Memory + Agents
Moving from legacy PLM workflows to intelligent, dynamic ones requires more than a better interface – it demands a new foundation.
Traditional SaaS PLM systems gave us cloud access and subscription pricing, but the architecture was largely unchanged. Data was still siloed. Workflows were still document-focused. And automation is largely the same “document-like workflow diagram”.
At OpenBOM, we’ve taken the next step. We’re introducing two powerful concepts that reshape how engineering work is managed: Product Memory and Agents.
Product Memory
Think of product memory as the living knowledge base of your product. It connects not just the files, but the facts: part numbers, design changes, vendor quotes, status updates, configurations, approvals, and dependencies. It evolves as your product evolves.
Unlike a PLM system where information is locked inside document versions, OpenBOM’s product memory is:
- Federated: It doesn’t require you to centralize all systems. It links to CAD, ERP, and supplier data where it lives, while offering a unified view.
- Queryable and extensible: Need to see where a specific capacitor is used across all projects? Or which suppliers quoted it in the last 6 months? Product memory lets you answer those questions instantly.
- Real-time and multi-tenant: Multiple people – even from different companies – can view, contribute to, and act on the data, without delay or replication.
This product memory is what makes smart collaboration possible. It’s what gives agents their intelligence. And it’s what enables engineers, buyers, and project managers to work in sync—even if they never touch the same system.
Agents
If product memory is the brain, agents are the hands and eyes (tools).
An OpenBOM agent is a task-specific, intelligent entity. Some are powered by traditional logic (like checking unit cost thresholds); others use AI to interpret requirements, extract meaning from drawings, or draft supplier messages.
Importantly, agents don’t work alone. They augment humans.
A buyer sees a flagged part – an agent provides risk analysis and alternate sources. An engineer starts a design – an agent verifies compliance with part standards. A project manager wants status – an agent compiles cross-system information and alerts to delays.
What’s special about OpenBOM’s vision of agents is that the framework is open – you can build agents that they operate across domains. OpenBOM plans to support a standard framework and protocols for agents, so everyone will be able to use them and build other agents. They don’t live in CAD or ERP, or PDM systems. They span them. Because that’s how real engineering work happens – in the gaps between tools.
What’s Next: Human + AI Collaboration in Engineering
So what will this actually look like?
In upcoming posts, I’ll share how we envision engineers to interact with OpenBOM agents in everyday work and our delivery plans. For example:
- An AI-assisted BOM review tool that spots anomalies, missing data, or pricing red flags – and suggests fixes.
- Procurement agents that automatically track lead times, trigger RFQs, and flag deviations – without waiting for a formal workflow to start.
- Configuration agents that understand design intent and propose compatible part variations for different product lines or geographies.
We’ll also go deeper into the technical side – how events are captured, how agents are created, and how the architecture scales across departments and partners.
But the most important shift is that workflows aren’t diagrams anymore. They’re teams – blended teams of humans and intelligent agents working together over shared, live data.
This isn’t about replacing your PDM or ERP system. It’s about augmenting them with intelligence. Let them continue managing compliance, cost, and approvals—but let OpenBOM help you work faster and smarter in between.
Conclusion: Reimagining Engineering Work
Traditional PLM workflows gave us control, traceability, and structure, but they also gave us friction, delays, and duplication.
Today’s products and teams demand more. They demand workflows that are dynamic, data-driven, and adaptive. They need systems that don’t just route information—they act on it. And they need tools that help people get work done, not just document that it happened.
At OpenBOM, we’re building new workflows – one where product memory becomes your team’s shared brain (Manufacturing Graph), and where agents become trusted co-workers.
If you’ve ever felt your tools are slowing you down more than they help, we believe this transformation is for you. We’re just getting started. Stay tuned.
Interested to learn more – contact us today.
Best, Oleg
Join our newsletter to receive a weekly portion of news, articles, and tips about OpenBOM and our community.