The infrastructure being built for AI agents won’t work in your factory. Here are five governance questions manufacturing needs to answer before adopting agents.
Something significant happened in the world of AI this month. It might have been overlooked by most manufacturing executives because it looked like consumer tech news.
OpenAI acqui-hired the creator of OpenClaw, a new and wildly popular open-source AI agent framework. OpenAI then created an independent foundation as the new home of OpenClaw. Days later, Meta acquired Moltbook, a startup that recently launched what amounts to a social network for AI agents. Meta folded the team into Meta Superintelligence Labs. Taken separately, each move is strategic for the buyer. Together it signals that the titans of AI are determined to control all elements of the emerging Intelligence platform stack, including what some are calling the “agent internet.”
This infrastructure gold rush is real and consequential. And it is being built entirely without manufacturing in mind.
The rise of agents in manufacturing
AI agents are software systems that can plan, act, and hand off tasks autonomously across tools and systems. A year ago almost no one in industrial software was talking about them. Now they are beginning to appear at the edges of PLM workflows, ERP integrations, and engineering change processes at major manufacturers. The vendors selling into those environments are adding agent capabilities to their platforms. The enthusiasm is genuine and, in many cases, the early results are promising.
Enthusiasm for agents is running ahead of governance. The agent internet being constructed by OpenAI, Meta, and their peers is designed for a world of relatively low-stakes, general-purpose tasks. Manufacturing is the opposite: high-stakes, heavily regulated, deeply audited, and institutionally conservative. It is not resistance to innovation per se; it is about preventing everything that might happen when things go wrong.
Nobody is building the governance layer that regulated manufacturing actually requires. Not the consumer tech companies, who don’t think in these terms. Not the PLM incumbents, who are treating agents as product features rather than as an interoperability and accountability problem. Standards bodies are at the starting gate, exploring how to govern AI for manufacturing systems. That process, when it concludes, will produce something valuable. It will also take years.
This article proposes five questions that manufacturers, vendors, and standards participants need to answer before AI agents can be responsibly deployed in regulated production environments. They are not rhetorical questions; they are the load-bearing problems of agent governance in manufacturing.
Five questions that need answers
What follows are not predictions about where manufacturing AI is headed. Instead, there are questions about the problems that already exist, today, wherever an AI agent has been given authority to act inside a production workflow. The agent vendors don’t have agreed upon answers. Neither do the PLM incumbents. Neither does any standards body. Think of it as the governance gap.
1. Identity: who authorized this agent to act?
When someone initiates an engineering change, there is an accountable person attached to that action. Their credentials were verified. Their authorization level was checked against the workflow. Their name goes on the record.
When an AI agent initiates the same action, none of that is guaranteed. The agent infrastructure being built by the consumer tech industry provides mechanisms for agents to identify themselves to each other. It does not provide mechanisms for verifying that a specific agent was authorized by a specific human to act within a specific regulated workflow.
In a regulated manufacturing environment, this is not an edge case. It is the threshold question. Until it has a vetted and pre-approved answer, every agent acting inside a production workflow is operating on implicit trust rather than verified authorization.
2. Auditability: can you prove the path, or just the act?
Regulated manufacturing environments require audit trails. This is not bureaucratic preference; it is a legal and certification requirement in aerospace, defense, medical devices, and automotive supply chains, among others.
Current AI agent frameworks can log that an action occurred. What they cannot reliably reconstruct is the full chain of reasoning, authorization, and inter-agent communication that produced the action. In a compliance context, proving the act is necessary but not sufficient. You need to prove the path: the data that triggered the agent, its chain-of-thought reasoning, the version of the model at that moment, and the credentials that authorized it. Every decision point, every handoff, every instruction that led from a human intent to an agent-executed outcome must be accounted for.
No current agent framework, consumer or enterprise, has solved this for regulated manufacturing. Some are beginning to think about it. Until the industry can answer how it will capture and verify the path to the satisfaction of standards compliance auditors, every AI agent operating in a production workflow creates compliance risk, not operational value.
3. Containment: where are the boundaries, and who enforces them?
Manufacturing data is not generic. A single product development workflow can contain geometry files that trigger ITAR export controls, supplier pricing data protected by NDA, proprietary process parameters that represent years of competitive advantage, and personal data governed by privacy regulation. In a human-operated environment, access controls and security clearances manage who can touch what. The boundaries are imperfect but they exist.
AI agents complicate this in a specific way. An agent executing a multi-step workflow doesn’t request access to data the way a human does. It only ingests what it needs to complete the task. In a poorly governed implementation, it may pass that data to external services, other agents, or cloud-based model infrastructure outside the authorization boundary. Not maliciously, but only because nobody defined where the boundary was.
The consumer agent infrastructure being built right now was not designed with manufacturing-grade containment in mind. Questions regarding what data an agent is permitted to access, retain, and transmit — as well as permission enforcement — have no agreed answer in any current agent framework.
Until containment is addressed, deploying agents inside regulated manufacturing workflows is an exercise in trust. Trust is not a governance model.
4. Handoff: does a transfer of work constitute an approval?
In a regulated manufacturing workflow, moving work from one stage to the next is not a neutral act. A handoff is an implicit declaration that the work is ready for what comes next. In human-operated workflows this is formalized: sign-offs, stage gate reviews, approved supplier lists, drawing releases. The handoff is a conformance event, not just a coordination event.
AI agents hand off work differently. In current agent frameworks, a handoff is essentially a data transfer with instructions attached. The sending agent passes its output to the next agent or system and moves on. There is no inherent conformance check. There is no verification that the output meets the specification requirements of the next stage. There is no human sign-off unless one is explicitly engineered into the workflow. In most current implementations, it isn’t.
This matters most at the boundaries between systems. When an agent completes a task in a PLM environment and passes the result to an ERP or MES system, it is crossing a boundary between systems of record that were designed with human gatekeepers in mind. Removing those gatekeepers without replacing them with an equivalent governance mechanism doesn’t streamline the workflow. It removes a control that exists for regulatory and quality reasons.
The question is not whether agents can execute handoffs efficiently. They can. The question is whether an agent-executed handoff constitutes a valid approval event in a regulated context. If so, what makes it valid? Who defined that standard? Where is it recorded?
5. Failure: when an agent gets it wrong, who is responsible?
Every manufacturing workflow fails sometimes. A human makes an error, a process breaks down, a part doesn’t meet spec. Regulated manufacturing environments have well-developed mechanisms for handling this: nonconformance reports, corrective action processes, root cause analysis, and clearly defined accountability chains. When something goes wrong, there is always a person whose name is attached to the decision that caused it.
AI agents introduce a failure mode that existing accountability structures were not designed to handle. When an agent executes an incorrect action, the question of who bears responsibility is genuinely unresolved. It might be a change to the wrong revision, the passing of non-conforming data through a stage gate, or the triggering of a procurement event based on misreading a specification. Who is responsible? The developer of the agent framework? The vendor who deployed it? The manufacturer who authorized it to act? The human who approved the workflow design?
The problem compounds when multiple agents are involved. In a multi-agent workflow, an error introduced early may not surface until several handoffs later, by which point reconstructing the origin requires exactly the kind of path auditability that question two identified as currently unsolved. Failure and auditability are not separate problems. They are the same problem from opposite ends.
Rollback is equally unaddressed. In a human-operated workflow, reversing an incorrect action is procedurally complex but conceptually straightforward. If someone made a mistake, someone corrects it, the record reflects both. In an agent-operated workflow, rollback requires that every action was logged with sufficient fidelity to reverse it cleanly, that the systems touched by the action support that reversal, and that the accountability chain remains intact throughout. No current agent framework provides this for regulated manufacturing environments.
Until the industry defines what agent failure looks like, who owns it, and how it gets corrected, deploying agents in production workflows is not automation. It is risk transfer from the vendor to the manufacturer and ultimately to the end user.
Who builds the gate?
The barbarians aren’t at the stage gate. They’re already on the shop floor, and nobody checked their credentials.
AI agents are now entering manufacturing environments. Not in some future state, not in a pilot program at a forward-thinking OEM, but in the workflow tools and platform updates that manufacturers are already running. The consumer tech industry is building the infrastructure that underlies them at remarkable speed. That infrastructure is genuinely impressive. It was also designed for a different world.
The five questions in this article are not a checklist for slowing down adoption. They are the minimum threshold for responsible deployment. Identity, auditability, containment, handoff, and failure are not edge cases to be addressed in a future product release. They are the load-bearing problems of agent governance in manufacturing, and right now none of them have agreed answers.
The standards process will eventually produce answers. It will take years. In the meantime, manufacturers are making deployment decisions, vendors are shipping agent-enabled products, and the governance gap is widening with every release cycle.
Forward this article to the person in your organization who should be asking these questions. If you can’t think of who that is, you have your first problem to solve before turning the AI agents loose.
This article is the first in a series on AI agent governance in manufacturing. To receive the follow-on framework document when it publishes, send an email to randall@consiliavektor.com with “Agent Governance” in the subject line. Subscribe to Consilia Vektor to be notified of new articles.
Your comments are welcome