Manufacturing procurement runs two very different kinds of purchasing through the same team. MRO spend, the bearings, filters, and replacement parts that keep a line running, is unplanned, urgent, and scattered across dozens of small suppliers. Direct spend, the raw materials and components that go into the product itself, is planned, contracted, and tied tightly to production schedules. Most procurement software is built for one or the other. Plants need both handled well, often across multiple facilities that don't share a purchasing system.
MRO and direct spend behave like different jobs. An MRO request for a replacement part often starts as "the line is down and we need this part today," with the requisition, approval, and order compressed into hours. A direct-spend purchase order for a raw material tied to a production run is planned weeks or months out, against a contracted price and a qualified supplier list. Treating both with the same approval workflow either slows down urgent MRO buys or lets direct-spend purchases skip controls they actually need.
Purchasing is decentralized by plant, and that's not a bug to fix. A plant manager or maintenance lead often has local purchasing authority for MRO spend up to some threshold, because waiting for corporate sign-off on a $200 part while a line sits idle doesn't make sense. That decentralization is usually correct. It also means spend visibility and supplier data fragment across plants unless something actively reconciles it.
Vendor master data multiplies across sites. The same supplier might be onboarded separately at three plants with three slightly different records, three different negotiated terms, and no single view of total spend with that vendor across the company, which is exactly the condition that produces maverick spend and missed volume discounts.
Zamp's AI employees for procurement are configured against each plant's actual purchasing policy through an Agent Operating Procedure: what a given role or plant can approve without escalation, which categories always require sourcing review, and which supplier and pricing data source is authoritative when plant records disagree. Because plants genuinely do have different authority thresholds and supplier relationships, the AOP is written per deployment rather than assuming one policy fits every site.
On the systems side, Zamp connects to whichever procurement, ERP, or vendor-portal systems a given plant actually runs through APIs, custom MCP servers, or browser automation for portals that don't expose one, so a purchasing agent covering three plants on three different ERP instances isn't rebuilt three separate times. A Company Brain shared across the deployment means vendor and pricing data gathered at one plant is available when the same supplier shows up at another, which is what actually closes the maverick-spend gap decentralized purchasing tends to create.
Every purchasing agent runs under its own identity with access scoped to its specific role and spend category, and approval thresholds are enforced at the point of action, not just documented in a policy no one checks. A request that falls outside a plant's normal pattern, a new supplier with no history, a price significantly above the last quote, an MRO request routed as if it were direct spend, gets flagged Needs Attention with the specific reason attached, rather than either auto-approved or blocked outright. Every requisition, approval, and purchase order is logged with the reasoning behind it, so a procurement lead can review spend patterns across every plant from one place instead of pulling separate reports per site.
For the finance side of manufacturing operations, see AI Agents for Manufacturing Cost Accounting. For the full picture of how this fits into a manufacturer's broader AI employee deployment, see AI Employees for Manufacturing.
