Scaling AI Agents Across Multiple Manufacturing Plants
Scaling an AI agent across plants means separating the agent's core logic from everything that varies by site, then rolling out in a sequence that makes each deployment cheaper than the last. Plant two is almost always harder than plant one, because plant one's agent quietly absorbed dozens of site-specific assumptions: local item numbering conventions, a custom SyteLine form nobody documented, a different ERP instance or version, a language, and a set of local workarounds that exist in nobody's process map. The fix is architectural separation plus a deliberate rollout order, not more engineers.
Why Plant Two Is Harder Than Plant One
The first agent is built with the first plant's people, data, and habits in the room, so site-specific logic gets embedded without anyone noticing. Then plant two turns out to run a different ERP version, uses a different unit-of-measure convention on the same part family, has a custom field in a different position, routes approvals through a plant controller instead of a buyer, and operates in a language the prompts were never tested in. Multi-instance ERP landscapes make this worse: if plant two runs its own SyteLine database with locally added Uf_ columns, the integration layer needs configuration rather than a copy. Expect plant two to cost 50 to 70 percent of plant one, and plant five to cost 15 percent.
Separate the Core Agent From Site Configuration
Refactor after plant one, before plant two, while the site-specific assumptions are still fresh. Everything that varies moves into a per-site configuration file under version control: ERP endpoint and credentials, field and object mappings, approval routing, language, thresholds, and any local terminology. The core agent, prompts, tool definitions, and evaluation harness stay shared. The test of a good separation is simple: onboarding a new plant should require editing a config file and running the evaluation suite against that plant's data, with zero changes to core agent code. If a new site needs a code fork, you have built five agents rather than one agent deployed five times.
- Per-site config file holding ERP endpoints, object and field mappings, and credential references
- Site-specific approval routing and confidence thresholds as configuration, never as forked prompts
- Shared core prompts and tool schemas in a single repository with one release pipeline
- New-site onboarding acceptance test: config edit plus evaluation run, zero core code changes
A Rollout Sequence That Compounds Instead of Sprawling
Sequence for learning, not for politics. Plant one should be a willing site with clean data and a strong local champion. Plant two should be deliberately different, ideally a different ERP instance, region, or product line, because that is what forces the configuration separation while you still have budget and attention. Plants three through five are then throughput, running two to four weeks each. Resist the pressure to launch four sites simultaneously after a successful pilot: parallel launches produce parallel firefighting with no shared learning, and the site-specific issues arrive faster than the small central team can resolve them. Publish site-level adoption and accuracy metrics so plants can compare themselves.
Governance, Prompt Libraries, and Shared Evaluation Sets
Multi-site scaling fails on governance more often than technology. Decide explicitly who can change a shared prompt, how a site requests a variation, and what evidence is required before a change ships to all plants. Maintain one evaluation set per site drawn from that site's data, and run all of them on every core change, because a prompt tweak that improves accuracy in Ohio can regress it in Monterrey. Keep a shared library of reusable agent patterns with the evaluation results attached, so plant four is choosing from proven components rather than starting a design conversation from scratch. Give sites a documented path to request a variation, with a stated turnaround, because an unanswered request becomes a local fork within a month.
- One named owner for shared prompts, with pull request review and a documented variation request path
- Per-site golden evaluation sets, all executed on every core change before promotion
- Shared pattern library with attached evaluation results, not just prompt text
- Weekly per-site scorecard: adoption rate, escalation rate, override rate, and accuracy trend
How Netray Runs Multi-Site AI Agent Rollouts
Netray builds the site-configuration separation into the first deployment rather than refactoring after plant two hurts, and we deliberately choose a structurally different second site to force the abstraction early. We deliver per-site evaluation sets, a shared pattern library your team owns, and a governance model covering prompt change control across sites. For groups running multiple SyteLine, LN, or M3 instances, we handle the mapping layer so a single core agent serves heterogeneous ERP landscapes and version differences do not force a fork. Clients typically see plant two cost roughly half of plant one and plants four onward land in two to four weeks each, with a per-site scorecard published from the first week of each launch.
Frequently Asked Questions
Why is the second plant harder than the first for AI agent rollout?
Because the first agent silently absorbed site-specific assumptions: local item numbering, undocumented custom forms, a different ERP version, unit-of-measure conventions, approval routing, and language. Plant two exposes all of them at once. Refactor after plant one and before plant two, moving everything variable into a per-site configuration file. Expect plant two to cost 50 to 70 percent of plant one and plant five around 15 percent.
Should you roll out an AI agent to all plants at once?
No. Parallel launches produce parallel firefighting with no shared learning, and site-specific issues arrive faster than a small central team can resolve them. Sequence deliberately: a willing site with clean data first, a structurally different site second to force the configuration abstraction, then two to four week rollouts for remaining sites. Publish per-site adoption and accuracy metrics so plants can compare themselves.
How do you manage prompts across multiple manufacturing sites?
Keep core prompts and tool schemas shared in one repository with a named owner and pull request review, and push everything site-specific into configuration. Maintain a golden evaluation set per site from that site's own data, and run every set on every core change, because a prompt improvement at one plant can regress another. Track a weekly per-site scorecard for adoption, escalation, override rate, and accuracy.
Key Takeaways
- 1Why Plant Two Is Harder Than Plant One: The first agent is built with the first plant's people, data, and habits in the room, so site-specific logic gets embedded without anyone noticing. Then plant two turns out to run a different ERP version, uses a different unit-of-measure convention on the same part family, has a custom field in a different position, routes approvals through a plant controller instead of a buyer, and operates in a language the prompts were never tested in.
- 2Separate the Core Agent From Site Configuration: Refactor after plant one, before plant two, while the site-specific assumptions are still fresh. Everything that varies moves into a per-site configuration file under version control: ERP endpoint and credentials, field and object mappings, approval routing, language, thresholds, and any local terminology.
- 3A Rollout Sequence That Compounds Instead of Sprawling: Sequence for learning, not for politics. Plant one should be a willing site with clean data and a strong local champion.
Put this into numbers
Free interactive tools for exactly this problem. No signup to use them.
AI Agent Security Review Checklist
A 30-point security review for AI agents that can call tools and write to business systems, covering identity, permissions, prompt injection, data handling, and audit.
Free ToolAI Center of Excellence Setup Checklist
A 32-point checklist for standing up an AI Center of Excellence that delivers working systems instead of slide decks, covering charter, funding, platform, governance, and adoption.
Free ToolRPA vs AI Agent Selector
Answer nine questions about a specific process and find out whether classic RPA, modern AI agents, or a hybrid of both is the right automation approach.
Terms used in this article
Rolling an AI agent out across multiple plants or ERP instances? Netray will design the site-configuration architecture and rollout sequence before plant two becomes a rebuild.
Related Resources
Building an AI Center of Excellence in Manufacturing
Build an AI center of excellence in manufacturing: staffing, intake and prioritization, reusable agent patterns, and funding models that survive budget cycles.
AI & AutomationFrom AI Pilot to Production: The Playbook
Move an AI pilot to production: environment promotion, monitoring, rollback plans, and the ERP integration hardening manufacturers need before go-live.
AI & AutomationAI Change Management on the Shop Floor
AI change management on the shop floor: how to introduce agents to operators and planners without stalling production, with training, comms, and rollout steps.