Getting Return on AI in Manufacturing Operations

Manufacturers have spent this year under pressure to put AI into their operations and to show what it returned. Margins are tighter, so investment arrives in increments rather than as a single transformation budget, and every increment is expected to produce a measurable result.

The return has been uneven, and not because the technology underdelivered. Producing a first version of a solution has become faster. Verifying it, connecting it to data the team trusts, and standing it up at a second site takes the effort it always did. Which means the question changed. Not whether AI can build something, but what has to be true before what it builds can be trusted, audited, and run in more than one place?

Three pressures are setting the agenda for the operations leaders we work with.

Capital is moving into new production lines faster than IT can support them. So a line often starts producing before the systems meant to run it are in place.

Productivity has to come from the team already there. Not from a headcount increase, and not from a significant software or hardware purchase.

Most manufacturers already know what needs to change. Being measurably better off is a different problem, and this year, it's the one that gets funded.

For an operations leader, the question is no longer whether AI can draft a solution or read a data set. It is what has to be in place before what it produces can be trusted, audited and run at more than one site.

Building a solution means turning what the operation knows into something it can run: the steps, the logic, the data connections, and the checks that keep the work compliant. That work has always depended on the people who understand the process, and most of their day went to assembly rather than judgment. AI removes a good share of the assembly and leaves the judgment where it was. It increased the output without changing who has to review it.

Running the operation means acting on data held in systems built to do different jobs. A scheduling system holds what was planned, a machine controller holds what ran, a paper record holds what the operator observed, and a spreadsheet holds what someone decided to do about it. None of them exchanges data with the others, so the knowledge stays where it was created and people reconcile the accounts by hand before anyone can decide anything.

That reconciliation is the part that does not survive automation. A person can reconcile two systems that disagree because they know which source to trust. An agent cannot. It either declines to answer or returns a confident answer that is wrong.

Scaling means taking a solution proven at one site to the rest of the network. A fix validated at one plant often never reaches the others, so the same problem gets solved five times in five places. And without a record of where each copy came from, a central team can confirm that something is running at a site but not whether it is the current version.

Why the relevant experience isn't AI experience

None of the three is an AI problem. Each is a question of what surrounds the AI: who approved it, what data it read, and which version is running where.

Tulip has spent more than a decade in operations where a mistake carries consequences, like pharmaceutical, medical device, and defense manufacturing. Permissions, approvals and audit trails were built into the platform long before there was an agent to govern, which means AI arrives inside the oversight your team already works under rather than alongside it. Nothing in the existing stack is replaced.

Building: from assembly to judgment

Engineers and builders have always used the tools that best solve their problems, be it paper, spreadsheets, and eventually, digital applications. AI is the next one, doing the same job.

Regardless of the tool, the processes that survive were those designed by those who best understood their own operations. To solve bottlenecks between access to tools and operational knowledge, we built the Authoring Agent. The Authoring Agents works inside the application editor, drafting a working solution from the documents the operation already maintains, including SOPs and work instructions, and editing that draft on request.

What changes is where the expert's day goes. Rather than assembling steps, logic, data connections and compliance checks by hand, the people who know the process decide what the solution should do. When a draft comes back close to right, they change the field themselves instead of filing a request and waiting for capacity.

The faster solutions get built, the more of them there are and a change to one can break another before anyone realizes the two were connected.

Projects are where the whole system gets designed rather than one app at a time. The apps, data structures, automations and connections serving a single use case are held together and mapped to the physical area they support, so the relationships between use cases are explicit rather than assumed. A change can be assessed against the system it belongs to. And a solution proven once moves as a single versioned unit rather than a set of parts someone reassembles at the next site.

Running on a single record

The scheduling system, the machine controller, the paper record and the spreadsheet only become one record if something puts them on the same terms.

Tulip’s industrial connectivity capability links devices and business systems natively, over standard industrial protocols. It then puts their output on common terms, so a work order, a machine state, a lot and an operator action carry the same definition in every app, dashboard and agent. Machine data can then be queried against order records, defect codes and station activity. That is what lets a team correlate scrap with changeovers, or defects with a shift or a material lot, without building the integration first. High-frequency readings are aggregated at the edge before they leave the site, so only what the analysis needs travels.

Factory Playback treats the cameras already installed on a production floor as an operational data source. Footage is aligned to the same timeline as machine and order data, so an investigation starts from the video attached to the record rather than from recollection .The past can be searched for events nobody configured an alert for, because a vision language model interprets what is in the frame rather than matching a rule set up in advance. The same cameras answer new questions without new hardware: counts at a workbench, dwell time in a zone, whether a station is active or idle.

Agents act on that combined record. They answer questions from it, produce the analysis when one is requested, and run on a schedule rather than waiting to be asked. The organization sets which actions an agent takes on its own, which require approval and which are prohibited. The people who know the process put their experience into the decision rather than the reconciliation.

Scaling with Control

Governance does three jobs: visibility, control and trust.

OpsMoto provides visibility. It brings deployments, apps, automations and user activity across every site and instance into one view, and records the lineage of each solution. A central team can answer which sites run which version, and where one has diverged. Compiling that picture otherwise means logging into each instance in turn.

OpsMoto also runs independently of the core platform release cycle, which means adopting it, and updating it, does not put a validated system back into revalidation.

Enterprise Library provides control. A central team publishes an approved solution once, and each site installs the current version from a browsable catalog rather than receiving a file to import by hand. A fix vetted once reaches the whole network. And each site can adapt what it installed to the local process without losing the link back to the template, so local fit stops costing central visibility.

Trust is not a product. It is the condition the rest operates inside: where data sits, how it is secured, and what AI is permitted to do. Those are the controls the operation already relies on in regulated and secure environments, not a separate set written for AI.

Two days with manufacturers who are getting return on AI now, and who will tell you what it cost them to get there. You can put an idea in front of someone who has already tried it and hear where it broke.

The demo floor is hands-on across all three. You build a solution from an SOP. You work with connected machines and video data. You move a solution between sites and see what the central team sees.

The sessions follow the same arc: teams in the middle of a rollout, central teams governing a network, and the engineering work of running AI against a live production floor.

Operations Calling is in Somerville, October October 6-7, and Lyon, November 3-4. The capabilities are what we will show. What they returned is what the manufacturers in the room will tell you. Get your ticket today!