Enterprise enthusiasm for AI agents is real and accelerating. But most of the early deployment experience rests on a dangerous assumption: that the enterprise IT systems beneath the agents can stay exactly as they are. For technology decision makers in industries where a missed compliance flag or a misfired transaction can shut down a production line, that assumption is not a starting point — it is a liability. Before your organization commits to an agent strategy, it is not enough to ask which agent to choose. Rather, you must ask whether your systems are ready to support an agent, and whether your governance model is ready to oversee it.
For most manufacturing and industrial businesses, ERP is not merely one of many enterprise applications. It is the operational backbone — the authoritative source of truth for financials, production, inventory, procurement, and compliance. When ERP produces bad outputs or acts on incomplete information, the downstream consequences can be immediate and broad. That is why introducing any new technology into a mission-critical ERP system — including AI agents — requires substantial planning.
This is also why so many customers approach ERP changes with caution, particularly in the mid-market where resources are more limited and implementation timelines leave less room for error. In my experience, many manufacturers are running ERP systems they implemented a decade or more ago, long before AI agent readiness was a consideration for anyone. These systems were built to record and report reliably, and they do that well. The question today is whether the agent layer deployed on top has been designed with enough understanding of those systems and the business processes they support to function correctly.
Purpose-built agents are designed to address this directly. It is not that general-purpose agents lack capability in the abstract — many are genuinely useful in the right context. It is that ERP workflows carry institutional logic that takes time to learn: why a particular approval sequence exists, which exceptions require human judgment, how a compliance requirement interacts with an operational decision. Agents designed with that domain expertise built in are better positioned to add value in ERP environments and to avoid the kinds of errors that are easy to miss and expensive to reverse.
The agents most people have interacted with so far are human-centric: They assist a person with a specific task, produce an output, and hand it back for review. An agent that schedules a meeting, drafts a supplier communication, or summarizes an audit report is useful and relatively low-risk. If the output is wrong, a human catches it before anything breaks. The consequence is, at worst, wasted time.
But now, a different class of agent is moving into enterprise environments. These agents do not merely assist humans. They interact directly with systems, initiate transactions, coordinate across platforms, and trigger real-world actions. For instance, an agent managing a component shortage in an automotive assembly environment needs to access live inventory data from multiple tier-one suppliers, cross-reference demand sequences from the OEM, evaluate qualified alternatives against specs, model the downstream impacts on production scheduling, and surface a recommendation — or in some configurations, act on its own recommendation. That is not simply automating a human task. That is operating inside business-critical infrastructure at a level of complexity and consequence that earlier human-centric agents were never designed to handle.
Technology decision makers need to know very clearly which category they are deploying before they configure a single parameter.
The assumption driving most enterprise agent deployments is that the underlying system can remain static while agents do the heavy lifting. In a field like automotive manufacturing, where a supplier substitution, a production sequence change, or a quality release decision can cascade across a just-in-time supply chain, that assumption is wrong. The consequences are not recoverable with a quick patch.
It’s worth pointing out the meaningful difference between a system of record and a system of action. A system of record stores, validates, and reports information. A system of action reasons, decides, and executes. Agents require the latter. If your ERP or manufacturing execution system was not engineered for agentic interaction — with real-time data access, event-driven architecture, deterministic transaction support, and appropriate guardrails — you have not actually deployed an AI capability. You have simply added a category of new ways for things to go wrong — at speed.
Consider what this looks like in practice. An automotive OEM is managing a sudden shortage of a single electronic control unit feeding three vehicle lines. The agent is tasked with identifying an alternate qualified supplier, modeling the production impact, and initiating a re-sequencing recommendation. Each of those steps requires the underlying system to expose authoritative, live data and handle the resulting transaction reliably. A legacy ERP that only syncs on a batch schedule, or cannot expose supplier qualification status via API, or lacks the controls to support a mid-run sequence change is not a foundation for that workflow. It is a failure point dressed up as an AI deployment.
Deploying agents without first assessing system readiness is not an AI strategy. It is a risk transfer from the vendor to the operator.
Even when systems are properly set up, not every agent action should be autonomous. The question technology decision makers must answer before deployment — not after an incident — is which tasks can be safely delegated and which require a human decision point.
To figure this out, evaluate consequence and reversibility together. Agents can and should operate autonomously on tasks that are low-consequence and easily reversible, e.g. flagging a delivery anomaly, pre-populating a nonconformance report, or generating a draft response to a quality inquiry. As consequence rises and reversibility shrinks, human oversight becomes a hard requirement, not a design preference.
Staying with the example of automotive manufacturing, the lines are clear in principle, if not always in practice. An agent can autonomously reorder standard consumables against a replenishment rule. But it should not autonomously approve a supplier substitution for a safety-critical component. That decision carries implications for IATF 16949 (the international automotive quality management standard), potential customer-specific requirements, and liability exposure that a qualified engineer needs to own. An AI agent can flag that a mixed batch may be out of specification, but a human quality manager should authorize the hold before that batch is sequenced to the line.
The harder problem is making those human interventions meaningful. “Human in the loop” is often designed as a notification rather than a genuine control point. The approver receives an alert, lacks the context to evaluate it properly, and approves it on reflex. For agent governance to function correctly, the underlying system must surface the right information to humans at the right moment. That is an infrastructure requirement, not just a UI design choice.
The governance challenge discussed here connects directly to a broader question about where agent autonomy is actually headed. I explored the distinction between agent self-direction (where humans provide context and direction) and true autonomy (where an agent acts without human input) in an earlier piece: “Will Autonomy Break AI Agents? Here Are The Likely Scenarios” — Jason Andersen, Moor Insights & Strategy, October 2, 2025. Most enterprise deployments today sit firmly in self-direction territory, which makes governance design all the more important now, before autonomy raises the stakes further.
Once system readiness and governance requirements are understood, the sourcing decision becomes more tractable — but it must be reframed. The question is not simply first-party versus third-party. It is whether the agent was purpose-built for the ERP environment it will operate in, or whether it is a general-purpose agent being asked to perform domain-specific work it was not designed for.
Purpose-built agents, whether developed by the ERP vendor or by a specialist third party with deep domain expertise, carry the knowledge of the underlying business processes, data structures, and compliance obligations baked in. A generic agent does not. The generic agent may perform well on straightforward tasks, but when it encounters the edge cases that define manufacturing and supply chain operations (a quality hold that conflicts with a customer commitment, a supplier substitution that touches a safety-critical specification, a compliance record that requires an unbroken audit trail), a generic agent is not equipped to navigate them correctly. The consequences of getting those moments wrong are not correctable with a prompt revision.
Third-party purpose-built agents can be the right choice when the ERP vendor’s own agent does not accommodate the industry-specific customizations an operation depends on; when the workflow spans multiple systems or partner environments that a single-vendor agent cannot traverse; or when the vendor’s roadmap does not align with operational timelines. In my experience tracking enterprise software deployments, first-party agent capabilities that are still a year or more away from what an enterprise needs today are not a solution for today’s operational problem. To put it another way, a vendor roadmap should inform strategy, but it should not hold operations hostage when capable alternatives exist now.
Technology decision makers evaluating an agent initiative should be able to answer each of the following before a deployment decision is finalized.
The infrastructure requirements, governance models, and risk profiles for these differ substantially. Applying human-centric standards to a system-integrated ERP workflow is where most early deployment failures originate.
A generic agent that handles scheduling or content generation is not qualified by extension to reason about production sequencing, quality holds, or supplier qualification. Verify that the agent carries deep knowledge of your industry’s business processes, data models, and compliance obligations — not just general AI capability.
Map use cases against consequence and reversibility. Establish those boundaries in policy before encoding them in configuration.
Real-time data access, event-driven architecture, deterministic transaction support — the agent will only be as reliable as the system beneath it. For mid-market ERP environments running older systems, assess this honestly before committing to a deployment.
In automotive manufacturing, agent-driven decisions touching safety-critical components, quality releases, or supplier qualifications may need to satisfy IATF 16949 requirements, customer-specific quality agreements, or functional safety standards. Confirm compliance before go-live, not during a customer audit.
If the process spans your ERP, a manufacturing execution system, a logistics provider, and a tier-two supplier, a single-vendor agent may lack the visibility to manage it reliably. And if the capability you need is still a year or more out on the vendor’s roadmap, do not let that delay an improvement that is achievable today.
For enterprise technology decision makers, the sequence of evaluation matters more than the specific technology deployed. Start by understanding what kind of agent you are deploying. Assess whether your systems can support it. Define where humans need to stay in the loop, and make those interventions real. Then decide who should build the agent. Organizations that follow this sequence will deploy with less operational risk, meet compliance requirements in regulated environments, and build agent programs that hold up past the pilot stage.
One honest caveat: Organizations with strong compensating controls — manual checkpoints, exception-handling workflows, parallel system monitoring — can sometimes bridge system readiness gaps in the near term. That approach can work. It does add operational complexity and cost, and it tends to fail at scale or under time pressure, but it is not inherently reckless. The question is whether it is a deliberate bridge chosen one time or a permanent workaround.
ERP and manufacturing platform vendors should take note as well. Systems not architected for agentic interaction — with robust APIs, real-time data exposure, and deterministic transaction controls — are creating an opening for third-party agents and, ultimately, for platform substitution. The vendors that move to make their systems agentic-ready are not just improving agent outcomes for current customers. They are also closing the door on the competitive threat that the sourcing question represents.
Agents deployed without deep ERP expertise carry substantial risk of failure. The systems beneath them and the governance around them matter enormously — but they are not sufficient substitutes for purpose-built capability. Get the agent right. Get the system right. Get the governance right. In that order.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。