AI agents for manufacturing and field technicians: how to design them

Short answer: An AI agent for manufacturing and field technicians needs four things: documentation that is available without a signal, a source shown with every answer, a strict limit to its own domain, and data encrypted on the device and in transit. The best first deployment is an assistant over manuals that answers a technician's specific question right at the equipment. Process automation in the field starts when the technician no longer has to search and simply gets the answer.

Why it matters

A technician in the field is the most expensive place to look for information. They stand at the equipment, have limited time and often no signal, and the answer is buried in hundreds of pages of manuals or with an overloaded internal support team. Every minute of searching is a minute of lost work, and every faulty installation is an extra site visit. Process automation in manufacturing and service therefore does not start in the office, but at this point.

An AI agent, meaning a program that uses a language model to carry out a given task on its own over connected data, can solve this problem. But only if it is designed for the field. An agent that guesses parameters or answers anything you ask is more dangerous in the workshop than no agent at all. At MeguMethod we dealt with this in the app for 2N installation technicians, and within AI Infrastructure we help companies set what such an agent needs and where its limits are.

Want to know whether an AI assistant would help your technicians and what it would need? Book 30 minutes online with us. We will tell you what we would tackle first. Book an online call

Which use cases make sense in manufacturing and service

The best first deployment is the one that saves the technician searching and decides nothing for them. From our perspective, four situations keep coming up in manufacturing and service.

An assistant over manuals and documentation. The technician asks a specific question (“what is the wiring procedure for this module”) and the agent searches the documentation, answers and shows the exact place in the manual. This is how the Lennie assistant works in the app for 2N installation technicians: we converted the documentation into vector data, the agent finds the specific passage and attaches the source to the answer instead of guessing parameters. This type has the lowest risk and the fastest payoff, because the agent changes nothing and only shortens the path to the answer.

Documentation in the field. The technician has to document the state of the equipment and the course of a test or installation, and in the field this is done today with photos and notes that someone sorts later. An app that guides them step by step and leaves nothing out is the foundation; an agent can additionally check completeness or assemble a protocol from the notes. In Photo Creation Guide we built an app for the automotive industry that guides technicians through photo documentation of crash tests so that no mandatory shot is missing, with encrypted offline storage and synchronization once the signal returns.

Managing devices and sensors. The technician configures, checks and repairs devices in a network. A good interface with validation reduces errors more than any model; an agent can then help with diagnostics. For Jablotron we designed a web app for technicians managing devices and sensors, with the goal of replacing an interface built only for experts with something that shortens onboarding and limits errors.

Voice control. The technician has dirty hands or is holding a tool and needs to ask without typing. A voice layer makes sense, but it adds the demand of filtering workshop noise. It is an add-on over a working text agent, not the first step.

What an AI agent for the field must have

These four properties are not optional. When one is missing, technicians stop using the agent or, worse, trust it where they should not.

Documentation available without a signal. Workshops, installation sites and test tracks have no reliable signal. The manuals and data the technician needs most often must therefore be on the device, and searching them must work offline. The AI answers themselves usually need a connection, because the language model runs on a server. The app therefore has to tell the technician what it can do without a connection (search in downloaded information) and what it cannot (an AI answer). At 2N the manuals are available offline directly in the app and updates download only what has changed; search in downloaded information works offline, while the AI assistant works online only. In Photo Creation Guide, photos are encrypted in the phone's storage and synchronized once the connection returns.

A source for every answer. An agent at the equipment must not guess. Every answer should point to a specific place in the documentation so the technician can verify it. Technically this is RAG (retrieval-augmented generation): the model answers only from what it retrieved in approved documents, not from general knowledge. It protects against hallucinations, meaning answers that sound right but have no basis in the data. In the field, bad advice can damage hardware, which is why Lennie has zero tolerance for it.

A limit to its domain. The agent handles one topic: technical support for your products. Anything outside it should be declined. At 2N the assistant is set up for 2N product support and is not meant to be steered to other topics. A defined domain protects against misuse and gives technicians confidence that the agent knows what it is talking about. What happens when an agent has no such boundary will be covered in a separate article on prompt injection and AI agents.

Encryption and data security. Devices in the field get lost and stolen. Data must be encrypted on the device and in transit, and the app should pass a security review before technicians get it. Photo Creation Guide passed a security review and a penetration test with no findings, on the first attempt. Also ask where technicians' queries go and where the model runs; for some industries this means operation in the EU or in your own environment.

How to approach the design

The design starts with the technicians, not the model. The process we recommend has five steps, and the model comes only in the last one.

1. Observe technicians at work. What questions do they ask, where do they look for answers, where do they make mistakes and lose time. At 2N we started from the product manager's data, interviews and user observation, field research and competitor analysis. Without this step you are building an agent for a problem that may not exist.
2. Pick one use case and measure the baseline. How many queries support receives, how long it takes to find a procedure, how many visits are caused by faulty installation. A number before rollout is the only way to recognize the benefit later.
3. Get the documentation in order. The agent is exactly as good as its source. Decide what the source of truth is and who maintains it. Documentation often needs to be split so that the agent keeps the context of tables and wiring diagrams; at 2N we split the manuals by chapter.
4. Design the boundaries and oversight. What the agent may do, what it may not, when it says “I don't know” and when it hands over to a person. Decide who checks answers during the pilot and who maintains the agent afterwards. We cover this more broadly in the article What is an AI agent and how a company can use it.
5. Pilot with selected technicians, then expand. At 2N the first version was tested by selected technicians, and only then did the app go to the App Store and Google Play. The pilot produces a list of what to add to the documentation and what to adjust in the agent's boundaries.

When an AI agent for technicians makes sense and when it does not

It makes sense when:

• technicians repeatedly search for procedures in extensive documentation or call support with similar questions,
• documentation exists and someone maintains it,
• technicians often work without a stable signal and need the documentation on the device itself,
• a faulty installation or service means an extra visit or damaged equipment,
• you can measure the baseline (support queries, search time, repeat visits).

It does not make sense when:

• documentation is outdated, fragmented or missing; then that is the first step, not the agent,
• you want the agent to decide on interventions in the equipment without human review,
• technicians work on only a few types of equipment and know the answers by heart,
• you have nobody to maintain and monitor the agent after the pilot,
• the main motivation is to have AI, not to solve a specific problem in the field.

If you found yourself in the first list, send us a few sentences about what your technicians deal with today. We will get back to you with how we would proceed. Send an inquiry

How MeguMethod approaches it

We build assistants for technicians on two rules we have proven in our work for 2N: zero tolerance for hallucinations and a strict limit to the domain. Lennie works as a search engine over the 2N documentation, answers only from it, attaches a source to every answer and is set up for technical support of 2N products. The manuals are available offline in the app, including search in downloaded information; the AI assistant itself works online. We describe the same approach on the page about AI Assistants for B2B, which features, besides Lennie, a transactional bot over an internal API with data in the EU.

We address the broader framework in AI Infrastructure: we map what is running in the company, set rules for the stack and deployment, equip and train the team and keep overseeing the code. We start with a 30-minute online consultation with no commitment.

Next step

Want an AI assistant that answers your technicians at the equipment and makes nothing up? See how AI Infrastructure from MeguMethod works, or book 30 minutes online and we will go through what such an agent would need in your case. If you want context first, read What is an AI agent and how a company can use it, or our older article on digitization of internal processes.