Technology + Method: The Transformative Productivity Equation

We spend a lot of energy talking about change, and even more talking about how to apply technology to it. The speed of AI innovation itself is no longer in question — it is happening, and it is happening fast. Executives and practitioners are largely aligned on that point, and aligned that the imperative is to adopt, use, test, and deploy. The question left standing is how.

That "how" is the familiar pattern we are observing: pilots are failing, POCs don’t scale, digital initiatives stall, etc. This is real, and it isn’t surprising that organizations reach for technology instead of method to answer it. The tool is always the easier lever to pull — it’s not a new behavior, and it’s a familiar failure mode. Something similar happened when Lean first arrived in manufacturing in the West. The tools got the attention — the focus was on the Kanban boards, the 5S audits, the Supermarkets, Andons, Poka-Yoke, Kamishibai, and so on — while the harder, genuinely transformative process behind them, the organizational adoption of Lean and the change in operational behavior, got skipped. That pattern resurfaces with every new paradigm, and we are clearly watching it happen again.

It’s disheartening that the prescription, once again, is entirely about the technology: data structure, infrastructure, context, integration, connectivity. Every one of those is correct and necessary. None of them will do much on their own, without a strategic process of transformation — one backed by leadership strong enough to actually drive the organization toward an order-of-magnitude productivity improvement.

Deploying transformational technology into an organization that hasn’t changed how it behaves, thinks, designs, engineers, and of course operates isn’t transformation. Transformation is genuinely hard, which is exactly why organizations keep reaching for the tool instead. It’s easier to issue a purchase order for tech; trying to change the way you operate is a challenging, conflict-ridden process that is uncomfortable and very risky.

So what is the best approach here? It really is not new, like in Lean and in CIM (Computer Integrated Manufacturing, yes, remember that?), the answer is the combination of a technology that is truly digital, and an effective method to guide how it’s adopted in a continuous transformative motion. A new way of working, designing, operating, and engineering, not just a new technology capability bolted onto the existing operational model. You will know it’s working when it produces a transformative, order-of-magnitude productivity gain. That is what leadership should be expecting, not an incremental improvement.

The Productivity Equation

The Productivity Equation

Let’s start by stating the obvious. The observation and discussion on digital adoption failure rates are real. I need to start with this background to ground reality and satisfy the skeptics — if there are any left.

MIT’s NANDA initiative found that 95% of enterprise generative AI pilots deliver no measurable return despite tens of billions in enterprise spend — not because the models are weak, but because the organizations never integrated them into how work actually happens. That’s consistent with what BCG found well before generative AI showed up: 70% of digital transformations fall short of their objectives. McKinsey’s own research on why transformations fail lands on the same conclusion from a different angle — the constraint is almost never the technology’s capability, it’s the organization’s ability to change how it works around it.

In the last three decades I have watched this unfold countless times, where companies attempt to absorb new technology without changing their approach or how they work, and then wonder why the improvements do not stick. The technology becomes the thing they tried. Not the operating model they run on.

This is the same digital divide I’ve been writing about for years — not embracing the required change is really just digital theatrics. Naming the problem is half the battle; solving it to produce a sustainable productivity gain is victory. This can only be achieved by executing on the equation — the two specific, concrete components, applied together.

The Technology

You have to use technology that is genuinely digital and AI-native. This critically means composable — not just connected, modular, AI-enabled, digital, IIoT, and, of course, not monolithic. Composable technologies are built to change at the pace of the business and operations rather than the pace of an IT project, and to absorb new capability, including AI, in hours-to-days iteration cycles rather than months-to-years projects.

That distinction sounds like a technical footnote until you sit with what it actually means operationally. In a traditional, monolithic system, a change — a new product introduction, an equipment upgrade, a new process step, a new quality procedure, a technology upgrade, etc. — will trigger a change request, a design review, configuration, a validation cycle, and a deployment window measured in months. This is due to the monolithic nature of the solution: architected around a single, centrally-owned data model, it cannot change locally without touching everything connected to it. That’s not a flaw a vendor fixes with a software update — it’s the architecture.

A composable platform inverts that. Each solution is scoped to one operator doing one job, apps share data through common structures but are independent of one another, and a local change stays local. That’s the concrete, measurable expression of "technology built for transformation": speed-of-change, hours-to-days instead of months-to-years. It’s also the precondition for AI to be useful in operations at all — a model can only iterate as fast as the system around it lets it, and a platform that requires a quarter to reflect a floor-level change will require a quarter to reflect what an agent just learned, too.

Notice that the method, composability, is already embedded in the technology. Technology alone — even genuinely composable technology — produces pilots, not transformation. This is the half of the equation; it is necessary but it is not sufficient.

The Method

You have to use a method that defines the underlying transformative theory and its mechanics — the concepts and the strategic guidance, together. Lean is the clearest example. Its concept is a specific definition of what a Lean operation looks like when it’s actually working, and it rules out what doesn’t count: Lean, at its core, defines a small set of principles for an operation — identify value, make value flow, execute pull, and enable perfection. A cost-cutting exercise with no customer-defined value isn’t Lean, no matter how many Kanban boards it has. The tools — Kanban, 5S, Andon, Poka-Yoke, Kamishibai — are what make that concept usable on the floor, not just legible to a consultant. Concept plus tools is the playbook, and the playbook is what makes a transformation widely usable and easy to adopt at scale.

So, a method that actually drives transformation has two specific components: a concept — the foundational idea, strategic model, and guiding vision that redefines how operations use technology, expressed as a framework that defines the outcome you should expect and, just as precisely, what falls outside it — and a set of tools and best practices that show people how to apply that concept correctly, in daily work.

A concept with no tools stays a slide in a training deck nobody can act on. Tools with no concept behind them turn into techniques people run without knowing what they’re supposed to add up to — which is exactly what happened when Lean arrived in the West, as I noted above.

The method here is called Composability, and I’ve explained it in a number of previous posts. It includes a concept, a framework, tools, and best practices. Composability is defined by five pillars, resting on two foundational, supporting conditions. Each pillar has its own supporting tools and best practices, all bound by the same framework. Here is the framework:

Bottom-up. Solutions are built from the operational level up — not imposed through top-down hierarchies — tailored to the specific process, with the people closest to the problem contributing directly to what gets built. This produces emergent design: solutions evolve in real time as operational needs evolve, deployed incrementally and iterated on immediately, rather than routed through an IT change-request queue against a predefined architecture.

Agility — Augmented Lean. Composability is the reunion of Lean and Agile: rapid test-fail-learn cycles and on-demand process changes, in place of the predefined processes a monolithic system locks an organization into. This isn’t a development methodology; it’s an operational property — the ability of the floor to respond to a process change, a quality event, or a new product introduction in hours-to-days instead of weeks-to-months. I call this Augmented Lean because it is, structurally, the Toyota Production System’s logic of standardize-then-improve, run inside a digital architecture that can actually keep pace with how often the standard needs to change.

Democratization. The people who know the process — engineers, technicians, operators — build and maintain the digital solutions themselves, using no-code and low-code tools, without waiting on centralized IT. This is also the organizational mechanism that lets change scale past the first pilot: people get trained to build, and the organization accumulates a growing portfolio of focused, continuously maintained apps instead of a single archived experiment. Generative and agentic AI are amplifying this pillar further — describe a process in natural language and get a working scaffold back, and the barrier to entry drops for people who would never otherwise touch a no-code tool.

Human-centric. Technology serves the operator, not the reverse. Traditional enterprise interfaces make the person on the floor into a data-entry function for the system — locate the right transaction, navigate the rigid form. A method that inverts this, designing around the operator’s actual workflow rather than the data model, puts the operator at the center: productivity gains come from augmenting human capability, not from forcing people to adapt to system constraints. This is also still fundamentally about people, not software.

Compliance. In regulated environments — life sciences, aerospace and defense, and others — this pillar is less about the baseline technical requirements every platform has to meet (audit trails, e-signatures, data-integrity standards — prerequisites, not differentiators) and more about a mindset shift: the belief that a digital solution can be continuously improved while remaining in a validated state, instead of locked down between full re-validation cycles. Changes get scoped, risk-assessed, and evidenced automatically, which is what makes agility and democratization survivable in a GxP context rather than a liability.

Underneath all five pillars, two more concepts have to be true, or the playbook doesn’t hold. The first is digital maturity — an organization’s actual, demonstrated capability to run composable architectures, not just its enthusiasm for them. Culture, skills, and governance have to advance in step with the technology; an organization can deploy a composable platform and still fail to capture the gain if its people and processes haven’t caught up to what the platform enables. The second is connectivity and data integrity — accurate, consistent, trustworthy operational data, available at the point of work. Without it, none of the five pillars actually function: an operator can’t be human-centric about a decision built on data they know is stale, and an agent can’t augment what it can’t see clearly. Digital maturity and connectivity are the two bases the five pillars stand on — not an afterthought to them, but the ground underneath.

None of this is a modularity story. Composability is not "interchangeable pieces." It’s an operating discipline that determines whether an organization can sustain the rate of change its business actually requires — and every one of Lean’s real tools, including standard work, lives inside it rather than outside it.

The Outcome is Always the Measure of Success

Technology without method produces pilots with marginal productivity increases. Method without technology is a theoretical exercise that fails on execution. Technology with a method drives transformation that results in order-of-magnitude productivity improvements.

My simple equation uses addition, but there’s a scenario where it actually becomes multiplication. A brilliant composable platform deployed with no method for what to build first, on which line, with which team, or toward which measurable outcome doesn’t stay composable for long — it degrades, most detrimentally, into just another monolithic JAM (Just Another Manufacturing System). That isn’t a smaller version of transformation. It’s a sure way to keep doing what you were already doing, which is exactly where the marginal outcomes come from. A beautifully designed operating philosophy with no platform capable of executing it for rapid time-to-value doesn’t drive transformation either. It’s a sure way to build distrust and skepticism.

Technology + Method = Productivity. Not one or the other.

Why Trust Is the Real Problem with AI — And What to Do About It

A few months ago I was asked to contribute a chapter to a new book called The AI Opportunity. The editors wanted a practitioner's perspective — not another "AI is coming" think piece, but something grounded in how AI actually lands, or fails to land, in environments where physical things get made. I wrote Chapter 14: Designing AI-Enabled Operations That Humans Can Trust.

The book is now published, and I want to share the core ideas here in a practical format that is a bit more direct. Because honestly, the message is something I have been trying to get across for years in various ways, and the book format gave me the chance to put it all in one place.

Here's the short version: The reason most AI deployments in manufacturing fail isn't the technology. It's the fundamental approach and architecture, and that is what I define as composability.

Let me unpack why.

The Trust Problem Is Not What You Think

When manufacturing leaders talk about "trusting AI," the conversation usually gravitates toward ethics, model accuracy, or data quality. Those things matter — but they are not where trust actually breaks down on the shop floor.

In operations, trust is earned through repeated, consistent performance in the flow of everyday work. It's not about whether a model is statistically impressive in a benchmark. It's about whether a system behaves predictably when conditions change, supports human judgment under pressure, and fails safely when uncertainty rises.

Manufacturing makes accountability impossible to avoid. When AI influences how a deviation gets handled, whether a product ships, or how a piece of equipment gets configured — responsibility doesn't transfer to the algorithm. Humans are still on the hook. So when an AI system obscures its reasoning, works from incomplete data, or overrides operator expertise, trust evaporates fast. And in regulated industries like pharmaceuticals or medical devices, where explainability isn't optional, an untrustworthy system isn't just frustrating — it's ungovernable.

The trust problem in AI is not primarily an ethical or philosophical issue. It is a design problem.

That is the chapter's central argument, and I think it's the most important thing for executives and practitioners to internalize before they make another AI investment.

Why Most AI Deployments Disappoint — And What To Do About It

We have all seen the statistics — AI pilots that don't scale, initiatives that live forever in proof-of-concept purgatory, strategy decks full of AI ambition and shop floors that look the same as they always did. At this point we have all heard this ad nausoum - on a daily basis! But the pattern is real and worth understanding, because the failure mode is consistent and fixable.

AI gets layered onto existing operational systems — systems that were engineered for stability and repeatability, not adaptation. These systems encode yesterday's processes — and not just yesterday's, but the assumptions of the 1980s electronic era that gave rise to the monoliths that still runs manufacturing today. Layering AI onto these foundations doesn't fix the mismatch; it deepens it. More digital on top of the wrong structure is still the wrong structure, its literally lipstick on a pig.

There's also a velocity problem. AI capabilities now evolve on a monthly cadence. Operational systems and governance models move in multi-year cycles. The gap between what AI can do and what organizations can absorb keeps widening, creating what I call "velocity paralysis" — organizations that recognize the opportunity but can't act fast enough to capture it.

And then there's the context problem, which is the one I've been writing about for years in this blog. More than half of operational knowledge exists as "dark data" — observations, judgment calls, visual cues, and institutional experience that never enter digital systems. When AI is built on this incomplete foundation, its recommendations feel disconnected from what operators see and know. It reinforces skepticism rather than trust. And skepticism, as I've written before, kills more innovation than failure ever does.

AI now makes the digital divide even more clear, while at the same time providing a unique opportunity to cross it faster.  

Composability and Agentic AI: The Design Answer

The answer to the failures described above is composability — and I want to be precise about what I mean, because the word gets misused. Composability is not a software architecture concept. It is the method for transforming operations in the digital era, defined by five reinforcing pillars: bottom-up adoption, agility (what I call Augmented Lean), democratization, human-centricity, and compliance. Together, these pillars create operational systems that can absorb change continuously without losing control — which is exactly what AI deployment requires. I've written about the 5 Pillars and digital maturity at length elsewhere, so I won't retread all of it here. The point for this chapter is that composability is the precondition — without it, AI accelerates fragility rather than productivity.

The book chapter also introduces the framework for deploying agentic AI within this composable foundation. The core idea: a human actor — an engineer, a citizen developer, an operations lead — remains at the center, defining intent rather than writing code, and retaining accountability for outcomes. Two classes of AI agents operate around them: Staff or Companion Agents that augment human judgment with insight, pattern recognition, and recommendations without executing changes independently; and Builder Agents that create operational artifacts — workflows, connectors, data models — within explicit governance constraints. The result is an agentic system that can evolve rapidly without destabilizing operations, because scope is bounded and outputs are transparent. I published a full treatment of this Composable Agentic Framework last year — if this is new to you, that's the place to start.

What Executives and Practitioners Actually Need to Know

I'll close with the practical takeaways, because that's why this chapter exists.

For executives: The risk calculus has flipped. For decades, the conservative position in manufacturing was "wait and see." That position is no longer conservative — it's dangerous. Organizations that learn to apply AI responsibly within their operations will become structurally more productive, more adaptive, and more competitive over time. The gap between those who do this well and those who don't will compound. As I put it in the chapter: what begins as prudent caution can quietly turn into strategic disadvantage. Don't be the last dinosaur.

For practitioners: The question is not whether to implement AI — it's whether to implement it in a way that actually works in your environment. That means resisting the pressure to layer AI onto rigid monolithic architectures. It means designing for human agency from the start, not as an afterthought. It means treating data integrity as a precondition, not a downstream problem. And it means choosing composable, modular approaches that allow your operations to absorb change continuously — because the pace of AI evolution is not going to slow down to match your ERP upgrade cycle.

For both: Trust is not a soft concept you address in the governance policy document. It's a hard design requirement that shapes every architectural decision. Build systems that humans can understand, intervene in, and be held accountable for — and AI becomes a genuine multiplier. Build systems that obscure logic, override expertise, and create black boxes on the shop floor — and you'll spend the next three years explaining why the pilot succeeded but the rollout stalled.

The future of AI will not be decided in models or labs alone. It will be decided where work happens, one operation at a time, by organizations that have the courage to engage, the discipline to design for trust, and the humility to let humans and machines learn together.

More Is Coming

If these ideas resonate — trust as a design problem, composability as the operational method, agentic AI governed by human accountability — there is a lot more on the way. I am currently working on writing the Augmented Lean Field Guide, the practitioner companion to the original Augmented Lean book. It goes significantly deeper than any single chapter or blog post can: full frameworks, worked design patterns, and the full arc from first pilot to continuous transformation. It will be out by the end of 2026, and I'll be sharing more from it here as we get closer.

Democratization Is Not Anarchy. Learn to Deal with IT!

In nearly every conversation I have with manufacturing executives about their digital transformation programs, the topic of democratization surfaces the same way. As a problem. "How do we make sure people aren't building things outside of our control?", "How do we enforce compliance with IT governance?" "How do we prevent shadow IT from getting into production?" "What's our policy on AI-generated code?" The conversation turns to containment before it ever reaches potential. And in my experience, that is exactly the wrong place to start.

I've written about democratization as one of the 5 Pillars of Composability for years. It generates more internal friction than any other pillar — not because it is the most dangerous, but because it is the most misunderstood. Organizations treat it like a problem to be controlled. What they should be treating it like is the engine that has been quietly driving their best productivity gains for the past three decades — whether they recognized it or not.

The evidence has been right in front of us the entire time. We just keep refusing to see it.

The Proof Has Been Hiding in Plain Sight

Look at Microsoft Excel, there is no piece of enterprise technology that has driven more distributed manufacturing productivity gains than a spreadsheet application that anyone can use. Long before no-code platforms existed, Excel was what people reached for when the digital solution they needed simply didn't exist — or when the monolithic system in place couldn't provide it. From simple hour-by-hour production trackers to complex inventory management models, engineers and operators built what they needed with what they had. The gap was always there, because ERP, MES, WMS, QMS, EAM — every monolithic system of record was designed for structured, standardized workflows. The contextual, the ad-hoc, the highly specific operational problem always fell through the cracks. Excel caught them. It democratized data manipulation — it placed analytical and tracking capability in the hands of every engineer, quality manager, and production planner on the floor. IT organizations hated it. Shadow IT. Ungoverned. Risky. And yet — it worked. The productivity it unlocked was enormous, precisely because the people building the tools were the people who understood the problems.

The same story played out with Human-Machine Interfaces on the plant floor. When SCADA and DCS vendors began providing configuration environments that operators and process engineers could use directly, the pace of process improvement accelerated. The automation engineers closest to the process could suddenly instrument, visualize, and adjust without waiting months for a programmer to interpret their requirements, write a specification, queue the work, and deploy a change. Democratization of configuration capability drove productivity. Again.

The pattern is consistent: 

When you give operationally knowledgeable people the tools to solve their own problems, the rate at which problems get solved increases dramatically. This is not a hypothesis — it is a thirty-year track record.

This is precisely the type of democratization that no-code and low-code platforms have extended into frontline operations over the past decade. The shift from "IT builds, operations uses" to "operations builds what they need" compresses the lag between identifying a problem and solving it from weeks to hours. As I've described through the lens of digital maturity, organizations that make this shift don't just get more efficient — they develop a fundamentally different operational capability. They become adaptive

AI Is Closing the Last Gap — and That Changes Everything

No-code lowered the barrier to building digital solutions, but it still required learning a new environment, a new paradigm, a new way of thinking about logic and workflow. AI is closing that gap entirely. You can now describe what you need in plain language and have a working solution generated in front of you. The barrier to content creation for is approaching zero.

Think about what that means for the examples we just discussed. The engineer who used to spend days building a complex spreadsheet model to track WIP and yield can now describe the logic conversationally and have the model built for them. The process engineer who needed a SCADA supplier's configuration team to update an HMI display can now specify the change in plain language and iterate in real time. AI isn't just another wave of democratization, it super charges it. It skips no-code as the primary mechanism by which non-programmers create digital solutions.

And here is the implication that most organizations are missing: as the barrier to creation approaches zero, the value of the platform it runs on increases dramatically. Anyone can generate a solution. Not everyone is generating solutions that are version-controlled, validated, connected to the right data sources, maintainable by someone other than the person who built them, and operating within a compliant environment. The purpose-built platform — composable, human-centric, compliance-ready — becomes more critical, not less, as AI democratizes creation. Ungoverned AI generation without a platform foundation is not democratization. It is the digital equivalent of everyone writing their own procedures on sticky notes.

As I described in A Composable Agentic Framework for Frontline Operations, the emergence of builder agents — AI that helps domain experts design and iterate digital solutions in real time — is the realization of this shift. The question it raises for every manufacturing organization is not "how do we control this?" It is: do we have the platform foundation to make what our teams are about to build actually work?

And the organizational response? The same one we've seen before. Fear. The containment reflex. "What's our policy on AI-generated code in production?" "How do we prevent people from deploying things that haven't been validated?" "Who is accountable when something built with AI goes wrong?"

I am not saying those are wrong questions. I am saying they are being asked before the far more important one: what becomes possible when your process engineers, quality specialists, and production leads can build and iterate the tools they need in hours rather than weeks? That is the question that unlocks value. Governance comes second — as the framework that makes value creation sustainable — not as a replacement for asking whether value is even being pursued.

In both previous waves of democratization, the organizations that responded with blanket restriction fell behind the ones that built governance structures capable of channeling the new capability. As I've been observing as the industry traverses the digital divide, the companies pulling ahead are not the most cautious — they are the ones with a sound strategy and culture that enables effective governance.

Why Democratization Gets Managed Instead of Harnessed

The answer is structural, and it runs deep. Most manufacturing organizations still operate with a mental model inherited from the era of monolithic systems — where digital capability was scarce, expensive, and necessarily centralized. In that model, IT was the gatekeeper because it had to be. Building anything digital required specialized skills, expensive licenses, and careful change management. The architecture was fragile. A mistake in one place could propagate across the whole system. In that context, tight central control was not a choice — it was a necessity.

The decline of monolithic architectures didn't just change the technology. It changed the risk profile. Composable platforms are designed for distributed development — with version control, role-based permissions, validated templates, and isolated workspaces that contain failure to a single application or station. But organizational culture moves slower than technology. The gatekeeping mindset persists long after the scarcity that justified it has disappeared.

So we still see organizations applying the change governance frameworks designed for monolithic systems deployments to no-code app development. We see IT review boards that were built to manage quarterly release cycles now being used to evaluate whether a process engineer can add a field to a workstation app. The tools changed. The governance didn't. And the result is that organizations spend more energy suppressing the creative capacity of their most operationally knowledgeable people than they do enabling it.

There is also a subtler dynamic that I've observed consistently. Organizational skepticism tends to attach itself to democratization specifically because its outputs are distributed and visible — not because they are more dangerous than centralized systems. A poorly architected process buried inside a monolithic MES can affect the entire operation and take months to unwind. A poorly designed app built by a process engineer affects a single workstation and can be corrected in an afternoon. The distributed failure mode is actually less catastrophic. But it's more visible, and visibility triggers the control reflex — even when the underlying risk doesn't warrant it.

Democratization Is Not Anarchy. It Requires Democratic Governance.

Here is the point I want to make directly: democratization is not the absence of rules. It is the distribution of capability within a system of rules.

We have a model for this. It is called democracy. Functioning democratic systems are not anarchies — they are the most sophisticated governance structures humans have built. They have constitutions, laws, institutions, independent accountability mechanisms, and ethical norms. They distribute power not because they have abandoned governance, but because they have built governance structures capable of handling distributed power. The result — when it functions — is a more resilient, adaptive, and innovative system than any centralized alternative has ever achieved.

The comparison to manufacturing governance is direct. What I have consistently called controlled democratization means giving people the capability to solve their own problems within a governance framework designed to channel that creativity productively — not police it into submission. Policing is a dictatorial method. It is also what traditional top-down, monolithic systems use. And it is precisely why those systems generate compliance without generating adaptability.

The most well-governed democracies do not work because they have the most police. They work because they have strong institutions, a culture that understands and values the rules, and mechanisms for accountability when those rules are violated. Manufacturing organizations that want to harness democratization need to build the equivalent: platforms that enforce governance by design rather than by gatekeeping, centers of excellence that guide rather than approve, and a culture that treats accountability and empowerment as the same thing — not opposites. The power of that combination, when you've seen it operating at scale, is not incremental. It is categorical.

The Question Is Not Whether. It's How.

Your teams will use AI to build things. The only variable is whether they do it inside your governance framework or around it. Blanket restrictions don't prevent use — they push it underground, where it operates without documentation, without platform guardrails, and without accountability. That is the actual risk. And it is a risk created entirely by the policing reflex.

Every previous wave of democratization taught the same lesson. The organizations that tried to stop it accumulated missed improvements, unsolved problems, and eventually lost the people who were motivated enough to try. The organizations that built governance structures to channel it gained ground that compounded over time.

Continuous transformation is only achievable if democratization is operating at full potential. You cannot get there by treating your most operationally knowledgeable people as risks to be managed. The difference between democratization and anarchy has never been the absence of rules — it has always been the quality of governance.

Build governance worthy of the capability your teams are ready to use. Don't be the last to start.

Video Illustration: The AI Knowledge Revolution

An Alternative Visual

This is my alternative visual narrative that explores how AI and specifically Agentic AI are fundamentally disrupting traditional manufacturing hierarchies. The video illustrates the "compression" (or collapsing) of the classic Data-Information-Knowledge-Wisdom (DIKW) pyramid, showing how AI now acts as an intelligent intermediary that instantly transforms unstructured "human language"—like deviation comments and work instructions—into actionable operational wisdom

Key themes include:

• Collapsing Complexity: Moving past the rigid, million-dollar data models of the 1990s to a system that understands context like a human.
• Knowledge Flow: Driving multi-site transformation through "Outbound" digital playbooks and "Inbound" frontline innovations.
• Augmented Lean: Democratizing expertise across the entire network so every site becomes both a consumer and a producer of wisdom.

I also talked about it in an interview for Tulip's "Human in the Loop" series.

Behind this is a body of work and a lot of written content that I will publish in the future. As I have written before I am experimenting with different formats to convey the message about composability. 

Stay tuned more content will be coming out in the future!

Agentic AI in Action: What I Learned Experimenting with Operational and Builder Agents

Over the last several months, I’ve been deepening my exploration of Agentic AI within Tulip, applying the concepts I laid out in my Agentic Framework and testing them in real operational scenarios. What started as curiosity has quickly become something else entirely: a recognition that we are opening a fundamentally new chapter in how manufacturing systems are built, operated, and scaled.

As I’ve experimented with both operational agents—those that support frontline teams in real time—and builder agents—those that help design, generate, and improve digital solutions—I am realizing how deep and wide the impact is going to be. The more I explore, the more use cases reveal themselves, and the more explosive the potential becomes. Its much more than I initially thought, and I have been thinking in terms of multi-agent systems for manufacturing since the 90's! Agentic AI (multi-agent systems powered by generative AI) are a much bigger step change than I would have imagined to how we think about creating and running manufacturing solutions.

Let's start with a brief recap. Operational agents extend the capability of the production system realizing digital twin capabilities in ways that introduce reasoning, interpretation, and contextual understanding directly into the work being done on the floor. Builder agents open the door to a multithreaded, parallel engineering process that fundamentally changes the speed and depth at which solutions can be created. It feels less like a “copilot” assisting a developer and more like a coordinated team of SMEs designing solutions - Augmented Lean at hyperspeed!

This combination—augmenting frontline execution while accelerating the design and iteration of digital systems—points to a future where humans orchestrate agent ecosystems rather than manually building every piece of a solution themselves. This brings me to the motivation for writing this post that became clear to me in a recent customer conversation about DCS integration in support of a digital solution for pharmaceutical manufacturing of clinical drugs.

Reimagining Composable Integration with DCS and ISA-88 Through Agentic AI

The question I was asked recently wasn’t the classic “How do you integrate an MES with a DCS?”—that problem has been addressed in many different ways in the traditional architectures. The real question was far more interesting: How do you integrate a Composable MES built on a Frontline Operations Platform with a DCS or other ISA-88 based batch system?

In a traditional MES world this integration immediately triggers a familiar debate about how to partition the recipe across systems, define boundaries of responsibility, and reconcile master data, recipe models and equipment hierarchies. And that debate is almost always constrained—if not outright dominated—by the rigidity of monolithic MES platforms. The architecture drives the discussion more than the operational needs do.

But in a composable environment, the constraints that shaped those historical debates simply don’t apply. Let's look at what happens when you apply a composable, agentic model.

1. Composable Apps Remove the Traditional Constraints

In a composable architecture, apps are not bound to a predetermined master data model or recipe structure. This means that there is no need for recipe model partitioning, no need to replicate equipment hierarchies, no predefined S88 recipe model to map into. 

This flexibility removes the most painful barrier in traditional MES ↔ DCS integration: the structural reconciliation of recipes and equipment models. The DCS can continue using its ISA-88 representations. Tulip apps can represent the process in the most intuitive and useful way. And the integration simply becomes the mapping of meaning and intent between the two worlds. You design the representation of the process that makes sense for your operation—not the one dictated by the systems.

Composable solutions also shift the perspective entirely by taking a human-centric, activity-based approach organized around the physical reality of the shop floor. I fully recognize that, in the traditional monolithic MES world, standard models like ISA-88 were considered essential—they provided structure, discipline, and a shared language for process-centric systems. But composability represents a fundamentally new paradigm. 

To democratize operational systems and bring them closer to frontline work, we must prioritize operator-first design rather than forcing every SME to become a master of S88 modeling. ISA-88 remains invaluable for process control, but the surrounding operational systems must be simplified and democratized so they can work hand in hand with the distributed nature of modern manufacturing. Composable platforms do exactly that: they allow process engineers, chemical engineers, and frontline teams to collaborate without being constrained by rigid, expert-only models.

This alone would dramatically simplify integration. But the real breakthrough comes with agents.

2. Builder Agents Enable Multithreaded, Generative Solutioning

Builder agents transform integration work from a linear, manual design activity into a parallel, iterative, and generative process. They don’t just help you “build faster”—they fundamentally change how solutions are conceived and engineered.

I experimented with builder agents that can ingest a full ISA-88 recipe structure and conduct deep introspection on it: understanding the procedural models, identifying phase logic, parsing parameter definitions, and extracting the relationships between equipment, units, and operations. It then suggested mappings, app contexts, and design patterns—not only based on expert interpretation of the ISA-88 standard, but also from what they’ve learned across existing apps, historical integrations, real-world performance of similar solutions and critically expert knowledge of composable design principles. In other words, these agent combines domain expertise with empirical insight, offering design options that reflect both best practices and operational realities.

This alone already feels like having a team of process engineers and MES architects working in hyperspeed. But the true power emerges when operational agents begin contributing dynamic intelligence into that design loop.

Operational agents provide real-time feedback about process variability, material availability, logistics implications, quality status, or unexpected delays. They can accommodate non-optimal or evolving recipes by dynamically dispatching materials, reallocating resources, or bringing the right expertise into the process at the right time. This dramatically increases operational resilience and reduces risk—because the system adapts rather than stalls when confronted with real-world complexity.

And then there’s compliance...

Specialized builder agents trained on GxP principles can support on-the-fly risk assessments, propose mitigation strategies, and generate validation documentation as part of the design cycle. Operational validation agents can take this further, enabling true continuous validation—monitoring execution conditions, evaluating deviations against risk models, and providing traceable explanations for decisions. Compliance becomes embedded, in fact native, in the system rather than layered on top.

When you step back and think about the implications, the potential is almost infinite. The combination of builder and operational agents elevates agility and compliance to levels we’ve never imagined in traditional MES architectures and design approaches. It enables systems that are not only faster to build, but continuously improving, self-aware, and aligned with both operational needs and regulatory expectations.

This is the beginning of a new era in how manufacturing solutions are designed, executed, and validated. It feels like a generative design process running at hyperspeed. Not a single assistant helping you code tasks faster — but a team of AI experts collaborating to create a complete solution.

And this unlocks something we have never had before in manufacturing software: the ability to rapidly iterate and explore multiple viable integration architectures before committing to one. This is enormously valuable in an ISA-88 context, where recipes, equipment logic, and operational variability rarely align perfectly.

Seeing the Explosion of Use Cases

If you let the builder and operational agents begin to work together, the number of possibilities just explodes - its the first step towards a Multi-Agent System (MAS). These agents don’t simply execute tasks—they learn, reason, and collaborate in ways that constantly reinforce and expand what’s possible. Suddenly, problems that used to take months of engineering effort can be tackled in days—or even hours.

Some of the notable and exciting use cases I’ve come across include:

• Automatically mapping process logic into app structures.
• Rapidly generating compliant workflows for regulated environments.
• Exploring recipe variants and operational scenarios through simulation.
• Using agents to assist in validation and documentation.
• Dynamically interpreting and adapting recipes at runtime.
• Applying cross‑system reasoning to catch inconsistencies early.
• Coordinating multiple agents to design complete production solutions.

Each one opens a new door—where imagination, not technical limitation, becomes the real constraint.

What stands out to me most is the sheer power of these systems and what they make possible. Seeing a builder agent reason through an ISA-88 recipe, or an operational agent adapt to a real-time process disruption, feels less like traditional programming and more like working alongside a tireless, highly capable collaborator. My role has shifted from hands-on integration to guiding and steering intelligent agents—and that shift fundamentally changes how we think about manufacturing systems. The emerging dialogue between human expertise and machine reasoning opens up an entirely new design space, one where adaptability, resilience, and scale are no longer constrained by human bandwidth.

I’m also starting to document and share some of these experiences through AI‑generated videos, another capability I’m learning to use. They’ve turned out to be a surprisingly powerful way to show what agentic systems can do—and to help others visualize these new forms of collaboration on the shop floor. It’s a learning journey in itself, but it feels like the right extension of this exploration: using AI not only to build better systems but to communicate and learn in entirely new ways.

Seeing all of this unfold up close, it’s clear we’re not just evolving automation—we’re watching Holonic concepts come alive, the manifestation of the new digital manufacturing reality.

Crossing the Digital Divide: Human-Centric Manufacturing in a Multi-Agent World

When you step back and look at what emerges from the combination of builder agents and operational agents, it becomes clear that this is not just another productivity boost or architectural evolution. It is a convergence point — one that aligns remarkably well with how manufacturing operations have always been run by humans.

Manufacturing has never been a purely deterministic, rules-based environment. It is adaptive, situational, and deeply human. Engineers design intent. Operators respond to reality. Supervisors balance constraints. Quality professionals manage risk. For decades, our digital systems have struggled to reflect this reality, forcing people to adapt to rigid models and monolithic workflows rather than supporting the way work actually happens.

Multi-agent systems change that equation by enabling digital systems to finally reflect the way manufacturing actually operates—through parallel problem solving, continuous adaptation, and coordinated decision-making across people, processes, and technology.

Builder agents mirror how engineering teams work: exploring options in parallel, iterating designs, learning from past outcomes, and continuously refining solutions. Operational agents mirror how plants operate: responding to variability, adjusting to constraints, coordinating people and materials, and managing risk in real time. Together, they form a digital system that finally behaves the way manufacturing organizations behave — collaborative, contextual, and resilient.

 

This is profoundly human-centric, because it aligns digital systems with how manufacturing teams actually operate — dynamically, collaboratively, and contextually.

It also brings into sharp focus a theme I’ve been writing and speaking about since the late1990s. For decades, we have tried to digitize manufacturing by automating tasks, enforcing standard models, and embedding rigid logic into systems. That approach delivered value, but it also created the very constraints that now limit agility, scalability, and innovation.

What we are seeing now is the realization of a different paradigm — one where digital systems augment human reasoning instead of replacing it, where composability replaces monoliths, and where intelligence is distributed across agents rather than centralized in static applications. This is the paradigm shift I’ve been pointing to for years, and it is finally reaching a practical, scalable form.

The convergence of composable platforms, agentic AI, and multi-agent collaboration marks a true inflection point. We are no longer just modernizing legacy systems. We are crossing the digital divide — moving from systems that support transactions to systems that participate in operations.

The potential here is vast! Agility, resilience, productivity, and compliance are no longer trade-offs. They become reinforcing outcomes of a system designed around human workflows, continuously learning agents, and real-world context.

This is not the end state — it’s the beginning. But for the first time, the tools, platforms, and paradigms are aligned. And that alignment is what makes this moment different from other transformative eras that came before. And it will not stop - that is why we call it continuous transformation! 

Experimenting With AI as a Creative Assistant: How I Created My Recent Videos

Over the last few weeks, I have been playing with AI as a creative assistant. Since my multimedia creative skills are - let's say sub par, I have used AI as a partner, or assistant in. The goal is to enhance content to promote knowledge sharing in manufacturing. Not AI as a replacement for expertise, but AI as a way to translate expertise into formats people actually absorb.

As part of this, I created two videos and I wanted to share the behind-the-scenes story of how I made them, what tools I used, and what I learned along the way.

Digital-First & Composable: The Future of Pharma Manufacturing Design

 

Grandpa Learns AI.

Why I’m Doing This

A few months ago, I was interviewed by a research team connected to the World Economic Forum. They’re studying the future of work and education in the digital age—specifically how people learn and adapt in environments that are changing faster than ever.

That interview got me thinking: Manufacturing is changing. Digital tools are changing. But our learning models haven’t caught up.

And if I’m being honest, my own communication style tends to be direct, dense, and sometimes… too straight to the point. Great for experts, not always great for everyone else.

So I wanted to see what happens when I let AI help me explain the concepts I care about—but in a completely different voice. So I leveraged the generative AI tools (specifically I used NotebookLM from Google for no other reason than availability - its free for now) and I’ll admit: I expected the usual AI fluff but the results was… surprisingly good.

With some well thought out prompting and iteration NotebookLM didn’t just rewrite my explanations—it transformed them into something more approachable, more story-driven, and dare I say it, more human. It brought out a teaching style that’s very different from my natural tone.

Transforming the Content

The first video was really just a "let me just feed some content and see what I get...". I recently wrote a whitepaper titled "Digital-First and Composable— A NewParadigm for ConceptualFacility Design in Pharmaceutical Manufacturing" about why its critical to take a digital first approach to the design of pharmacuetical manufacturing facilities. (Its not published publicly yet, but let me know if you are interested in a copy)

I wanted to test whether NotebookLM could help explain this somewhat deeper and more technical topic in a different way to non technical people. Basically as if you are explaining this to your grandmother. This is a known exercise that is commonly used to create a simplified and easier to understand content of technical topics. It was something I typically asked my students to do when defining their research topic, e.g. the The Feynman Technique. 

Here AI surprised me again. It took my content and created a narrative that felt clear, structured, less consultanty and was like a guided tour of the future of manufacturing It delivered the same intellectual payload—but in a format that's easier to digest for people who aren’t neck-deep in these topics every day.

For the second video I fed it the transcript from my WEF conversation about how people learn, and the AI picked up on a few of the stories that I used to exemplify how to explain new digital concepts to the industry. It took the my grandpa story  and created a story about a grandpa discovering AI for the first time. It turned a complex topic into something relatable and a little emotional. 

I shared both the whitepaper and the video I created with customers and colleagues and the feedback was that the video is by far more valuable than the whitepaper. The surprising part was that people actually learned from it. They weren’t just “getting the point.”, they were experiencing it - maybe even feeling the point. 

Why Use Personas?

One thing that became clear through this experiment is that who explains something matters just as much as what is being explained.

In manufacturing, we’re all guilty of communicating like… well, manufacturing people. Precise. Direct. Dense. Focused on efficiency. It’s great for experts, but not always for learners who don’t live and breathe MES architectures or Pharma 4.0.

This is where personas come in. Sometimes the most effective way to teach a technical idea is to have it explained by someone who is not you.

• A grandpa.
• A mentor.
• A line worker.
• A curious newcomer.
• A future digital assistant.

AI helped generate voices and storytelling styles that I simply wouldn’t have used myself. And that difference matters. It’s disarming. It opens people up. It creates emotional connection. It makes the content stick.

But—and this is important—it didn’t invent anything on its own. It worked because I gave it:

• the right context
• the right source material
• the right stories
• and a clear intention
• grounded in my decades of experience

AI can’t fabricate expertise but it can translate expertise into a form that reaches people where they are. The personas made the learning accessible and my context made it accurate. It’s a powerful combination.

What I Learned

In the end, this experiment taught me that AI can significantly expand my creative range—but only when it’s grounded in the right context. AI didn’t magically produce valuable content; it was effective because it worked with my whitepaper, my WEF interview, my research, and my own stories from years in manufacturing. When AI has that depth to draw from, it becomes an amplifier rather than a generator of fluff. 

I also realized how essential storytelling is for real learning. The emotional layer—whether it was explaining a digital-first facility as if to a grandmother or turning my grandpa anecdote into a touching narrative—made the concepts stick in a way traditional technical writing rarely does. And using personas was far more powerful than expected: having someone unlike me tell the story didn’t dilute the expertise; it made it more approachable and meaningful. What this ultimately reinforced is that AI isn’t the expert—it’s the assistant. It can translate, reframe, and humanize ideas, but only when guided by intention and supported by real experience. And that, I think, is exactly how AI will create value: by helping us communicate better, teach more effectively, and unlock new ways to share the knowledge we’ve spent years building.

Composability, Governance, and the Future of Agentic AI in Manufacturing

We’ve all heard the stories: “Somebody created a solution in just a few hours with no-code or vibe coding…”.

It’s exciting, right? Engineers solving problems in record time, building digital tools with nothing more than intuition, creativity, and a bit of AI support. This is the promise of democratization—Agentic AI empowering everyone to innovate and improve.

And in many contexts, that speed is a superpower. But in manufacturing, the story is more complicated. Operations are inherently complex: machines, materials, people, processes, schedules, quality checks, and compliance requirements all interact in a dynamic web that is nonlinear, a complex adaptive system. In such environments, even small changes can cascade unpredictably, amplifying into disruptions far greater than their cause—an inherent feature of systems where interdependencies drive emergent outcomes.

This is where the risk lies. If an unguided agent makes the wrong decision in such an environment, things can go wrong very quickly—and often in ways that are difficult to anticipate or trace. The result might be downtime, compromised product quality, production delays and at worst safety issues. But the bigger danger is cultural: when something fails spectacularly, it doesn’t just cause operational damage—it can scare the organization away from using the technology at all.

Instead of unlocking incredible productivity, one misstep can trigger a mindset of “we don’t dare do this again…”. That’s not just a lost opportunity; it’s a setback that can stall digital transformation for years.

Digital Maturity Gaps

With the incredible pace of innovation of digital technologies and specifically Agentic AI, we have to acknowledge a hard truth: most manufacturers are still not fully ready to capitalize on this technology. The foundations are often shaky, and if we introduce solutions built by and with agents into this environment without addressing the gaps, the risks multiply.

Some of the most common issues include:

• Fragmented data that prevents end-to-end visibility.
• Disconnected IT and OT systems that block seamless collaboration.
• Cultural skepticism and lack of digital maturity that slow adoption and erode trust.

These are not new problems. I discuss them in detail in this blog.  Our traditional models both in technical architecture and deployment of operational solutions for manufacturing were never designed for the agile, composable, and connected environments we’re striving to build today. In addition we can't ignore that in any given manufacturing facility there are machines and systems of varying ages and legacy status.

Consider a Scenario

An enthusiastic engineer uses vibe coding to create an agent that dispatches materials to keep machines and operators as busy as possible. At first, everything looks good, machines are running at full capacity, operators always have work, and parts move quickly into assembly.

But no one realized the agent doesn’t properly recognize WIP limits or downstream capacity. It keeps dispatching jobs even when assembly stations and testers can’t keep up. The result: piles of excess material stack up between stations, overflowing into walkways and creating unsafe conditions for operators.

In a matter of hours, what was meant to boost productivity causes overproduction, flow disruption, and a serious safety hazard. The line is forced to stop because the system created too much of it, in the wrong place, at the wrong time. 

This isn’t hypothetical. It’s the kind of risk that emerges when Agentic AI is unleashed without governance. And unlike traditional tools, agents can act autonomously and at scale, amplifying errors at a speed we may not be able to react to.

Managing Complexity with Composability: Governance, Framework & Platform

Given this reality—where digital maturity is uneven, legacy systems abound, and the dynamic nature of manufacturing operations—the arrival of Agentic AI presents both an enormous opportunity and a serious risk. Agents are coming at us fast, and their power lies in democratization and speed. But those same qualities, in an environment as sensitive as manufacturing, can amplify problems just as quickly as they solve them.

This paradigm shift cannot be left to chance. To harness Agentic AI safely and effectively, we need to approach it in an organized, managed, and focused way. That requires: governance, framework, and platform all working together and grounded in composability.

• Governance gives us the rules, guidance, and guardrails to ensure reliability, safety, quality, and compliance are never compromised. Governance is not just about control; it actively helps organizations overcome barriers like fragmented data, siloed systems, and cultural skepticism by providing structure, discipline, and confidence. Done right, it helps in the transformation of the manufacturing environment from both a technical readiness (data integrity, system integration) and an organizational readiness (culture, mindset, trust).

• Framework provides the structure to make governance actionable. In A Composable Agentic Framework for Frontline Operations, I laid out how agents can be defined by type, given clear goals, and aligned through the artefact model. The framework ensures that agents are not just scattered tools but part of a purposeful, multi-agent system that reflects and supports real operations.

• Platform is the enabling layer. An Agentic manufacturing operations platform purpose-built for frontline operations makes it possible to apply governance and framework seamlessly—across both authoring (building digital solutions) and execution (running the production line). Unlike generic vibe coding environments, such a platform is designed specifically for process engineers and operations teams. It embeds an understanding of how manufacturing works—constraints, variability, compliance, and safety—and provides tools to build solutions quickly while remaining aligned with operational best practices. Most importantly, it enables the creation and deployment of operational agents at scale that are are integral parts of the production system itself.

And underlying all of this is composability. Composability ensures that agents and solutions don’t exist in isolation, but as modular, human-centric, bottom-up elements of a system that adapts as needs evolve. Digital transformation success depends on treating composability not as an IT concept, but as an operational paradigm. In fact, composability was conceived for multi-agent systems (MAS)—and Agentic AI now makes that vision practical.

Final Thoughts

I think that we all agree that Agentic AI despite all the hype is not a fad—it’s here, its real and it’s already reshaping how work gets done. But to harness it safely and effectively, we need to recognize the two distinct scenarios where agents play a role:

1. In building and engineering: where agents help create digital content, processes, and solutions. Here, governance ensures what gets built is valid, safe, and aligned with operational goals.

2. In live operations: where agents support and even run production activities, interacting with machines, data, and humans in real time. Here, governance ensures reliability, compliance, and resilience in execution.

Both scenarios are powerful—they are needed but both also carry risks if unmanaged. And in manufacturing, where operations are complex and dynamic, small missteps can cascade into detrimental consequences.

That is why governance, framework, and platform are critical. Governance provides the rules and guardrails; the framework gives agents structure, goals, and alignment through the artefact model; and the platform operationalizes it all, giving process engineers and frontline teams the environment to deploy agents as integral parts of the production system, and all of this at scale.

And beneath it all is composability. As I’ve argued before, composability was conceived for multi-agent systems—modular, autonomous, and collaborative components working toward shared goals. Agentic AI now makes that vision practical on the shop floor.

The challenge ahead is not whether manufacturers will adopt Agentic AI, but whether they will do so in a way that balances speed with safety, democratization with discipline, and autonomy with alignment. Done right, it promises resilience, reliability, and the kind of productivity gains that digital transformation has always aspired to deliver.

---