AI agents in manufacturing: ten examples from service, quality and procurement

An AI agent in a manufacturing company is software that uses a language model to take over one step of an existing process, acting in the systems where the work sits: the ERP, such as SAP S/4HANA, the CRM, the ticket system or the QM system. The ten examples of AI agents in manufacturing below all follow the same mechanics of intake, context, proposal, release and write-back.

Three conditions separate an agent in production from an assistant that employees ask questions. It works inside a process with a defined start and end, for example from the incoming complaint to the draft response. A named workflow owner in the business is measured on its result. And it runs within a control set that fixes read and write permissions, thresholds, checkpoints, logging and escalation.

Eurostat counts 55 per cent of large EU enterprises using AI in 2025. Among manufacturers that use AI, the most common purposes were marketing and sales at 30 per cent and the organisation of business administration processes at 27 per cent. Both are office processes around production, where cases arrive as emails and PDFs that an agent can read and turn into a step in a system.

The good candidates sit wherever many similar cases arrive as emails, PDFs or forms and someone checks them against the ERP, CRM or QM system. In a manufacturer that means technical service, the quote desk, quality and procurement, order entry, maintenance and field service, and the paperwork of production.

In complaint handling the agent assembles the case file for the 8D report, drafts the problem description (D2) and proposes containment actions (D3) from similar past cases, while root cause analysis and corrective actions stay with quality management. Purchase orders that arrive by email or PDF become draft sales orders in the ERP once the agent has checked customer, items, prices and delivery dates, which is the core of order entry automation.

On the shop floor, AI agents work on documentation and coordination, not on control loops. PLCs, SCADA, the process control system and anything else that controls or regulates in real time stay where they are, and the agent gets neither write access there nor a place in a control loop.

What it reads comes from the IT side: the shift log, fault texts, downtime reasons from the MES and maintenance history from the ERP. What it writes is a draft, such as a handover report, a deviation report or a maintenance notification, which the shift supervisor or maintenance planning releases. The separation between IT and OT that your network and security architecture defines stays unchanged.

Shift reports add a limit that has little to do with technology. The agent summarises faults, actions and open points, not the performance of individual employees. Annex III point 4(b) of the EU AI Act lists AI systems intended to monitor and evaluate the performance and behaviour of workers among high-risk systems, and in Germany section 87(1) no. 6 of the Works Constitution Act gives the works council a co-determination right over technical devices designed to monitor employees' behaviour or performance. The legal assessment stays with your legal and data protection functions; settle it with employee representatives before the agent reads its first shift.

The first AI agent belongs in a workflow with many similar cases, a named owner in the business and context that already sits in systems. In mid-sized manufacturers, good candidates are therefore the service inbox, the quote desk or order entry, because volumes there are already counted in the ERP and the ticket system.

Two answers rule a candidate out as the first workflow. If nobody in the business is measured on the result, you get a demo that nobody runs after the pilot. If the process decides about people, for example job applications or performance reviews, the obligations for high-risk systems shift effort and timeline.

The workflow check scores one specific process in ten questions on value, feasibility and ownership. Worked workflows with the agent, release points, control set and metrics are set out under use cases.

Low-code tools such as n8n or Microsoft Copilot Studio let a business team build an agent itself, and for a first prototype that can be the fastest route. Running in the system of record is decided by four points that no tool settles on its own: write access, control set, test set and ownership.

Both tools bring serious building blocks. In n8n, the AI Agent node connects a chat model with tools and lets the agent decide which tool to call, and n8n can be self-hosted on your own infrastructure, on premises or in a private cloud. Copilot Studio is Microsoft's graphical low-code studio for agents and workflows, with prebuilt and custom connectors to company systems, human review steps and evaluations against test sets.

Whether n8n, Copilot Studio or your own code in your cloud runs in the end is an architecture decision to take with your IT. A workflow can go into production with any of them once the four points are decided, written down and tested in shadow mode.

In the first quarter one workflow moves from assessment through the build into shadow mode, and the go-live decision follows the acceptance numbers. A Workflow Assessment takes four weeks and a Workflow Build 8 to 12 weeks from scope to production, with shadow mode against live cases starting in the last weeks of the build.

In shadow mode the agent drafts against real cases while people keep deciding. The comparison per case category is the evidence on which release rights widen, starting with the categories where the acceptance numbers hold. The principles behind this sequence are set out under how we work.